IMAP-auth on LAN and otherwise
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?
Test on 10-master.conf:
inet_listener imaps { address = <public-ip> port = 993 ssl = yes }
Returns the following error:
Error: bind(<public-ip>, 993) failed: Can't assign requested address
2017-05-02T18:12:41 master: Error: bind(<public-ip>, 993) failed: Can't assign requested address
Error: service(imap-login): listen(<public-ip>, 993) failed: Can't assign requested address
2017-05-02T18:12:41 master: Error: service(imap-login): listen(<public-ip>, 993) failed: Can't assign requested address
Fatal: Failed to start listeners
-------- Original Message -------- Subject: Re: IMAP-auth on LAN and otherwise Local Time: 2 May 2017 4:26 PM UTC Time: 2 May 2017 14:26 From: reinob@bbmk.org To: Rupert Gallagher ruga@protonmail.com dovecot@dovecot.org dovecot@dovecot.org
On Tue, 2 May 2017, Rupert Gallagher wrote:
[...] Is it possible to instruct Dovecot to use the public IP only?
for inet_listeners (imap, pop, etc.) you can use "address = <your-public-IP>" the default is AFAIK to listen on all addresses ("*" for ip4 and "::" for ip6)
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?
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?
Problem solved.
Sent from ProtonMail Mobile
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?
How? :)
On May 3, 2017 5:25:51 PM GMT+02:00, Rupert Gallagher ruga@protonmail.com wrote:
Problem solved.
Sent from ProtonMail Mobile
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?
By pointing the clients' DNS to the server's local address, instead of the public one.
We feared it would break IMAP locally, because of DNSSEC and DANE and what not, all tied to the public IP. It just passed the test, and IMAP is much faster now.
Sent from ProtonMail Mobile
On Wed, May 3, 2017 at 5:27 PM, B. Reino reinob@bbmk.org wrote: How? :)
On May 3, 2017 5:25:51 PM GMT+02:00, Rupert Gallagher ruga@protonmail.com wrote:
Problem solved.
Sent from ProtonMail Mobile
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?
participants (3)
-
B. Reino
-
Rupert Gallagher
-
Tobi