7.Cisco ASA VPN Filter




The Cisco ASA supports VPN filters that let you filter decrypted traffic that exits a tunnel or pre-encrypted traffic before it enters a tunnel. You can use the VPN filter for both LAN-to-LAN (L2L) VPNs and remote access VPN.

VPN filters use access-lists and you can apply them to:

  • Group policy
  • Username attributes
  • Dynamic access policy (DAP)

A VPN filter attached to username attributes overrules a VPN filter which is attached to a group policy. A VPN filter attached to a DAP overrules VPN filters on both username attributes and a group policy.

In this lesson, I’ll show you how to configure and verify a VPN filter on a remote access VPN using a group policy and username attributes.

1.Configuration

Here is the topology we’ll use for this example:

Asa1 R1 R2 Remote User

The remote user connects with IPSec remote VPN to ASA1 to get access to the 192.168.1.0/24 network. The user can access both routers. We are going to configure the VPN to restrict the traffic from the user to the routers.



We start with a basic remote VPN configuration.

hostname ASA1
!
ip local pool VPN_POOL 192.168.10.100-192.168.10.200
!
interface GigabitEthernet0/0
 nameif INSIDE
 security-level 100
 ip address 192.168.1.254 255.255.255.0 
!
interface GigabitEthernet0/1
 nameif OUTSIDE
 security-level 0
 ip address 10.10.10.1 255.255.255.0 
!
access-list SPLIT_TUNNEL standard permit 192.168.1.0 255.255.255.0 
!
crypto ipsec ikev1 transform-set MY_TRANSFORM_SET esp-aes esp-sha-hmac 
!
crypto dynamic-map MY_DYNA_MAP 10 set ikev1 transform-set MY_TRANSFORM_SET
crypto map MY_CRYPTO_MAP 10 ipsec-isakmp dynamic MY_DYNA_MAP
crypto map MY_CRYPTO_MAP interface OUTSIDE
!
crypto isakmp identity address 
crypto ikev1 enable OUTSIDE
crypto ikev1 policy 10
 authentication pre-share
 encryption aes
 hash sha
 group 2
 lifetime 86400
!
group-policy VPN_POLICY internal
group-policy VPN_POLICY attributes
 dns-server value 8.8.8.8
 vpn-idle-timeout 15
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value SPLIT_TUNNEL
!
username VPN_USER password MY_PASSWORD
tunnel-group MY_TUNNEL type remote-access
tunnel-group MY_TUNNEL general-attributes
 address-pool VPN_POOL
 default-group-policy VPN_POLICY
tunnel-group MY_TUNNEL ipsec-attributes
 ikev1 pre-shared-key MY_SHARED_KEY
!
end
hostname R1
!
no ip routing
!
interface GigabitEthernet0/1
 ip address 192.168.1.1 255.255.255.0
!
ip default-gateway 192.168.1.254
!
end
hostname R2
!
no ip routing
!
interface GigabitEthernet0/1
 ip address 192.168.1.2 255.255.255.0
!
ip default-gateway 192.168.1.254
!
end

I’ll use the Cisco VPN client. Here are the properties of the VPN connection:

Cisco Vpn Client Properties Asa1

Let’s connect:

Cisco Vpn Client Connect Asa1

Once the VPN client is connected, I can ping both routers. Let’s try R1:

C:\Users\h1>ping 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=4ms TTL=255
Reply from 192.168.1.1: bytes=32 time=3ms TTL=255
Reply from 192.168.1.1: bytes=32 time=3ms TTL=255
Reply from 192.168.1.1: bytes=32 time=3ms TTL=255

Ping statistics for 192.168.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 4ms, Average = 3ms

And R2:

C:\Users\h1>ping 192.168.1.2

Pinging 192.168.1.2 with 32 bytes of data:
Reply from 192.168.1.2: bytes=32 time=3ms TTL=255
Reply from 192.168.1.2: bytes=32 time=3ms TTL=255
Reply from 192.168.1.2: bytes=32 time=2ms TTL=255
Reply from 192.168.1.2: bytes=32 time=4ms TTL=255

