2

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.
[wmsodbc]> 

But port 9093 did not work:

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

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?

3
  • Is your service running? Mar 6, 2014 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.
    – Tony B
    Mar 7, 2014 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, 2014 at 15:04

3 Answers 3

1

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

to

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.

0

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.

7
  • 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?
    – Tony B
    Mar 7, 2014 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.
    – Tony B
    Mar 7, 2014 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? Mar 8, 2014 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.
    – Tony B
    Mar 25, 2014 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 www.apple.com inside the network would not work, but ping of www.apple.com 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.
    – Tony B
    Mar 26, 2014 at 16:02
0

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
5
  • 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.
    – Tony B
    Mar 7, 2014 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.
    – Tony B
    Mar 7, 2014 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.
    – Tony B
    Mar 7, 2014 at 17:17
  • have you considered to try another port, maybe try 9094 instead of 9093
    – Sverre
    Mar 9, 2014 at 15:02
  • George suggested flipping ports above, which I did, with no success. Thanks.
    – Tony B
    Mar 25, 2014 at 22:41

You must log in to answer this question.

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