Adam, I am not sure how things are configured as I don't administer that part of our LAN. So I point my servers to the gateway, set my netmasks and then tell the upstream folks who has to connect to the server. This has worked for the past three years. Then the upstream folks changed the filter. Now I am not sure where that sits in the mix. So with my limited network knowledge I know that packets from my server go to the gateway. Now I always figured that if all of my switches are on the same switch and the destination is on that switch it would never see the router as the switch should just send the packets down to the next port. But I have always felt that the packets go to our gateway and from there they go to wherever they have to go. In that gateway the port 80 traffic is hijacked and sent first to the web filter.
Now that stated what I did was change the listening port of my troubled server to 8081. Restarted httpd and tehn from the troubled server tried to connect to the web service via port 8081 and I could get there. I then tried from another host and got the same result as I did when the web service was listening on port 80. So that may blow the hijack theory out of the water. Tom suggested a route issue and that is what might be the problem. I am out of the office until Friday and when I get back in I am going to take my netbook and connect to the switch that all my servers are connected to and point my netbook at the troubled server. That way I take the gateway out of the mix and I can prove the troubled server is the problem or not. Stay tuned. ;-) >>> Adam Compton <[email protected]> 01/12/11 4:02 PM >>> On Wed, Jan 12, 2011 at 12:12 PM, John BORIS <[email protected]> wrote: > Adam, > Thanks that does help. The one thing I don't see when I do iptraf is > the TCP handshaking taking place. So somewhere that process is broke. I > want to make sure I dot all of my i's and cross my t's before I go to > the next level. > If you don't see a TCP handshake starting up, the conclusion I would draw is that there's nothing listening on that port. >From the original question: Now on the network side. These machines are on the same switch. same > network but are routed to the main router for the network. That router > hijacks all port 80 traffic and directs it to our web filter, well I > assume that but not sure if you can hijack http traffic. I changed the > listening port of the Web process to 8081 and then retested and got the > same results. > My gut tells me that the problem is with the "hijacks port 80" part of the process. How does that work? What kind of hardware is the router that's implementing it? (Are you sure it's happening where you think it is?) Depending on the mechanism of this hijacking, you might get various kinds of unhelpful information from TCP-level analysis. Here's a test you can try: attempt to connect with telnet to the web filter's listening port and see if it's still listening. If it is listening, then I would investigate the "I'm hijacking port 80 traffic" part of the equation to make sure it's still working properly. If it is not listening, figure that out and then attempt a normal connection again. Do note, it's very possible that both parts are broken, so don't get discouraged. :-) - Adam Compton _______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
