VPN Established but no traffic will pass

Unanswered Question
Jul 30th, 2008
User Badges:

Hi All!


I hope you can help. We have establiseh a VPN connection with a 3rd party using the config below...


version 12.4

service timestamps debug datetime msec

service timestamps log datetime msec

service password-encryption

!

hostname VPN-1

!

!

crypto isakmp policy 1

authentication pre-share

crypto isakmp key ******* address 10.1.1.1

!

!

crypto ipsec transform-set GLOBAL esp-des

!

crypto map MAP 1 ipsec-isakmp

set peer 10.1.1.1

set transform-set GLOBAL

match address ACL

!

!

!

interface Loopback1

ip address 192.168.100.1 255.255.255.248

!

interface FastEthernet0/0

ip address 11.x.x.1 255.255.255.240

ip virtual-reassembly

ip tcp adjust-mss 1380

speed 100

full-duplex

crypto map MAP

!

interface FastEthernet0/1

ip address 192.168.200.1 255.255.248.0

ip virtual-reassembly

ip tcp adjust-mss 1380

speed 100

full-duplex

!

ip classless

ip route 0.0.0.0 0.0.0.0 11.1.1.2


!

no ip http server

no ip http secure-server


ip access-list extended ACL

permit ip 192.168.100.0 0.0.0.7 192.168.100.0 0.0.255

I can see that the VPN establishes but no traffic seems to go down the tunnel, when I run a 'sho cry ips sa' I see various a number of send errors.


The traffic I am trying to send is a ping test, sourceds from the loopback interface.


Any help would be greatly appreciated


Kind Regards


Steve

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
michael.leblanc Wed, 07/30/2008 - 09:31
User Badges:
  • Silver, 250 points or more

Your crypto ACL suggests that you have overlapping address space at each end of the tunnel.




AxiomConsulting Wed, 07/30/2008 - 11:22
User Badges:

Michael,

Thank you for your response. I will try to explain why they overlap...


Our client has given us the range 192.168.100.0 255.255.255.248 to participate on their network, 192.168.100.0 255.255.255.0. Therefore if the overlapping ACLs is the problem (in which I suspect you are correct) how do I get around this?


Again, thanks in advance for your help!


Steve



michael.leblanc Wed, 07/30/2008 - 12:02
User Badges:
  • Silver, 250 points or more

First, make sure you correct the mask in the crypto ACL, per my other post.


You should check with the other admin and make sure your crypto ACLs are exact mirrors of each other. It wouldn't be a bad idea to put a sniffer on the WAN side to see if you can detect asymmetrical operation (packets that should be encapsulated, but are not).


It looks like the pool (192.168.100.0 255.255.255.248) is not part of a policy push from the other crypto endpoint.


Are they actually using a /24 mask on their side, or is that an assumption on your part?


Could it be that they are actually using a mask greater than /24 so as to not have an overlap?


My concern was how a host on the far side with a /24 mask would initiate/respond to a host on your side. The host on their side would ARP your host believing it was directly reachable, due to the mask.


Perhaps this might be resolved with "ip proxy-arp" configured on the internal interface of their router.


Is their 192.168.100.0 /? network the connected network on the inside of their router, or buried deeper in their topology?


AxiomConsulting Wed, 07/30/2008 - 12:13
User Badges:

Michael,


Thanks for your help, I will be in contact with the remote admin tomorrow, I will find out that the ACLs definately mirror / subnet masks etc. Also the wildcasd mask mistake in the original post was my typo, not from the 'live' config.


I'll keep you and the board posted on my progress.


Steve

AxiomConsulting Fri, 08/01/2008 - 00:26
User Badges:

Michael,


Just to let you know that Phase 2 of the VPN negotiation was failing, as there was a mis-match in the transform set. Once this was recified traffic flow started as expected!...Thanks for you help.


Steve

michael.leblanc Fri, 08/01/2008 - 10:19
User Badges:
  • Silver, 250 points or more

Steve:


An earlier post indicated:


"I can see that the VPN establishes but no traffic seems to go down the tunnel, when I run a 'sho cry ips sa' I see various a number of send errors."


You might want to revise the criteria that you were you using, that lead you to erroneously conclude that the VPN was being established.


I suspect the "sh crypto ipsec sa" output for that protected flow, would not have had SPIs listed under the the "inbound esp sas:" and "outbound esp sas:" sections, if Phase 2 had not completed successfully. However, that is an "opinion".


Glad you were able to bring the situation to a successful conclusion.


michael.leblanc Wed, 07/30/2008 - 09:46
User Badges:
  • Silver, 250 points or more

One of the masks in your crypto ACL is also missing an octet.


permit ip 192.168.100.0 0.0.0.7 192.168.100.0 0.0.255


Edit: Assuming the same error was not entered on the other tunnel endpoint, your crypto ACLs would not be symmetrical (mirrored).

Actions

This Discussion