VPN issue - 1 host within tunnel not communicating/traffic not encrypting


-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?
Who is Participating?
SimplyNerdyAuthor Commented:
It was a bug within the IOS.
My first thought was an off-by-one error.  I would recheck the numbers on BOTH sides to be sure that:

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
SimplyNerdyAuthor Commented:
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
SimplyNerdyAuthor Commented:
Because that's what it was
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.