Over the past month, our colleagues in mainland China have been complaining about not being able to connect to our email server, which is located in Hong Kong. Connecting to ports 25 (SMTP), 143 (IMAP4), 110 (POP3), 80 (HTTP), 443 (HTTPS) and 22 (ssh) often results in an immediate ‘Connection closed by foreign host.’
Well, not quite immediate… often some bits can be passed through, for example:
# telnet mail.sw-linux.com 143 Trying 202.153.106.243... Connected to mail.sw-linux.com. Escape character is '^]'. * OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT IDLE ACL ACL2=UNION STARTTLS XMAGICTRASH] Courier-IMAP ready. Copyright 1998-2004 Double Precision, Inc. See COPYING for distribution information. Connection closed by foreign host.
# telnet mail.sw-linux.com 25 Trying 202.153.106.243... Connected to 202.153.106.243. Escape character is '^]'. 220 mail.sw-linux.com ESMTP Exim 3.35 #1 Fri, 09 Jun 2006 13:14:12 +0800 HELO nanjing 250 mail.sw-linux.com Hello nanjing [218.104.86.222] MAIL FROM: xxxx@sw-linux.com 250 <xxxx @sw-linux.com> is syntactically correct RCPT TO: xxxx@sw-linux.com 250 <xxxx @sw-linux.com> is syntactically correct Connection closed by foreign host.
So what do we do? Let’s do a trace of the actual TCP/IP packets, courtesy of ethereal. Here’s what our Hong Kong server sees:
Capturing on eth0 0.000000 218.104.86.222 -> 202.153.106.243 TCP 39758 > smtp [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=92231345 TSER=0 WS=6 0.000811 202.153.106.243 -> 218.104.86.222 TCP smtp > 39758 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=15684968 TSER=92231345 WS=7 0.102624 218.104.86.222 -> 202.153.106.243 TCP 39758 > smtp [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=92231453 TSER=15684968 0.103506 218.104.86.222 -> 202.153.106.243 TCP 39758 > smtp [RST] Seq=1 Ack=1302803663 Win=0 Len=0 0.190447 218.104.86.222 -> 202.153.106.243 TCP 39758 > smtp [RST] Seq=1 Ack=1 Win=0 Len=0 0.231670 218.104.86.222 -> 202.153.106.243 TCP 39758 > smtp [RST] Seq=1 Ack=1 Win=0 Len=0
And from our Nanjing client:
Capturing on eth0 0.000000 218.104.86.222 -> 202.153.106.243 TCP 39758 > smtp [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=92231345 TSER=0 WS=6 0.107777 202.153.106.243 -> 218.104.86.222 TCP smtp > 39758 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1460 TSV=15684968 TSER=92231345 WS=7 0.107813 218.104.86.222 -> 202.153.106.243 TCP 39758 > smtp [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=92231453 TSER=15684968 0.234913 202.153.106.243 -> 218.104.86.222 TCP smtp > 39758 [RST] Seq=1 Ack=1 Win=0 Len=0 0.269906 202.153.106.243 -> 218.104.86.222 TCP smtp > 39758 [RST] Seq=1 Ack=1 Win=0 Len=0
Now I’m no networking expert, but look at all these packets with the RST flag set… no wonder the connection drops. Even more strangely, look at the line I bolded; that Ack number seems to have came out of nowhere.
Man-in-the-middle, perhaps?
So this morning at around 11am, we opened another set of ports with non-standard port numbers for our mainland colleagues to use. It worked… while it lasts; even these ports were blocked by around 12:20pm ten minutes later.
What can we do?
Update Duh, this is very likely due to the enforcement of the new anti-spam legislation.
Ok, I’m seeing this now.
We setup a service on port 26 for clients to send mail through with SMTP AUTH
(port 25 is spam filtered with a bunch of rbl’s now, and we’re seeing plenty collateral damage blocking)
If clients were blocked, we told them change over to port 26. (I would normally tell people use SSL / port 587, but we find that incurs the wrath of connection reset^H^H the firewall in spades, so i don’t even bother)
Problem was that they still couldn’t send mail.
A check on the server showed that everything was coming in ok except for the DATA.
Somewhere along the line the ‘china proxy’ was dropping that.
I did some logging myself as this was replicatable, and lo and behold, I was seeing similar to you - what I was sending was not what I was receiving.
Logging them off / on ADSL solved this for me. Probably something like - new ip address, new session with proxy server.
Makes running mail services here such fun, sigh…
you are right about the Man-in-the-middle.
Give this a look
http://www.lightbluetouchpaper.org/2006/06/27/ignoring-the-great-firewall-of-china/
iptables solve the problem if used on both sides.
That’s exactly what we tried. Sure, the connection doesn’t drop, but there’s still the transparent proxy to deal with.