Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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 have a weird problem. I can run this command just fine from various servers:

wget --debug '--http-user=USER123' '--http-passwd=PASSWORD' http://GW-BOX:9091/weijhkdsvn/v9_odbc//CRONTAB.2014020

Where "GW-BOX" is the gateway to my network, USER123 and PASSWORD represent the user and password for weijhkdsvn, and 9091 points to an internal Linux server. The problem is that that this command times out and/or gets rejected.

wget --debug '--http-user=USER123' '--http-passwd=PASSWORD' http://GW-BOX:9093/weijhkdsvn/v9_odbc//CRONTAB.20140206

Port 9093 points to a different internal server. Note that the only difference is the port.

So then I tried to do a wget directly from the server, to ensure that http was configured correctly:

wget --debug '--http-user=USER123' '--http-passwd=PASSWORD' http://9091-Server:80/weijhkdsvn/v9_odbc//CRONTAB.20140206

In this case, 9091-Server is the internal server that port 9091 refers to. It works fine. Then I tried the same command, but mimicing port 9093:

wget --debug '--http-user=USER123' '--http-passwd=PASSWORD' http://9093-Server:80/weijhkdsvn/v9_odbc//CRONTAB.20140206

where 9093-Server refers to the internal server that 9093 points to.

So the above examples prove that 9093-Server has http setup correctly to allow wget, as far as I can see. This suggests that maybe the problem is with GW-BOX, so I tested the ports with telnet, and port 9091 worked fine.

[wmsodbc]> telnet GW-BOX 9091
Trying GW-BOX...
Connected to GW-BOX.
Escape character is '^]'.
telnet> quit
Connection closed.

But port 9093 did not work:

[wmsodbc]> telnet GW-BOX 9093
Trying GW-BOX...
telnet: connect to address GW-BOX: Connection refused

So then I checked iptables on GW-BOX:

[root@wmsgateway ~]# iptables-save | grep "909[13]"
-A INPUT -p tcp -m tcp --dport 9091 -j LOG 
-A INPUT -p tcp -m tcp --dport 9093 -j LOG 
-A PREROUTING -d GW-BOX-EXTERNAL-IP/32 -p tcp -m tcp --dport 9091 -j DNAT --to-destination 9091-ServerIp:80 
-A PREROUTING -d GW-BOX-EXTERNAL-IP/32 -p tcp -m tcp --dport 9093 -j DNAT --to-destination 9093-ServerIp:80 
-A POSTROUTING -d 9091-ServerIp/32 -p tcp -m tcp --dport 9091 -j SNAT --to-source GW-BOX-INTERNAL-IP
-A POSTROUTING -d 9093-ServerIp/32 -p tcp -m tcp --dport 9093 -j SNAT --to-source GW-BOX-INTERNAL-IP 
[root@wmsgateway ~]# 

So what else can I check to see why port 9091 accepts wget/telnet requests, but 9093 does not?

share|improve this question
Is your service running? – Michael Hampton Mar 6 '14 at 23:45
What service? Note that one port works, the other port does not, so that suggests things are running. Note also that wget using 9093-Server:80 works, which means service is running on 9093-Server. The only thing that fails is going from some third serverr to GW-BOX to 9093 to 9093-Server. – user3329922 Mar 7 '14 at 16:55
in the code above, you use made up names, and such, maybe check all your different setups, and check for a simple spelling mistake? – Sverre Mar 9 '14 at 15:04

One method of verifying where the issue is, is to swap the ports against the servers. ServerA currently has Port 9091 and functions correctly, ServerB has Port 9093 and fails. To determine if the issue is in the GW-Box or the server itself, turn the iptables configuration around in the GW-box for the SNAT. Point 9091 to ServerB, and 9093 to ServerA. If 9091 continues to work, you know the issue is somewhere in the rule you have for port 9093, as Server A and B both work on 9091, this could also indicate a firewall rule issue on Server B as well. If 9091 fails, but 9093 works, you can safely assume that your GW-Box is operating correctly, and that Server B somehow is not allowing the upper range ports to access via WGET, since you have confirmed previously that WGET is accessible directly.

