VPN Tunnel = Router To ASA

Hi All,

I am setting up an Cisco 2611 Router to establish an IPsec VPN Tunnel to an Cisco ASA.

As for the Cisco ASA, I am using the ASDM GUI so am not to worried about configuring on this end, however I am using the CLI on the Router and wanted to double check my config with you people.

Crypto Policy:

!
!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
group 2
crypto isakmp key Festival161# address **.***.**.***
!
!

Transform Set:

!
!
crypto ipsec transform-set TUNNEL_TO_ASA esp-3des esp-md5-hmac
!
!

Crypto Map:

!
!
crypto map TUNNEL_TO_ASA 1 ipsec-isakmp
description ***Tunnel To Delft ASA***
set peer **.***.**.***
set transform-set TUNNEL_TO_ASA
match address 110
!
!

ACL's:

!
!
ip access-list extended VPN
permit esp host **.***.**.*** host **.***.**.***
permit ahp host **.***.**.*** host **.***.**.***
permit udp host **.***.**.*** host **.***.**.*** eq isakmp
permit gre **.***.**.*** host **.***.**.***
!
!
access-list 110 permit ip 172.16.161.0 0.0.0.255 any
access-list 110 deny ip 172.16.161.0 0.0.0.255 172.16.0.0 0.15.255.255
access-list 110 deny ip 172.16.161.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 110 deny ip 172.16.161.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 110 deny ip 172.16.161.0 0.0.0.255 192.168.2.0 0.0.0.255
!
!

I am missing anything, clearly cant seem to see the established SA?

Find more posts tagged with

Comments

burbankmarc

Make sure you exempt all of your interesting traffic from being NAT'd. I've ran into that problem a couple of times.

jovan88

uhh your vpn key is showing

RS_MCP

burbankmarc wrote: »

Make sure you exempt all of your interesting traffic from being NAT'd. I've ran into that problem a couple of times.

!
!
ip nat inside source list 110 interface Ethernet0/0 overload
!
!
access-list 110 permit ip 172.16.161.0 0.0.0.255 any
access-list 110 deny ip 172.16.161.0 0.0.0.255 172.16.0.0 0.15.255.255
access-list 110 deny ip 172.16.161.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 110 deny ip 172.16.161.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 110 deny ip 172.16.161.0 0.0.0.255 192.168.2.0 0.0.0.255
!
!
!

Permit the LAN traffic through NAT but not the interesting traffic.

Does this make sense to your quote?

burbankmarc

I'm not sure what subnet you're trying to connect to, so I'll use 192.168.1.0/24 as an example.

In your NAT acl you want to deny all vpn traffic so it'd look like this:

access-list 110 deny ip 172.16.161.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 110 permit ip 172.16.161.0 0.0.0.255 any

The reason for this is is NAT happens before it hits the crypto map, so if you don't deny it it will be NAT'd and not hit your crypto-map acl.

peanutnoggin

burbankmarc wrote: »

The reason for this is is NAT happens before it hits the crypto map, so if you don't deny it it will be NAT'd and not hit your crypto-map acl.

Not adding too much to this thread, but I was recently reading about Cisco's Order of Operation and came across this link. This is just reinforcement to what Burbankmarc is saying about traffic performing NAT before it hits the crypto map. HTH.

-Peanut

kalebksp

RS_MCP wrote: »

!
!
ip nat inside source list 110 interface Ethernet0/0 overload
!
!
access-list 110 permit ip 172.16.161.0 0.0.0.255 any
access-list 110 deny ip 172.16.161.0 0.0.0.255 172.16.0.0 0.15.255.255
access-list 110 deny ip 172.16.161.0 0.0.0.255 10.0.0.0 0.255.255.255
access-list 110 deny ip 172.16.161.0 0.0.0.255 192.168.1.0 0.0.0.255
access-list 110 deny ip 172.16.161.0 0.0.0.255 192.168.2.0 0.0.0.255
!
!
!

That access list would permit all traffic from 172.16.161.0/24. ACLs work based on first match so the four deny statements don't do anything. The more specific rules should come before the less specific.

shednik

kalebksp wrote: »

That access list would permit all traffic from 172.16.161.0/24. ACLs work based on first match so the four deny statements don't do anything. The more specific rules should come before the less specific.

I'll second this, and what are the tunnels doing exactly? I've seen funky instances with Cisco to Checkpoint devices where the Cisco side of the tunnel came up where as the Checkpoint side was failing on the encryption domain. Cisco to Cisco usually is easier to get talking. Fix what kalebksp suggested and see if it works. If it doesn't a sh crypto session from the router and a sh isakmp/ipsec sa from the asa will help and a look at your config on the ASA as well.