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

Can connect to certain hosts on segment, not others

0

I have a server sitting on a 192.168.194.0/24 network and a vpn connection to 10.0.3.0/24. There is no problem with the vpn.

From my server at 192.168.194.10 I can ping the inside of the remote firewall at 10.0.3.2.

I can also ping a remote server at 10.0.3.7.

I can also ping an XP workstation at 10.0.3.59

I however cannot ping a printer 10.0.3.8 I cannot ping a switch at 10.0.3.6 I cannot ping another XP pc at 10.0.3.60

Locally on the server 10.0.3.7 I can ping every device mentioned so far, so they all are up, they are all valid addresses/hosts, and there are no windows firewalls or anything else blocking icmp.

10.0.3.2 and 10.0.3.8 are my two devices I'm concerned with below. I tried to ping and traceroute each from 192.168.194.10 in the following.

Pings (filtering for just ICMP):

39  51.820697   192.168.194.10  10.0.3.2    ICMP    78  Echo (ping) request  id=0x0001, seq=2585/6410, ttl=128
40  51.875291   10.0.3.2    192.168.194.10  ICMP    78  Echo (ping) reply    id=0x0001, seq=2585/6410, ttl=64
41  52.822254   192.168.194.10  10.0.3.2    ICMP    78  Echo (ping) request  id=0x0001, seq=2586/6666, ttl=128
42  52.875031   10.0.3.2    192.168.194.10  ICMP    78  Echo (ping) reply    id=0x0001, seq=2586/6666, ttl=64
43  53.820667   192.168.194.10  10.0.3.2    ICMP    78  Echo (ping) request  id=0x0001, seq=2587/6922, ttl=128
44  53.873994   10.0.3.2    192.168.194.10  ICMP    78  Echo (ping) reply    id=0x0001, seq=2587/6922, ttl=64
45  54.819111   192.168.194.10  10.0.3.2    ICMP    78  Echo (ping) request  id=0x0001, seq=2588/7178, ttl=128
46  54.870133   10.0.3.2    192.168.194.10  ICMP    78  Echo (ping) reply    id=0x0001, seq=2588/7178, ttl=64
49  61.760306   192.168.194.10  10.0.3.8    ICMP    78  Echo (ping) request  id=0x0001, seq=2591/7946, ttl=128
51  66.441429   192.168.194.10  10.0.3.8    ICMP    78  Echo (ping) request  id=0x0001, seq=2592/8202, ttl=128
52  71.433282   192.168.194.10  10.0.3.8    ICMP    78  Echo (ping) request  id=0x0001, seq=2593/8458, ttl=128
53  76.441170   192.168.194.10  10.0.3.8    ICMP    78  Echo (ping) request  id=0x0001, seq=2594/8714, ttl=128

Notice no replies from 10.0.3.8, just 4 requests.

Tracert to 10.0.3.8:

21  22.700678   192.168.194.10  10.0.3.8    NBNS    96  Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
22  24.212666   192.168.194.10  10.0.3.8    NBNS    96  Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
23  25.725853   192.168.194.10  10.0.3.8    NBNS    96  Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
24  27.243319   192.168.194.10  10.0.3.8    ICMP    110 Echo (ping) request  id=0x0001, seq=2614/13834, ttl=1
25  27.295349   10.0.3.8    192.168.194.10  ICMP    138 Time-to-live exceeded (Time to live exceeded in transit)
26  27.295929   192.168.194.10  10.0.3.8    ICMP    110 Echo (ping) request  id=0x0001, seq=2615/14090, ttl=1
27  27.345990   10.0.3.8    192.168.194.10  ICMP    138 Time-to-live exceeded (Time to live exceeded in transit)
28  27.346555   192.168.194.10  10.0.3.8    ICMP    110 Echo (ping) request  id=0x0001, seq=2616/14346, ttl=1
29  27.401331   10.0.3.8    192.168.194.10  ICMP    138 Time-to-live exceeded (Time to live exceeded in transit)
30  27.402140   192.168.194.10  10.0.3.8    NBNS    96  Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
31  28.908360   192.168.194.10  10.0.3.8    NBNS    96  Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
32  30.422128   192.168.194.10  10.0.3.8    NBNS    96  Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
33  32.886648   192.168.194.10  10.0.3.8    ICMP    110 Echo (ping) request  id=0x0001, seq=2617/14602, ttl=2
34  36.412637   192.168.194.10  10.0.3.8    ICMP    110 Echo (ping) request  id=0x0001, seq=2618/14858, ttl=2
35  40.407571   192.168.194.10  10.0.3.8    ICMP    110 Echo (ping) request  id=0x0001, seq=2619/15114, ttl=2

