The only thing between the servers I am testing is the electronics of the switch. they attach to the same switch.
>>> <da...@lang.hm> 01/12/11 5:10 PM >>> On Wed, 12 Jan 2011, John BORIS wrote: > 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. if you have other servers on the same network, you can check and see if it's a firewall between networks, or something like iptables on the destination server. David Lang >>>> <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/