Ping statistics for 192.168.1.2:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 4ms, Average = 3ms

We have full access to the 192.168.1.0/24 network. Let’s restrict this.

1.1.Group Policy

We’ll start with the group policy option. I will first create an access-list that only permits ICMP traffic to R1:

ASA1(config)# access-list RESTRICT_VPN permit icmp any host 192.168.1.1
I use any as the source but with remote access VPN, you could configure the client source IP address here. For site-to-site connections you can specify the remote network as a source.

We have to apply the access-list to the group policy:

ASA1(config)# group-policy VPN_POLICY attributes
ASA1(config-group-policy)# vpn-filter value RESTRICT_VPN

We need to disconnect and reconnect our VPN client before this setting becomes active. Do this from the VPN client or reset the connection on the ASA:

ASA1# clear crypto ipsec sa

Before we reconnect, let’s enable a debug:

ASA1# debug acl filter

Once you reconnect, you see the following debug lines:

ASA1#
ASA1# ACL FILTER INFO:(ID:0x00007f11b93406a0) first reference to outbound filter RESTRICT_VPN(2): Installing rule into NP.
ACL FILTER INFO:(ID:0x00007f11b99bfbd0) first reference to inbound filter RESTRICT_VPN(2): Installing rule into NP.

The output above tells us that the VPN filter is installed. You can also verify this in the Accelerated Security Path (ASP) table:

ASA1# show asp table filter

Global Filter Table:
in  id=0x7f11b99ce080, priority=13, domain=filter-aaa, deny=false
        hits=0, user_data=0x7f11c485cd00, filter_id=0x2(RESTRICT_VPN), protocol=1
        src ip=0.0.0.0, mask=0.0.0.0, icmp-type=0
        dst ip=192.168.1.1, mask=255.255.255.255, icmp-code=0
in  id=0x7f11b923dac0, priority=12, domain=filter-aaa, deny=true
        hits=4, user_data=0x7f11c485d000, filter_id=0x0(-implicit deny-), protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0
in  id=0x7f11b923e200, priority=12, domain=filter-aaa, deny=true
        hits=0, user_data=0x7f11c485ce80, filter_id=0x0(-implicit deny-), protocol=0
        src ip=::/0, port=0
        dst ip=::/0, port=0
out id=0x7f11b99c34d0, priority=13, domain=filter-aaa, deny=false
        hits=0, user_data=0x7f11c485cc40, filter_id=0x2(RESTRICT_VPN), protocol=1
        src ip=192.168.1.1, mask=255.255.255.255, icmp-type=0
        dst ip=0.0.0.0, mask=0.0.0.0, icmp-code=0
out id=0x7f11b923de60, priority=12, domain=filter-aaa, deny=true
        hits=0, user_data=0x7f11c485cf40, filter_id=0x0(-implicit deny-), protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0
out id=0x7f11b923e5d0, priority=12, domain=filter-aaa, deny=true
        hits=0, user_data=0x7f11c485cdc0, filter_id=0x0(-implicit deny-), protocol=0
        src ip=::/0, port=0
        dst ip=::/0, port=0

The debug and the show command for the ASP table are useful to verify our work from the ASA. Let’s send some pings from H1:

C:\Users\h1>ping 192.168.1.1

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=4ms TTL=255
Reply from 192.168.1.1: bytes=32 time=3ms TTL=255
Reply from 192.168.1.1: bytes=32 time=3ms TTL=255
Reply from 192.168.1.1: bytes=32 time=3ms TTL=255

Ping statistics for 192.168.1.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 4ms, Average = 3ms

Pings to R1 still work. What about R2? Let’s try:

C:\Users\h1>ping 192.168.1.2

Pinging 192.168.1.2 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.1.2:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

These pings fail, as expected. Let’s check the access-list:

ASA1# show access-list RESTRICT_VPN
access-list RESTRICT_VPN; 1 elements; name hash: 0xa57c5d8b
access-list RESTRICT_VPN line 1 extended permit icmp any host 192.168.1.1 (hitcnt=1) 0x4f86339c

