1

There is a server program running behind a home ADSL modem/router, at a premise that I'll call C; the program listens on TCP port 29401, and accepts connections using a custom binary, non-HTTP, protocol to exchange data. The home router has a port forwarding feature that has been configured to allow (in addition to HTTP and SSH) Internet communication with such program:

Outer port: TCP 29401
Inner port: TCP 29401
Server address: 192.168.1.196

The home ADSL modem/router has a dynamic public IP on the external interface, and uses the usual 192.168.1.X/24 range of private addresses for the LAN. The server is running a dynamic IP auto-update client which keeps a DNS Host (A) record up-to-date. The private IP of the server is 192.168.1.196. Let dyn.example.com be the name of the dynamic DNS domain.

I'll focus on a scenario involving two additional premises, which I'll call A and B. These 3 premises are unrelated and independently connected to the Internet.

Premise A

From premise A it is possible to:

  • Browse the website corresponding to dyn.example.com virtual host on Apache.
  • SSH into the server using the hostname to establish the connection
  • A client program for the custom binary server is able to connect to dyn.example.com:29401 and exchange data.
  • Skype and other VOIP software (which like uses hole punching) works properly.
  • Connect to http://portquiz.net:29401/ and receive the appropriate page.

Premise B

From premise B it is possible to:

  • Browse the website corresponding to dyn.example.com virtual host on Apache.
  • Cannot test SSH, as no SSH client is available at premise B.
  • The same client program crashes, reporting that connection was forcibly closed by the remote host. The custom server doesn't show any evidence of a connection being established at any point.
  • Skype and other VOIP software (which like uses hole punching) works properly.
  • Connect to http://portquiz.net:29401/ and receive the appropriate page.

Choosing other TCP ports results in the same behavior.

Question

Does evidence suggest that at premise B outgoing traffic is analyzed at application level on all TCP ports? All ports can exit, but if they try to talk using a protocol different from HTTP, the firewall terminates the connection. To me this is surprising because I heard that first an administrator would lock all ports, and then proceed to analyze the traffic on port 80 to prevent applications from using HTTP tunneling techniques.

Improve this question

1 Answer 1

Reset to default
1

It's certainly possible to block based on more sophisticated protocol detection than simply the port.

It's also quite possible that the traffic is being broken by accident. Domestic Internet providers will often assume that their users are doing conventional things and optimise their networks accordingly.

One useful test would be to establish a VPN from the B site and see if it works when it is tunnelled through B's ISP.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .