Issues with Site to Site VPN (Newly Configured VPN)

[dhyland]

I'm having an issue getting a site to site VPN established and must be overlooking something.  I have the basic setup and NAT configured but, for the life of me, I must be missing something.  Can anyone take a look for me?

ROUTER ONE

crypto isakmp policy 1

   encr 3des

   hash md5

   authentication pre-share

   group 2

   lifetime 86400

crypto isakmp key password address 2.2.2.2

ip access-list extended VPN-TRAFFIC

   permit ip 192.168.200.0 0.0.0.255 192.168.10.0 0.0.0.255

ip access-list extended Test-Network-NAT

   remark =[Deny NAT for VPN]=

   deny ip 192.168.200.0 0.0.0.255 192.168.10.0 0.0.0.255

   remark =[Allow NAT for Test Network to Overload]=

   permit ip 192.168.200.0 0.0.0.255 any

crypto ipsec transform-set TS esp-3des esp-md5-hmac

crypto map CMAP 10 ipsec-isakmp

   set peer 2.2.2.2

   set transform-set TS

   match address VPN-TRAFFIC

interface FastEthernet 0/2/0

   ip address 192.168.200.254 255.255.255.0

   ip nat inside

   no shut

int FastEthernet 0/1   (WAN INTERFACE)

   crypto map CMAP

ip nat inside source list Test-Network-NAT interface FastEthernet 0/1 overload

ip route 192.168.10.0 255.255.255.0 2.2.2.2

ROUTER TWO:

crypto isakmp policy 1

   encr 3des

   hash md5

   authentication pre-share

   group 2

   lifetime 86400

crypto iskmp key password address 1.1.1.1

ip access-list extended VPN-TRAFFIC

   permit ip 192.168.10.0 0.0.0.255 192.168.200.0 0.0.0.255

crypto ipsec transform-set TS esp-3des esp-md5-hmac

crypto map CMAP 10 ipsec-isakmp

   set peer 1.1.1.1

   set transform-set TS

   match address VPN-TRAFFIC

int fast 0    (WAN INTERFACE)

   crypto map CMAP

ip route 192.168.200.0 255.255.255.0 1.1.1.1

NAT for the second router is a little different...

ip nat inside source route-map INTERNET interface FastEthernet0 overload

route-map INTERNET, permit, sequence 1

  Match clauses:

    ip address (access-lists): 198

Extended IP access list 198

    10 deny ip 192.168.10.0 0.0.0.255 192.168.200.0 0.0.0.255 (87 matches)

    20 permit ip 192.168.10.0 0.0.0.255 any (68154178 matches)

    30 permit ip 192.168.11.0 0.0.0.255 any (13246 matches)

    40 permit ip 192.168.15.0 0.0.0.255 any

Any and all input is much appreciated!

[Jouni Forss]

I guess the first thing you might do is try to generate traffic to the L2L VPN connection and then issue the command

show crypto isakmp sa

On the site where you are generating the traffic and see does the Phase 1 go through. If you have continuous ICMP going for example you could issue the above command several times since you might catch an output that is not the one where the Phase1 negotiation is failing at. (Naturally with Phase1 debug you would also see this)

If you have no output at all with the above command then you know the problem is on the local router. Either traffic isnt getting to the router, isnt matching the VPN rules or something to that direction.

If you see output then copy/paste the output here

Have these devices been in place at the sites without the L2L VPN or are these totally new devices on each site that you are just now setting up?

- Jouni

[dhyland]

Thanks for the reply, Jouni.

These devices have been in production for quite some time (not a new deployment).  A 'show crypto isakmp sa' on R2 shows the following  (WAN IPs changed obviously):

IPv4 Crypto ISAKMP SA

dest                      src                 state                              conn-id     slot      status

1.1.1.1                  2.2.2.2            MM_NO_STATE              0             0         ACTIVE

But, on the other end it shows status as ACTIVE (deleted)...

On further inspection, it appears that the VPN traffic coming in on R1 might be coming from R2's secondary WAN connection but I'm fairly certain that my route-maps and NAT overload rules are correct...