David, When I changed the port I left the IP the same. So I lean toward the Firewall.acl/iptables issue. One thing I can't check and have to depend on the upstream folks.
>>> <da...@lang.hm> 01/12/11 4:52 PM >>> On Wed, 12 Jan 2011, John BORIS wrote: > 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. if all you changed was the port number, and no IP addresses changed, then it's far more likely that you have a firewall / ACL problem than a route problem. Just confirming that the IP address didn't change on either end, correct? > 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. if you can login to a different server on the network and run lynx from there, if it works you know it's something in the network (probably a firewall) if it doesn't work from another machine on the same network, it's not a route issue. At that point it would probably be a firewall type issue on the receiving server (I say firewall type issue as it could be iptables rules, or SELinux rules, or AppArmor rules, but if you can get to it locally, probably iptables rules) David Lang > Stay tuned. > ;-) > > > >>>> Adam Compton <compt...@gmail.com> 01/12/11 4:02 PM >>> > On Wed, Jan 12, 2011 at 12:12 PM, John BORIS <jbo...@adphila.org> 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 > Tech@lists.lopsa.org > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ > _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