and that continues the same up to packet 41.

Any ideas?

asked 11 Jan '13, 09:13

Willmeister's gravatar image

Willmeister
6446
accept rate: 0%

edited 11 Jan '13, 09:23

cmaynard's gravatar image

cmaynard ♦♦
9.4k1038142

That got real ugly when i submitted it...sorry :)

(11 Jan '13, 09:14) Willmeister
1

Set the text as a "code sample", so it should be easier to read now.

(11 Jan '13, 09:25) cmaynard ♦♦

I also uploaded the tracert capture to https://www.cloudshark.org/captures/4f231cf04349

Thank you!

(11 Jan '13, 09:27) Willmeister

2 Answers:

0

That is a thought, but they all have the same gateway. I can get to all the devices from another remote subnet.

O.K. then the default gateway on subnet 10.0.3.0/24 is either not set correctly for all devices, or the connections from the other remote subnet are hidden (NAT) behind the internal IP of your firewall (10.0.3.2).

Can you please run tcpdump (or whatever capture tool your firewall provides) on the firewalls internal interface? If you see the ICMP request go to 10.0.3.8 (and 10.0.3.60), but you don't get a response, then the back route (default gateway) is not set correctly on those systems, or they have a wrong ARP cache entry for 10.0.3.2 (your firewall).

I however cannot ping a printer 10.0.3.8 I cannot ping a switch at 10.0.3.6 I cannot ping another XP pc at 10.0.3.60

Just a dump idea. Did you check, that there is no 'historic' route for those IP addresses on the involved firewalls (both ends of the VPN tunnel)? However, then it probably would not work from another subnet either...

Are you really sure, there are packet filter rules to allow those packets on the involved firewalls?

To sum it up, please check these items:

  • double check (again ;-)) the default route on all systems you cannot reach (printer, switch, WinXP). Don't assume anything (or believe what you were told), just check it ;-))
  • check the routes on all involved firewalls, if there are old/historic routes for the IP addresses you cannot reach
  • check if the packet filters are set correctly on all involved firewalls
  • capture on the internal interface of your firewall (10.0.3.2) to verify that the ICMP requests really leave the firewall towards the target systems
  • check if there are wrong/old ARP cache entries on the systems you cannot reach (printer, switch and WinXP)
  • check if the WinXP system (10.0.3.60) has other interfaces in the subnet of your server (192.168.194.0/24), like VMware virtual interfaces (vmnet1, vmnet8): route print | find "192.168."

Regards
Kurt

answered 11 Jan '13, 12:26

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 11 Jan '13, 13:11

OK, it's a new customer and I have very limited access to their equipment, I'm on a box that i can ping the devices across the tunnel...and sure enough, gateway was incorrect. Pleaded for another look and sure enough...you have to be like House. Never trust the patient :) Thanks, good to have the extra advice coming in, sometimes you need to step back. Thank you!

(11 Jan '13, 15:20) Willmeister

As I like to say during Sharkfest...if you hear hooves beating, think horses and not zebras (Unless you live in Africa, LOL)

(12 Jan '13, 18:51) hansangb

1

I would guess that the devices you can't ping don't have default gateways/routers configured. So they can talk to anything on their subnet but nothing beyond the subnet.

answered 11 Jan '13, 10:16

JeffMorriss's gravatar image

JeffMorriss ♦
6.2k572
accept rate: 27%

Printers typically don't get the usual "love" of PCs, so it is probably using the natural subnet mask of /8. And with proxy-arp turned off at the router (likely scenario), the return packets cannot make it back to you (can't get out of the local subnet). I would think the same is true for the XP.

(11 Jan '13, 10:27) hansangb

That is a thought, but they all have the same gateway. PC's are getting the same ipconfig from DHCP and I can get to some, not others. It's also why i mentioned other types of devices, most notably the switch. I can get to all the devices from another remote subnet.

(11 Jan '13, 12:13) Willmeister