This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

cannot http to server but I can ping it (What else should I analyze?)

0

I have a web server running nagios. When I web to it appears to be getting blocked or not routed from the wireshark output below.

I can ping it and the icmp traffic does appear in Wireshark and I get a proper reply. What can I look at to help me find what is not routing or is blocking it??

52878  >http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8 SACK_perm=1)
52878  >http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8 SACK_perm=1)
52878  >http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=8 SACK_perm=1)

asked 10 Jul '14, 11:20

parakiteiz's gravatar image

parakiteiz
11337
accept rate: 0%

edited 10 Jul '14, 11:29

Were the three packets you included captured on the client, or the server? And is the Nagios server unix-based?

(10 Jul '14, 12:08) smp

These 3 packets are captured from the client having the problem. Yes it is a Linux server but from my comments below I down even think it is making it that far.

Second look it appears the destination is All-HSRP-router_fd (00:00:0c:07:ac:fd). Which is a HSRP interface on my 3750 switch with the ip of ..253.1. It appears to not be routing on to the 1.0 subnet (vlan 255). When I do a sh ip route I see subnet 1.0 directly connected via vlan 255. So there should be no problems here?

Third Look: I just did a tracert to 1.89. Wireshark just loaded up on a bunch of Time- to exceeded to live exceeded (Time to live exceeded in transit). I also notice when I ping the address 1.89 I get a TTL of 63 when it is only 2 or 3 devices away. Looks like routing or switching issue.

What can I do to tie it down to a device?

(10 Jul '14, 12:36) parakiteiz
1

This type of L2/L3 problem is a bit out of my element, and I'm not sure this is the forum to get answers to that question. However I am forced to diagnose this type of issue all the time, and there's a simple way to confirm your theory that this is a L2/L3 problem. Simply perform network traces simultaneously on both the client and the server. You should see the SYN packet leave the client, and you should see it arrive on the server. If it doesn't arrive, then you know the problem is in the middle. If it arrives on the server, then there's something on the server (iptables?) filtering out the packet.

Good luck.

(10 Jul '14, 12:40) smp

Looks like routing or switching issue.

If you can ping the same host, but you can't connect to port 80, it's most certainly not a routing/switching problem, otherwise the ping would not work either!

(10 Jul '14, 12:50) Kurt Knochner ♦

The two hosts that appear to be problematic 1.89 and 1.234. When I try to http or https to them it goes like this:

66 62397 > http [SYN} Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1 (Green0
66 [TCP Retransmission] 62397 > http [SYN} Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
62 [TCP Retransmission] 62397 > http [SYN} Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1

It still appears have that type of traffic hanging on the HSRP mac address (Dst: All-HSRP-Routers_fd (Cisco MAC Adress for vlan and not routing past.

What else should I be looking for?

(15 Jul '14, 10:41) parakiteiz

A firewall!

(15 Jul '14, 10:56) Kurt Knochner ♦

I checked the logs on both firewalls; twice. These hosts did not appear in the logs. We have do have firewalls on our development LAN to separate subnets to emulate production environment.

(15 Jul '14, 12:44) parakiteiz

I checked the logs on both firewalls; twice.

If there is a block rule without logging, you won't see anything in the logs.

(15 Jul '14, 12:55) Kurt Knochner ♦

I created a span port on the same switch and used the same ip address since I did not hear back from you. I Http'ed to 1.89 from the my workstation and this was the output [TCP Previous segment lost] http 51048 [SYN, ACK] Seq469244521 Win=14600 LEN=0 MSS=1460 [TCP Previous segment lost] http 51048 [SYN, ACK] Seq=140687248 Win=14600 LEN=0 MSS=1460

When you dig in to the SEQ/ACK analysis you get This is an ACK to the segment in frame:12040 When you dig in to the TCP Analysis Flags you get: [Expert Info (Warn/Sequence): Previous segmentlost (common at capture start)] [Message: Previous Segment lost (common at capture start)] [Severity Level: warn] [Group:Sequence]

So it looks like my SYN packets are making it there just the ACK packets are getting lost?

What should I look for next?

(17 Jul '14, 14:38) parakiteiz
showing 5 of 9 show 4 more comments

One Answer:

0

Thanks all for you assistance. This appeared to be a self inflicted Routing Issue. On my switch04 I had give int vlan 255 a IP address of ..1.26 which made everything on that VLAN route VLAN 255 no the static route that existed. This appeared to be causing a routing loop.

I finally figured out my staring at my sh ip route output for like an hour. I then shut the int vlan 255 interface and saw it changed my sh ip route interface and fixed the problem.

answered 03 Sep '14, 07:40

parakiteiz's gravatar image

parakiteiz
11337
accept rate: 0%