Getting a VPN to work through a Cisco firewall

[rkunkel]

Hello all,

The problem here lies in the firewall blocking VPN traffic. Right now, as a lab, I've got the WAN port of the router set up with a xxx.xxx.xxx.158 255.255.255.252 IP address, and the LAN as a xxx.xxx.xxx.161 255.255.255.224 IP address.

When someone from the outside makes a VPN connection to the router's WAN IP address, it grabs an address from the pool, and work fine as long as the firewall is not in place.

Once the firewall is there, the traffic can't make it back in, despite the fact that the inspect CBAC is suppose to open holes in the firewall. I get log entires like:

-- Nameserver not able to get it's traffic back:

Jan 11 19:37:45.927: %SEC-6-IPACCESSLOGP: list 101 denied udp

xxx.xxx.xxx.10(53) -> xxx.xxx.xxx.182(3758), 1 packet

-- Hitting Yahoo by IP in browser. Traffic not making it back:

Jan 11 19:37:55.875: %SEC-6-IPACCESSLOGP: list 101 denied tcp

66.94.230.34(80) -> xxx.xxx.xxx.182(3759), 1 packet

Note that the "xxx.xxx.xxx.182" IP is the IP that was handed to the VPN client, but that is ACTUALLY out on the Internet.

I have the feeling that I'm missing something dumb, but I just don't know. I usually feel pretty adept at these things.

For your inspection, here are the relevant portions of the config. Also worth noting is that I've let the Cisco SDM write the access list parts of this. I've also tried it by hand, with no success.

ip inspect name DEFAULT100 cuseeme

ip inspect name DEFAULT100 ftp

ip inspect name DEFAULT100 h323

ip inspect name DEFAULT100 icmp

ip inspect name DEFAULT100 netshow

ip inspect name DEFAULT100 rcmd

ip inspect name DEFAULT100 realaudio

ip inspect name DEFAULT100 rtsp

ip inspect name DEFAULT100 esmtp

ip inspect name DEFAULT100 sqlnet

ip inspect name DEFAULT100 streamworks

ip inspect name DEFAULT100 tftp

ip inspect name DEFAULT100 tcp

ip inspect name DEFAULT100 udp

ip inspect name DEFAULT100 vdolive

interface FastEthernet0/0

description $ETH-WAN$$FW_OUTSIDE$

ip address xxx.xxx.xxx.158 255.255.255.252

ip access-group 101 in

ip inspect DEFAULT100 out

crypto map SDM_CMAP_1

interface FastEthernet0/1

description $ETH-LAN$$FW_INSIDE$

ip address xxx.xxx.xxx.161 255.255.255.224

ip access-group 100 in

ip local pool SDM_POOL_1 xxx.xxx.xxx.176 xxx.xxx.xxx.183

access-list 100 remark auto generated by SDM firewall configuration

access-list 100 remark SDM_ACL Category=1

access-list 100 deny ip xxx.xxx.xxx.156 0.0.0.3 any

access-list 100 deny ip host 255.255.255.255 any

access-list 100 deny ip 127.0.0.0 0.255.255.255 any

access-list 100 permit ip any any

access-list 101 remark auto generated by SDM firewall configuration

access-list 101 remark SDM_ACL Category=1

access-list 101 permit udp host 207.244.144.10 eq domain host xxx.xxx.xxx.158

access-list 101 permit udp host 207.244.153.11 eq domain host xxx.xxx.xxx.158

access-list 101 permit ip xxx.xxx.xxx.176 0.0.0.7 any

access-list 101 remark Auto generated by SDM for NTP (123) 72.36.170.170

access-list 101 permit udp host 72.36.170.170 eq ntp host xxx.xxx.xxx.158 eq ntp

access-list 101 permit ahp any host xxx.xxx.xxx.158

access-list 101 permit esp any host xxx.xxx.xxx.158

access-list 101 permit udp any host xxx.xxx.xxx.158 eq isakmp

access-list 101 permit udp any host xxx.xxx.xxx.158 eq non500-isakmp

access-list 101 deny ip xxx.xxx.xxx.160 0.0.0.31 any

access-list 101 permit icmp any host xxx.xxx.xxx.158 echo-reply

access-list 101 permit icmp any host xxx.xxx.xxx.158 time-exceeded

access-list 101 permit icmp any host xxx.xxx.xxx.158 unreachable

access-list 101 deny ip 10.0.0.0 0.255.255.255 any

access-list 101 deny ip 172.16.0.0 0.15.255.255 any

access-list 101 deny ip 192.168.0.0 0.0.255.255 any

access-list 101 deny ip 127.0.0.0 0.255.255.255 any

access-list 101 deny ip host 255.255.255.255 any

access-list 101 deny ip host 0.0.0.0 any

access-list 101 deny ip any any log

Thanks much!

[gfullage]

So the traffic is coming from the VPN client into the outside int, decrypted, then sent back out the outside int to the Internet, correct?

It looks like that because the traffic is coming into and out of the same interface, the inspection and hole opening is not working. This doesn't surprise me as inspection was never really designed for that type of traffic, rather traffic coming in one interface and out another on the router.

You can see by the log messages that it is the return packets that are being denied by ACL 101, so this confirms that the router has not opened a hole for this return traffic when it sees the outgoing traffic.

Probably the only way around this is to allow any traffic destined to your VPN client traffic into the router on ACL 101. Something like:

access-list 101 permit ip any xxx.xxx.xxx.176 0.0.0.7

You already have the inverse of this (any traffic sourced from your VPN clients), but you need to allow the destination as well for the return traffic.

[jackko]

access-list 101, as the inbound acl, needs to permit vpn client pool to router inside subnet.

e.g.

access-list 101 permit ip

the reason being that the router will first decrypt the packet, which originated from the remote vpn client and destined for the router inside subnet. after the decryption of the packet, router will then examine the packet and determine whether the packet is permitted by verifying the inbound acl.

further, in the near future, when you deploy the router into production. please make sure that the vpn client pool doesn't overlap with any router-known subnet.