07-30-2008 08:55 AM - edited 02-21-2020 03:51 PM
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
07-30-2008 09:31 AM
Your crypto ACL suggests that you have overlapping address space at each end of the tunnel.
07-30-2008 11:22 AM
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
07-30-2008 12:02 PM
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?
07-30-2008 12:13 PM
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
08-01-2008 12:26 AM
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
08-01-2008 10:19 AM
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.
07-30-2008 09:46 AM
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).
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide