Docker-mailserver: Fail2Ban bans docker gateway address

Created on 19 Feb 2017  路  14Comments  路  Source: tomav/docker-mailserver

Hello,

Thank you so much for your work.

I have a problem.
When attempting several connections with a wrong password (and user!), fail2ban ban the remote IP at the source of those requests, which is a normal behavior.
Unfortunately, this remote IP is my Docker gateway (172.18.0.1), thus completely avoiding anything coming from that IP to reach dovecot, making my entire mailserver not working anymore.

It here seems that the only two solutions would be:

  • disable fail2ban entirely (which is a shame ! :))
    or
  • whitelist the docker IP gateway (leading to no filtering anymore, as all requests goes through this IP to communicate to my docker-mailserver container)

What can be done here ?

Thank you in advance.

enhancement question

Most helpful comment

Which configuration on the host is needed to let the IP appear of the real client? To me it sounds like a docker issue and not a container issue?

All 14 comments

Docker's userland proxy masquerades the source address of all incoming connections. You could use the --net=host option to share the network stack between the Docker host and your container. This would bypass the issue.

More here:
https://github.com/docker/docker/issues/15086

Perhaps there's something to do here: https://github.com/tomav/docker-mailserver/blob/master/target/start-mailserver.sh#L763-L791

Adding this to fail2ban config may solve the problem.

@PAFsec let us know if you can contribute to this enhancement. Thanks.

Docker's userland proxy masquerades the source address of all incoming connections. You could use the >--net=host option to share the network stack between the Docker host and your container. This would >bypass the issue.

how I can use --net=host with docker-compose?

Is this still an issue?
If not how did you solve it?

This is still issue

@niko886 when you tails the output do and you connect to smtp for example, do you see the docker gateway ip or the client ip?

My setup runs with a ipv6 nat and docker network bridge just fine.
See here a snippet of my log:

mail                     | Sep  8 18:29:47 mail postfix/smtpd[1861]: connect from o10.sgmail.github.com[167.89.101.201]
mail:
    restart: always
    image: tvial/docker-mailserver:latest
...
    networks:
      app_net:
        ipv4_address: 172.16.38.2

networks:
  app_net:
    driver: bridge
    enable_ipv6: true
    ipam:
      driver: default
      config:
        - subnet: 172.16.38.0/24
        - subnet: fd00:aaaa:bbbb::/48

How is your configured?

@johansmitsnl The only way to me to solve this problem is using --net=host.

do you see the docker gateway ip or the client ip?

Without --net=host I see docker gateway ip, here is my config:

    networks:
      mail-net:
        ipv4_address: 172.16.0.10
...

networks:
  mail-net:
    driver: bridge
    ipam:
      driver: default
      config:
      -
        subnet: 172.16.0.0/24

With this setting you have the issue right?
You setup seems identical to mine and I have no issues with it.
Could you post a part of your mail log to verify the ip's?

@johansmitsnl sorry for late response

With this setting you have the issue right?

right, but subnet can change in my exampes, this is log for 172.17.0.0/24:

  • mail.log
Sep 14 16:33:14 mail postfix/smtpd[1401]: connect from unknown[172.17.0.1]
Sep 14 16:33:15 mail dovecot: auth: passwd-file([email protected],172.17.0.1): unknown user (SHA1 of given password: c6922b)
Sep 14 16:33:17 mail postfix/smtpd[1401]: warning: unknown[172.17.0.1]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
Sep 14 16:33:17 mail postfix/smtpd[1401]: disconnect from unknown[172.17.0.1] ehlo=1 auth=0/1 rset=1 quit=1 commands=3/4
Sep 14 16:33:42 mail dovecot: ssl-params: SSL parameters regeneration completed
Sep 14 16:33:42 mail dovecot: imap-login: Error: Timeout waiting for handshake from auth server. my pid=1399, input bytes=0
Sep 14 16:33:42 mail dovecot: imap-login: Disconnected: Auth process broken (disconnected before auth was ready, waited 78 secs): user=<>, rip=172.17.0.1, lip=172.17.0.2, TLS handshaking: Disconnected, session=<rkDt1ihZc7KsEQAB>
  • fail2ban.log
2017-09-14 16:33:15,715 fail2ban.filter         [999]: INFO    [dovecot] Found 172.17.0.1
2017-09-14 16:33:17,731 fail2ban.filter         [999]: INFO    [postfix-sasl] Found 172.17.0.1

I am running this mailserver on docker-osx and have this exact problem. ie, all ip address that attempt to communicate with the mailserver appear as 172.18.0.1. It doesnt take long for fail2ban to ban the mailserver from itself. Theres no way im running a mailserver without fail2ban. no sir

If i run the exact same container (and config) on a bridged vm (ubuntu 16.0), i can see all manners of ip addresses communicating with the server and fail2ban can easily lock out the offenders.

I can only assume that this is something to do with Docker for Mac's appalling network implementation.

looking at the MAILCOW compose file in comparison , the fail2ban service is launched with : network_mode: "host"

might be worth investigating further!

Which configuration on the host is needed to let the IP appear of the real client? To me it sounds like a docker issue and not a container issue?

Any news on this?

I agree with @johansmitsnl that this sounds more like a docker configuration issue than a mail server issue. Furthermore nothing has happened for more than a year, so I'll close this. If it is still an issue and you feel that we should change something to make it work, please submit a PR or a detailed suggestion.

Was this page helpful?
0 / 5 - 0 ratings