SimplyNerdy
asked on
VPN issue - 1 host within tunnel not communicating/traffic not encrypting
Situation:
-We have a VPN tunnel between 2 of our sites. On one side, 5 individual hosts are permitted access (side A) to an entire subnet range on the other side (side B), and vice versa.
-4 of the hosts on side A are able to effectively communicate with the subnet range in side B
-1 host in Side A is not reachable from any other host in the opposite subnet on the other side of the tunnel. It *is*, however, able to communicate with a 3rd site that has a separate tunnel built up
-On the firewall for side B, a sh crypto ipsec peer command shows that, as it pertains to the problem host, ping packets being sent across the tunnel from the host are being decrypted, but no packets on the side opposite that tunnel are being encrypted.
-Obviously, ping tests from the individual problem host on Side A to side B (and B to A) are failing.
-Traceroutes from Side A die out after reaching the VPN peer on Side A. There is no tracerouting possible on Side B (by design)
So it seems to me that the problem might be associated with the firewall on side B. But the rest of the tunnel performs as normal. It should be noted that this connectivity problem is new, used to work previously, and to our knowledge, nothing was changed on either side of the tunnel to precipitate the breakage.
Troubleshooting steps thus far included bouncing the tunnel, tearing down the entire crypto map and re-adding it, rebooting the machine nobody from Side B can reach
Potential causes?
-We have a VPN tunnel between 2 of our sites. On one side, 5 individual hosts are permitted access (side A) to an entire subnet range on the other side (side B), and vice versa.
-4 of the hosts on side A are able to effectively communicate with the subnet range in side B
-1 host in Side A is not reachable from any other host in the opposite subnet on the other side of the tunnel. It *is*, however, able to communicate with a 3rd site that has a separate tunnel built up
-On the firewall for side B, a sh crypto ipsec peer command shows that, as it pertains to the problem host, ping packets being sent across the tunnel from the host are being decrypted, but no packets on the side opposite that tunnel are being encrypted.
-Obviously, ping tests from the individual problem host on Side A to side B (and B to A) are failing.
-Traceroutes from Side A die out after reaching the VPN peer on Side A. There is no tracerouting possible on Side B (by design)
So it seems to me that the problem might be associated with the firewall on side B. But the rest of the tunnel performs as normal. It should be noted that this connectivity problem is new, used to work previously, and to our knowledge, nothing was changed on either side of the tunnel to precipitate the breakage.
Troubleshooting steps thus far included bouncing the tunnel, tearing down the entire crypto map and re-adding it, rebooting the machine nobody from Side B can reach
Potential causes?
ASKER
It's not going to be any sort of a subnetting issue. Again, the the hosts used to be able to communicate without issue.
That is new information.
Have you looked for any changes on either firewall or the affected host immediately preceeding the problem?
Did the host have a change of IP Address?
Assuming that you backup your firewalls after each settings change, you could try restoring to earlier configurations one at a time testing in between?
- Tom
Have you looked for any changes on either firewall or the affected host immediately preceeding the problem?
Did the host have a change of IP Address?
Assuming that you backup your firewalls after each settings change, you could try restoring to earlier configurations one at a time testing in between?
- Tom
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Because that's what it was
1. Both sides use the same ranges
That both define the Side A Range the same. And, both sides define the Side B Range the same.2. The math defining each range is correct.
In particular the definition of the Side B Range (the one with 5 hosts) but both should be reviewed. Depending on the firewalls involved and how these ranges are defined. For normal subnet definitions, one must subtract 2 from the subnet definition to determine the actual number of hosts allowed on a said subnet. Thus, a subnet with 8 addresses only supports 6 host addresses, INCLUDING the gateway address.3. Any masking involved aligns properly with desired ranges
If any masks are used to define the ranges, be sure that the masks accommodate enough address space for the desired number of hosts, including the gateway address.Not having all the details, that is my first thought.- Tom