share|improve this answer
Ok, flipping 9091 with 9093 showed something. Now 9091 does not work from a remote computer. So that would mean something is wrong with the 9093-Server, which makes no sense because wget 9093-Server:80 works fine from the GW-BOX. I thought iptables was sending ports 9091 and 9093 to port 80 on their corresponding server ( see above ). Is it not doing that? Is it sending it to a totally different port? – user3329922 Mar 7 '14 at 17:41
BTW, for the 9091-Server ( the one that works ) and 9093-Server ( the one that does NOT work ), iptables is not active, and we are NOT listening for ports 9091 or 9093 according to netstat. This means that, from the perspective of iptables and netstat, both the working machine and non-working machine are setup very similarly. – user3329922 Mar 7 '14 at 17:53
Is there anything else that could be affecting the port in question on the network? If the server is not responding on ~either~ remote port that's being forwarded, are you certain that the rule in the GW does not have anything unusual going on in it pertaining to the hostname or IP for the 9093-Server? All of your troubleshooting steps are suggesting that there is something in the 9093 server that is causing the issue. Possibly does the configuration for the http file share server have any access control on it? Or does it have any specific listening IP that could be the issue? – George Spiceland Mar 8 '14 at 4:52
The thing is that it works fine with port 80, so would that not suggest that configuration for http file share server is setup correctly, to allow access? I mean that is all the GW box does is route the external port to port 80 on the "bad" server. You also point out that maybe the rule on the GW is doing something unusual. I don't see how, but I suppose anything is possible. I will check those rules again. – user3329922 Mar 25 '14 at 22:40
Just thought of another symptom that might have a bearing on your comments, George: If I use this GW box as the GW for other machines, then those other machines cannot access the internet. But this GW box can definitely access the internet. In other words, ping of inside the network would not work, but ping of would work from this GW box. Do you think this could explain my problem? I don't see how, as I can run wget to another machine inside the network, but it is a symptom worth mentioning. – user3329922 Mar 26 '14 at 16:02

First, the test you did directly on wget to the servers, where were these test made from? from the original host, or from GW-box or from some "3rd party" host?.

Also, on GW-box have you checked if other services uses the 9093 port? (on gw-box run something like:

netstat -lnptu | grep 9093
share|improve this answer
For the 9093-Server:80 and 9091-Server:80 wget tests I did above, I ran them directly on GW-BOX, thus proving that things are setup correctly on 9091-Server and 9093-Server to allow wget. – user3329922 Mar 7 '14 at 16:57
For the telnet tests, I ran them totally outside the network, via the internet. For the GW-BOX:9093, and the GW-BOX:9091 tests, I ran them outside the network, from GW-BOX, from 9091-Server, and from 9093-Server. The 9091-Server tests work from outside the network and from the 9093-Server. It does not work from 9091-Server or GW-BOX. The 9093-Server test does not work for any box. – user3329922 Mar 7 '14 at 17:05
As for netstat test on the GW-BOX, what is weird is that I get nothing for either 9091 or 9093, but as we have discussed, 9091 works. That was one of the first things I checked. I am guessing that the port does not need to be listening ( from the netstat perspective ) because of iptables. That said, I did run "nmap -sT -O localhost -p 9091,9093", and both ports are referenced. I have another port ( 31006, totally different purpose ) that works fine and looks exactly like 9093 in nmap and netstat. – user3329922 Mar 7 '14 at 17:17
have you considered to try another port, maybe try 9094 instead of 9093 – Sverre Mar 9 '14 at 15:02
George suggested flipping ports above, which I did, with no success. Thanks. – user3329922 Mar 25 '14 at 22:41

Ok, I figured out the issue. GW-BOX is meant to be a gateway box, obviously. But as I said in another thread here, I could not access the internet THROUGH this box. I turns out that once I fixed that inability to access the internet THROUGH this GW-BOX, I was able to use wget just fine. In my case, as per the thread I just mentioned, I had to change the iptables from

iptables-save | grep eth
-A POSTROUTING -o eth1 -j SNAT --to-source 68.AAA.BBB.155


iptables-save | grep eth
-A POSTROUTING -o eth2 -j SNAT --to-source 68.AAA.BBB.155

and now things work. I also setup totally new ports, but I don't think that was the root cause.

Thanks. I hope this helps someone else.

share|improve this answer

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.