Above, you can see we have a hit on the access-list.

1.2.Username Attributes

Instead of the group policy, we can also attach the VPN filter to the username attributes. Let’s give this a shot. I’ll create a new access-list which permits all ICMP traffic:

ASA1(config)# access-list RESTRICT_VPN_USER extended permit icmp any any

Let’s enable this access-list under the username attributes like this:

ASA1(config)# username VPN_USER attributes
ASA1(config-username)# vpn-filter value RESTRICT_VPN_USER

Once you reconnect, we see the following debug lines:

ASA1(config-username)# ACL FILTER INFO:(ID:0x00007f11b99bfbd0) first reference to outbound filter RESTRICT_VPN_USER(3): Installing rule into NP.
ACL FILTER INFO:(ID:0x00007f11b99cce20) first reference to inbound filter RESTRICT_VPN_USER(3): Installing rule into NP.

Notice how the RESTRICT_VPN_USER access-list is applied instead of the RESTRICT_VPN access-list. Applying a VPN filter to the username attributes overrules the group policy settings. Let’s try some quick pings from H1:

C:\Users\h1>ping 192.168.1.1 -n 1

Pinging 192.168.1.1 with 32 bytes of data:
Reply from 192.168.1.1: bytes=32 time=3ms TTL=255

Ping statistics for 192.168.1.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 3ms, Average = 3ms
C:\Users\h1>ping 192.168.1.2 -n 1

Pinging 192.168.1.2 with 32 bytes of data:
Reply from 192.168.1.2: bytes=32 time=2ms TTL=255

Ping statistics for 192.168.1.2:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 2ms, Average = 2ms

As you can see, all ICMP traffic is now permitted. We can also verify this in the ASP table:

ASA1# show asp table filter hits

Global Filter Table:
in  id=0x7f11b99cdda0, priority=13, domain=filter-aaa, deny=false
        hits=2, user_data=0x7f11c485cb80, filter_id=0x3(RESTRICT_VPN_USER), protocol=1
        src ip=0.0.0.0, mask=0.0.0.0, icmp-type=0
        dst ip=0.0.0.0, mask=0.0.0.0, icmp-code=0
in  id=0x7f11b923dac0, priority=12, domain=filter-aaa, deny=true
        hits=4, user_data=0x7f11c485d000, filter_id=0x0(-implicit deny-), protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0
out id=0x7f11b99c55c0, priority=13, domain=filter-aaa, deny=false
        hits=2, user_data=0x7f11c485cd00, filter_id=0x3(RESTRICT_VPN_USER), protocol=1
        src ip=0.0.0.0, mask=0.0.0.0, icmp-type=0
        dst ip=0.0.0.0, mask=0.0.0.0, icmp-code=0

That’s all there is to it.

hostname ASA1
!
interface GigabitEthernet0/0
 nameif INSIDE
 security-level 100
 ip address 192.168.1.254 255.255.255.0 
!
interface GigabitEthernet0/1
 nameif OUTSIDE
 security-level 0
 ip address 172.16.1.1 255.255.255.0 
!
access-list SPLIT_TUNNEL standard permit 192.168.1.0 255.255.255.0 
access-list RESTRICT_VPN extended permit icmp any host 192.168.1.1 
access-list RESTRICT_VPN_USER extended permit icmp any any 
!
crypto ipsec ikev1 transform-set MY_TRANSFORM_SET esp-aes esp-sha-hmac 
crypto ipsec security-association pmtu-aging infinite
crypto dynamic-map MY_DYNA_MAP 10 set ikev1 transform-set MY_TRANSFORM_SET
crypto map MY_CRYPTO_MAP 10 ipsec-isakmp dynamic MY_DYNA_MAP
crypto map MY_CRYPTO_MAP interface OUTSIDE
crypto isakmp identity address 
crypto ikev1 enable OUTSIDE
crypto ikev1 policy 10
 authentication pre-share
 encryption aes
 hash sha
 group 2
 lifetime 86400
