Question: sometimes Postfix thinks 172.18.0.1 is the client_ip

[j-schumann]

Sometimes when receiving mail (from an external server) I can see something like this in the logs:

postfix/smtpd[4657]: connect from unknown[172.18.0.1]
postfix/smtpd[4657]: Anonymous TLS connection established from unknown[172.18.0.1]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
postfix/cleanup[4665]: 78DA3189E7E: milter-reject: END-OF-MESSAGE from unknown[172.18.0.1]: 5.7.1 rejected by DMARC policy for google.com; from=<noreply-dmarc-support@google.com> to=<postmaster@example.com> proto=ESMTP helo=<mail-oi0-x249.google.com>

So postfix only sees the IP of the docker host (172.18.0.1) instead of the real client IP. This causes different problems: SPF fails and eventually fails DMARC (as in the log above), or the spam score from spamassassin contains "ALL_TRUSTED=-1" as the mail server thinks the mail came from a trusted network.

Others are having the same problem with Docker & Postfix: http://stackoverflow.com/questions/39517593/postfix-docker-and-inconsistent-ip-addresses-from-host
I'm using docker compose (yaml v2) with no specific network settings (so it uses the default bridged mode) and no other proxies, the ports are directly exposed.

I was wondering if you ran into the same problem / know the reason for this?

[hardware]

It's a docker-side issue, there are two solutions for this problem :

• use --net=host : not viable, less isolation = more security flaws.
• disable the userland proxy : not viable at the moment, this option breaks kernel in a very bad way in some cases and it's incompatible with --iptables=false option.

But in my case, I don't have problems with SPF and DMARC, maybe this issue is inconsistent. I will check on my own server after work tonight.

moby/moby#15086
moby/moby#14856

[j-schumann]

Thanks a lot for the issue links, I subscribed there.

Yes, it seems to be inconsistent, e.g. moby/moby#7540. I mostly see this happen with mails from Gmail, but this may be coincidence. Would be interesting if you have the same entries in the logs as it mostly goes unnoticed. You could grep for "unknown[172.18.0.1]" (or whatever your Docker gateway IP is) in the mail.log

As this is obviously a docker problem and not related to Postfix (I saw the same issue in my Nginx logs now) you can close the issue here.

[hardware]

You could grep for "unknown[172.18.0.1]" (or whatever your Docker gateway IP is) in the mail.log

I have no result for "172.17.0.1" in mailserver log.

Thanks a lot for the issue links, I subscribed there.

Me too :) I hope this will be fixed in a future release.

[konstantinj]

Hi,
same issue for me after I've update docker from 1.12.x to 17.06.x.
2017-09-18T21:12:23.335362+00:00 mail postfix/smtpd[623]: connect from unknown[172.17.0.1]
Also with the new docker version I cannot get the client ip from my nginx container anymore.
Unfortunately setting userland-proxy=false makes it worse since the mailserver is then not able to get traffic anymore. But sending still works. But: Nginx then gets the client ip. What did docker do?

[j-schumann]

There are still many people having this problem, check the docker issues linked in the second post. Also moby/moby#15086 (comment) mentions the IPv6 module which I think might be true as not all external connections show up as 172.17.0.1 (or 172.18.0.0 in my case), only 1/4 to 1/3 of the incoming IPs in the logs are 172.% but none are IPv6 addresses...

So maybe with docker you also updated your kernel to a "bugged" version or enabled IPv6?

[ksylvan]

I did not enable ipv6 and I don't see those unknown[172 messages in my mail logs either. I do have one host that turned on ivp6 and I see those messages in the mail logs there.

[konstantinj]

I'm on Ubuntu 17.04 with 4.10.0-33. Before I was using Centos wihtout these issues. mh.

[konstantinj]

I've now disabled IPv6 like this: https://askubuntu.com/questions/309461/how-to-disable-ipv6-permanently

Now I get real client IPs without setting userland-proxy to false or anything else.