IMAP-auth on LAN and otherwise

Rupert Gallagher ruga at protonmail.com
Tue May 2 19:59:22 EEST 2017


It may be the new router and the new switch doing something "smart",
because problems started to show up since their installation.
We are purchasing a Cisco Catalyst just to diagnose the hardware.

There may be a software problem, although things used to work before
the installation of the new hardware. We use nsd to serve the public IP, and
we use unbound to serve recursive DNS queries to LAN clients.
This is unbound's stub-zone / split-horizon for the public DNS:

stub-zone:

name: "example.com."

stub-addr: 127.0.0.1 at 5350

stub-addr: 192.168.1.6 at 5350

stub-prime: no

stub-first: no

where "example.com" is the dovecot server.

The settings return consistent behaviour: the clients always receive
the correct public address by querying nsd at 192.168.1.6 on port 5350.

The puzzling bit is shown by Wireshark: sometimes dovecot returns ACK
from the LAN address, which is not correct for the given setup.

It will take weeks before we can diagnose with the Catalyst. Gosh...

-------- Original Message --------
Subject: Re: IMAP-auth on LAN and otherwise
Local Time: 2 May 2017 4:53 PM
UTC Time: 2 May 2017 14:53
From: tobster at brain-force.ch
To: dovecot at dovecot.org

I'm not sure that this is a dovecot issue. For me it sounds more that
the router somehow learned dovecots LAN ip and then takes a shortcut by
sending the packets directly to dovecot on routers LAN interface instead
of going all the way to the WAN interface and then back to LAN.
You could verify if that is the case by tcpdump on dovecot and see on
what interface the request comes is.

If that would be my setup I would configure a local nameserver with
split-horizon config and resolve my dovecots hostname with the LAN IP.
Then connecting TB to dovecots hostname as servername. So if your
outside your LAN it would resolve with your public IP and inside your
LAN it resolves with dovecots LAN IP.

Cheers

tobi

Am 02.05.2017 um 15:46 schrieb Rupert Gallagher:
> Hello,
>
> Thunderbird has been bugging us with connection errors. Dovecot is installed on a local server that carries a local IP and a public IP. When Thunderbird on a local client connects successfully, Wireshark shows a SYN request from the client's IP on LAN to the public IP of the server, followed by the ACK from the same public IP. When Thunderbird on the same local client fails to connect, Wireshark shows a SYN request from the client's IP on LAN to the public IP of the server, followed by the ACK from the server's LAN address, the client does not accept the ACK as valid and sends a new SYN request. The loop eventually leads to time-out. At the client's console, the DNS query of the IMAP server always responds with the server's public IP address.
>
> It is evident from Wireshark that the dovecot server sends ACKs from two IPs. Is it possible to instruct Dovecot to use the public IP only?


More information about the dovecot mailing list