Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am trying to help a friend figure this out, so I don't know all the details, but I figured I would post on here to see any possibilities.

We have a custom application that communicates using a single TCP port between the client and server and want it accessible both locally and remotely. The strange thing is that it works when the client is remote(internet) but NOT locally. Port forwarding is set in the router, which is a Cisco E800, and running a port scan indicates that the relevant TCP port is open to both the internal network and to the internet, however, the application will not connect locally. It DOES connect remotely so we know the server software is set up correctly, etc. OS on both ends of the connection is Windows 7 with windows firewall turned off.

Is there anything else we can try or tests we can run to determine the problem? I have run port discovery scans and ran netstat on the server. It showed the remote connections as "established" and another one with the machine name as "listening" on the relevant port.

Sorry I can't be more detailed, nothing about this problem makes sense.

EDIT: Since it seems like everything is set correctly, correct ports are open, etc. and we also know the server is functioning properly because it works from the remote location, maybe it is time to try some kind of packet sniffing/monitoring so we can see what is going on on that port... Is there an easy way to do this? In this way we could see if an attempt is being made, if there is any differences between a local request and a remote request, etc.

share|improve this question
Does the application connect by ip address or by name? – joeqwerty May 30 '13 at 18:58
Not sure how to do it on cisco hardware, but check if it supports NAT hairpin aka NAT loopback aka NAT inside-to-inside aka a few other terms. That's the usual culprit when it works from outside but not inside. – Grant May 30 '13 at 18:58
@Grant the answer below says this as well, however, I am having the issue where I cannot access it even by internal IP. It definitely feels like a router issue, and my friend says the problem started when she changed the router (it was a cable company provided router before and they didn't like being under their control) Is there any other sort of setting that would filter internal traffic over both the external and internal IP's but still allow access from the outside? – Kyle May 30 '13 at 20:23
@kyle from the client, can you telnet to that port on the server (using the local IP)? or does the connection timeout? If you run a port scan from the client computer against the server (try with both the internal and external IPs) does it show as being open in both cases? – Grant May 30 '13 at 20:38
@kyle also, double check that the subnet mask on both systems is correct. An incorrect subnet mask could cause similar issues. – Grant May 30 '13 at 20:40

On that router, the setting you are looking for is

Filter Internet NAT Redirection

Turn it off. That option prevents you from using the external address to connect from the inside, to the inside.

Turning it off allows NAT hairpin, so it will connect using the public address from outside and inside the LAN.

Some discussion about it on Linksys's forum here

share|improve this answer
Ok, will try this tomorrow when we go back on site. Would this prevent me from using the local IP to connect though? – Kyle May 30 '13 at 19:43
Probably not. Connections from the same LAN to the local ip address won't (or shouldn't) go through the router. If you're unable to connect from the same LAN to the local ip address then you can probably rule out the router or NAT as the problem. – joeqwerty May 30 '13 at 20:22
@kyle Agreed with joeqwerty...if you are definitely using the internal IP, the router shouldn't be involved at all. – Grant May 30 '13 at 20:37

The application should listen on or on both the ethernet IP and loopback IP (

The fact that only one listening port shows up and that is the hostname, means that the application is listening only on the ethernet IP.

Check your application configuration and change the listening IP to, then restart the application. Run netstat -an and check that the change was applied.

If you do now want to change the application configuration, then you must use only the ethernet IP address and never try to connect using localhost or

share|improve this answer

If you are on the same box as the server, you may not be able to connect if you try to connect to localhost. Use netstat to determine which address(es) the server is listening on. Assuming the server is on port 12345 this command should work:

netstat -an | grep 12345 | grep LISTEN 

If it is not listening on,, or *, you will need to connect to the address it is listening on. Your hosts entry may have the server name listed with the address, so that may be used if you try to connect by name.

share|improve this answer
I know the server is listening on its local IP (the left column of netstat output) – Kyle May 31 '13 at 1:08
And by local IP you mean the local ethernet IP or the local loopback IP? – Mircea Vutcovici May 31 '13 at 1:22
@Mircea the Ethernet IP – Kyle May 31 '13 at 18:03

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.