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@5350
stub-addr: 192.168.1.6@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@brain-force.ch To: dovecot@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?