On Monday 08 May 2017 19:25:26 Rupert Gallagher wrote:
Today the problem raised its head again, with a twist. A LAN client lost the DNS setting that pointed directly to the LAN address of the IMAP server, and two things happened: the LAN client could not connect to IMAP as we know, and a telephone call from the external client reported the same. When the LAN client closed Thunderbird, then the external client regained access. There were no other clients online at the same time. It turns out that the single LAN client was making enough requests to saturate dovecot's authentication service. I already described the detail with wireshark.
On Tue, May 2, 2017 at 3:46 PM, Rupert Gallagher <ruga@protonmail.com> wrote: 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?
I think is better to fix that using iptables, depending on your network topology (if you NAT the local lan traffic with destination the external IP of dovecot, it will answer with the external IP) . In yours case, looks like the trafic to the external IP isn't NAT-ed, which could cause troubles also for other kind of traffic.