• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 597
  • Last Modified:

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?
0
SimplyNerdy
Asked:
SimplyNerdy
  • 3
  • 2
1 Solution
 
TomRScottCommented:
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
0
 
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.
0
 
TomRScottCommented:
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
0
 
SimplyNerdyAuthor Commented:
It was a bug within the IOS.
0
 
SimplyNerdyAuthor Commented:
Because that's what it was
0

Featured Post

SMB Security Just Got a Layer Stronger

WatchGuard acquires Percipient Networks to extend protection to the DNS layer, further increasing the value of Total Security Suite.  Learn more about what this means for you and how you can improve your security with WatchGuard today!

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now