I've searched around a great deal with this, but can't manage to come up with a solution.

The easiest way of explaining it, is I used to have just 1 email server, now I have 2. The 1st email server accepts SSL connections only, and forwards non-SSL (ie 110, 143 etc) to the second server (this is in place because clients have their emails set up and working with the DNS entry that points to the first email server).

I want to use Fail2ban on the 2nd server to block failed logins, but I can't figure out how, as Dovecot only 'sees' the 1st server's IP address.

I can turn on logging on iptables on server 1, but cannot see how to 'relate' the connection to the failed password attempt on server2.

  • 1
    What proxy did you use to do SSL-decryption? Nginx? dovecot? stunnel? others? – masegaloeh Nov 30 '14 at 8:59
  • I don't use SSL decryption. Simply users connecting to server 1 must use SSL (port 995 etc), if they don't, their connection is sent to server2 – Fraser Nov 30 '14 at 9:33
  • Andrew, dovecot still couldn't see the source ip address :( Antony, Couldn't get this working, it kept coming up with error 255 (I can ssh into server2 from server1 and the otherway around no problems) – Fraser Dec 4 '14 at 9:57

A couple of possible solutions:

  1. Stand up Dovecot on server1, and configure it to use login referrals to send the clients over to server2. If your clients support login referrals, this could be the simplest solution. It would introduce a small delay with each new login, as the client connected to server1 and then got sent over to server2.

  2. Stand up Dovecot on server1, and configure it to proxy the connection to server2. The Dovecot wiki lists two methods of proxying:

    • Forward the password to server2. I guess that this can work as long as you can configure Dovecot on server2 to log the IP address of the client from the proxied connection, so Fail2ban can use it.

    • Perform the authentication on server1. Then you could set up Fail2ban on server1. Disadvantage is that then you have to log into server2 with a master password.


Perhaps an easier solution is to have it all running on server1 and just tunnel pop/pops and imap/imaps to server2 (autossh is a simple solution, but there are probably some better ways).

If you run autossh to maintain a ssh connection from server2 to server1:

autossh -M 3319 -4 -R 993:localhost:993 -R 995:localhost:995 -NC server1 -f

You could throw this line in /etc/rc.local for the quick and dirty way.

  • -M 3319 must point an available port (it will use 3320 too). autossh uses it control the tunnel is up. (see manpage of autossh)
  • -4 is to limit to ipv4 (see also the manpage)

If you initiate the connection from server1 to server2 then -R becomes -L (Local instead of Remote).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.