spacehunt.info

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.