Friday, February 19, 2010

Cisco SSL-VPN LAN Access with Zone Based Policy Firewall

Well this is my first real post. I spent a good deal of time trying to iron this out and I didn't find any documentation on how to mesh these two on Cisco.com beyond a Support Community thread.

https://supportforums.cisco.com/message/3021867#3021867

I did find this tiny little blurb however after I resolved my issue and was scouring for this post.

http://www.cisco.com/en/US/partner/docs/ios/sec_secure_connectivity/configuration/guide/sec_ssl_vpn.html#wp1462114

The underlying issue is that SSLVPN on releases somewhere around 12.4(20)T SSLVPN virtual interfaces are now handled differently according to BugID CSCsr41631. There is no detail that I could track down as to what changed, but essentially we have to get the SSLVPN-VIF interface into our internal security zone to access the LAN or whatever security zones or policies you would like to access over the VPN.

My best guess is that if this worked on earlier releases, that maybe the SSLVPN-VIF interfaces were treated as part of the self zone which is a default pass to with all security zones unless a zone-pairs have been defined with the self zone. But I wasn't able to find anything to support this. If I get motivated one day, maybe I'll load something older and see what I find.

Here is what you will need to do to enable this. This was completed on a Cisco 871 running 15.0(1)M1 Advanced IP Services.

Note: The ZBPF configuration listed below is barebones and included to add relevance to the posted configuration.

class-map type inspect match-any BASE-FW
match protocol tcp
match protocol udp
!
policy-map type inspect IN->OUT-FW
class type inspect BASE-FW
inspect
class class-default
drop
!
zone security OUTSIDE
description External Security Zone
zone security INSIDE
description Internal Security Zone
zone-pair security IN->OUT source INSIDE destination OUTSIDE
service-policy type inspect IN->OUT-FW
!
interface
description Outside Interface
ip address dhcp
no ip redirects
no ip proxy-arp
ip nat outside
no ip virtual-reassembly
zone-member security OUTSIDE
!
interface Virtual-Template1
ip unnumbered
ip nat inside
no ip virtual-reassembly
zone-member security INSIDE
!
interface
description Inside Interface
ip address 192.168.88.254 255.255.255.0
ip nat inside
no ip virtual-reassembly
zone-member security INSIDE
!
ip local pool VPN-Pool 192.168.188.1 192.168.188.6
!
webvpn gateway gateway_1
hostname MyAccess
ip interface port 443
ssl trustpoint TP-self-signed-1957322446
inservice
!
webvpn install svc flash:/webvpn/anyconnect-win-2.4.1012-k9.pkg sequence 1
!
webvpn install svc flash:/webvpn/anyconnect-macosx-i386-2.4.1012-k9.pkg sequence 2
!
webvpn context SSL-VPN
secondary-color white
title-color #669999
text-color black
ssl authenticate verify all
!
!
!
policy group policy_1
functions svc-enabled
mask-urls
svc address-pool "VPN-Pool"
svc keep-client-installed
svc split include 192.168.88.0 255.255.255.0
virtual-template 1
default-group-policy policy_1
aaa authentication list default
gateway gateway_1
inservice
!
end

Once I completed this the first time around, it didn't work for me. I had previously connected to the router with the AnyConnect client before defining the virtual-template interface. I found that I had to reboot the router to get it to work. I did try pulling the context out of service and back in but that didn't help. Maybe removing and reapplying the webvpn configuration might work, but this was my home network and a reload is easy to accomplish. You might wish to try some options I suggest above in a production enviroment before you have to schedule downtime.

No comments: