-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all! I'm stuck. I've got a dovecot IMAP server running (TLS, port 149) on Ubuntu 13.04 server behind a DSL router. The mailserver's IP is 10.0.0.1 When I connect to my mailbox from my intranet-PC (10.0.0.2), everything works as expected. Login OK, acces to all mailboxes is ok, everything. netstat -nt on my email server shows me: Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 10.0.0.1:143 10.0.0.2:57952 ESTABLISHED and /var/log/mail.log shows me: Aug 24 22:41:00 SERVERNAME dovecot: imap-login: Login: user=<UID>, method=PLAIN, rip=10.0.0.2, lip=10.0.0.1, mpid=24326, TLS, session=<3Ul+irfkYAAKAAAC> However, when I connect to my mailserver through the internet (from 10.196.124.7 which is a modem of my ISP), dovecot ignores the authentication request. It does nothing. Just nothing. My router forwards the connection request to my mailserver correctly, so port forwarding on the router is ok, as my mailserver gets a connection request from the client. Proof: "netstat -nt" shows me: Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 10.0.0.1:143 10.196.124.7:1024 SYN_RECV So, my server gets a connection request on port 143 from my client PC, but then nothing happens. By nothing I mean, that nothing gets written into /var/log/mail.log and my email client (Thunderbird) gets a connection timeout. Any ideas why dovecot is refusing connections? How can I solve this problem? thanx all Sulla -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlIZI7sACgkQR6b2EdogPFvqxACgrUACK1J8tHCxJR0jMUui14bs TsoAnAw4QnVr2kydjk2cErKW+i6oVu1f =86wg -----END PGP SIGNATURE-----
On 08/24/2013 05:20 PM, Sulla wrote:> > My router forwards the connection request to my mailserver correctly, so > port forwarding on the router is ok, as my mailserver gets a connection > request from the client. Proof: "netstat -nt" shows me: > > Proto Recv-Q Send-Q Local Address Foreign Address State > tcp 0 0 10.0.0.1:143 10.196.124.7:1024 SYN_RECV > >This proves one thing: that the SYN was received. It doesn't prove that the reply is being routed back properly. Obviously you have an asymmetrical routing or firewalling issue, and I'm not sure what kind of address translation should be / is / is not being preformed. This is a basic networking issue and has nothing to do specifically with dovecot. Try to shut dovecot down and open a listening port with netcat: #$ nc -lp 143 or for verbose output # nc -vvlp 143 On the other LAN compuer: # nc -vv 10.0.0.1 143 and start "chatting". It will work. From the outside computer it won't. If it does, dovecot will work too. Proceed with troubleshooting. TCP is handled by the kernel, not by dovecot. (you might want to look at the nc man page for the exact options available for your specific variety of netcat) You can probably do this on any other arbitrary port, it doesn't have to be 143 so you can let dovecot run at least for the LAN, if needed, while you figure this out.
Thanx to this very supportive list!! Richard pointed out to me that the IP which I called "external" was a net-10 IP and thus no official address, but rather belonged to the private pool of my ISP and that net-10 adresses were not routable with arbitrary results when a router nevertheless tries to route them. This hint was right on!!! I suspect that my ISP directly routed my connection request back to me without ever unleashing it to the open internet. It's a bit weird. I just set-up my (ancient) mobile phone (Sony Ericsson z770i) (IP: 213.162.68.141) to connect to my mailserver (I have different network provider, so this MUST go over the internet now), and this works! netstat -np tells me: Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 10.0.0.1:143 213.162.68.141:29650 ESTABLISHED and /var/log/mail.log shows: Aug 25 00:01:26 SERVERNA;E dovecot: imap-login: Login: user=<UID>, method=PLAIN, rip=213.162.68.141, lip=10.0.0.1, mpid=24703, TLS, session=<g6kmqrjk0gDVokSN> and my phone is just synching with the account... Haven't tried SMTP-ing yet... (it only cost me about 3 hours and a few hairs...) also thanx to Javier and Gedalya: The ubuntu 13.04 server installation does not have a firewall enabled (I guess this is typical for ubuntu), at least "sudo iptables -L -n" shows for INPUT, FORWARD and OUTPUT: policy ACCEPT. route -n shows: Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 10.0.0.138 0.0.0.0 UG 0 0 0 eth0 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 which is ok, I guess. -- View this message in context: http://dovecot.2317879.n4.nabble.com/dovecot-OK-for-intranet-not-OK-for-external-IPs-tp44051p44053.html Sent from the Dovecot mailing list archive at Nabble.com.
Stan Hoeppner
2013-Aug-24 22:31 UTC
[Dovecot] dovecot OK for intranet, not OK for external IPs
On 8/24/2013 4:20 PM, Sulla wrote:> I've got a dovecot IMAP server running (TLS, port 149) on Ubuntu 13.04 > server behind a DSL router. The mailserver's IP is 10.0.0.1...> However, when I connect to my mailserver through the internet (from > 10.196.124.7 which is a modem of my ISP), dovecot ignores the > authentication request. It does nothing. Just nothing.Basic IP networking problem. Your ISP is using the RFC 1918 class A private address space for its customers because it apparently has too little routable public space. Adding insult to injury you have configured the same class A subnet 10.x.x.x on the LAN segment of a consumer DSL "router" which is not an IP *router* at all. It is a Network Address Translation device. You're telling it to translate 10/8 to 10/8 which is impossible. The solution? Simple. You must use one of the other two RFC 1918 private address spaces on the LAN segment of your NAT'ing DSL modem. Here are all three. Pick one that is not 10/8. Hint, most people use 192.168/16 because the subnet masking is easier to remember, and because few people have more than 256 devices on their home network. 10.0.0.0 - 10.255.255.255 (10/8 prefix) 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) -- Stan