!
group-policy VPN_POLICY internal
group-policy VPN_POLICY attributes
 dns-server value 8.8.8.8
 vpn-idle-timeout 15
 vpn-filter value RESTRICT_VPN
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value SPLIT_TUNNEL
username VPN_USER password MY_PASSWORD
username VPN_USER attributes
 vpn-filter value RESTRICT_VPN_USER
tunnel-group MY_TUNNEL type remote-access
tunnel-group MY_TUNNEL general-attributes
 address-pool VPN_POOL
 default-group-policy VPN_POLICY
tunnel-group MY_TUNNEL ipsec-attributes
 ikev1 pre-shared-key MY_SHARED_KEY
!
end
hostname R1
!
no ip routing
!
interface GigabitEthernet0/1
 ip address 192.168.1.1 255.255.255.0
!
ip default-gateway 192.168.1.254
!
end
hostname R2
!
no ip routing
!
interface GigabitEthernet0/1
 ip address 192.168.1.2 255.255.255.0
!
ip default-gateway 192.168.1.254
!
end

2.Conclusion

You have now learned how to use the vpn-filter command to restrict your VPN traffic. I hope you enjoyed this lesson. If you have any questions feel free to leave a comment!

Comments

Post a Comment

Popular posts from this blog

Cisco ASA Packet Drop Troubleshooting

Image
As a firewall, the Cisco ASA drops packets. That’s great until it drops packets that you want to permit, and you have no idea what is going on. Fortunately, the ASA supports different tools to show you why and what packets it drops. In this lesson, we’ll cover the following tools: Connection State Interface Drops Syslog ASP Drops Packet Capture Packet Tracer Service Policy Conclusion Here is the topology I use: We use a simple topology: Two “host” devices: These are routers with ip routing disabled, and they use ASA1 as their default gateway. An HTTP server is enabled on both devices. ASA1 runs ASAv Version 9.9(2) and has two interfaces: INSIDE: security level 100 OUTSIDE: security level 0 In this topology, H1 will be able to initiate a connection to H2. H2 won’t be able to initiate a connection to H1 because we go from a  low-security level (0) to a high-security level (100) . Configurations ASA1 H1 H2 hostname ASA1 ! interface GigabitEthernet0/0 nameif INSIDE security-level 100...
Read more

show asp drop Command Usage

The  show asp drop  command shows the packets or connections dropped by the accelerated security path, which might help you troubleshoot a problem. See the general operations configuration guide for more information about the accelerated security path. This information is used for debugging purposes only, and the information output is subject to change. Consult Cisco TAC to help you debug your system with this command. The following sections include each drop reason name and description, including recommendations: rame Drop Reasons   ---------------------------------------------------------------- Name: natt-keepalive NAT-T keepalive message: This counter will increment when the appliance receives an IPSec NAT-T keepalive message. NAT-T keepalive messages are sent from the IPSec peer to the appliance to keep NAT/PAT flow information current in network devices between the NAT-T IPSec peer and the appliance.   Recommendation: If you have configured IPSec NAT-T on your ...
Read more

1.Cisco ASA Clock Configuration

The Cisco ASA firewall has a battery on the motherboard that saves the clock settings. Even when it’s is powered off, the clock will be stored. There are two important reasons why you want to make sure that your ASA has the correct date/time: In case of a security breach you want to track log files for events. With an incorrect timestamp, your log files are useless. PKI (Public Key Infrastructure) that we use for digital certificates to authenticate remote users (IPSEC or SSL VPN) requires the correct date/time. The most simple method is to configure the date/time manually, you can do it like this: ASA1(config)# clock set 13:15:00 Dec 19 2014 Just use the  clock set  command and enter the correct time/date. You can verify it like this: ASA1# show clock 13:15:15.709 UTC Fri Dec 19 2014 As you can see, the default timezone is UTC. If you are in another timezone like me then you have to change this: ASA1(config)# clock timezone CET +1 Use the  clock timezone  command t...
Read more