VPN-Filter v Interface ACLs on ASA 5525

j44mistry · ‎03-20-2013

Hello,

I need some clarification on the differences between a VPN-Filter v an Interface filter.

I am using an ipsec crypto tunnel between our site using ASA 5525 and a remote client who are using a Palo Alto Firewall.

I have applied a vpn-filter on the tunnel for these sites but I am being told that an interface filter would have been more simplier.

In terms of security which method is the best approach ?

Jay

Jouni Forss · ‎03-20-2013

Hi,

I have looked at the comparison "Interface ACL vs. VPN Filter ACL" more from the point of view of which is easier to configure. Also naturally the underlying ASA VPN environment naturally sets some limitations

First thing you have to check on your ASA is if you have the "sysopt connection permit-vpn" ON or OFF. If you issue "show run sysopt" you should see if its configured or not.

If you see "no sysopt connection permit-vpn" then it means that ALL traffic coming through a VPN connection need to be permitted in the interface ACL of the interface where the VPN is terminated.

If on the other hand you dont see anything related to the above "sysopt" command when you issue the command "show run sysopt" then your ASA is acting so that it will permit ALL traffic coming through a VPN connection to bypass the interface ACL. This is the default setting that why it wont show on the CLI.

In this situation naturally the usual way to control the traffic is to build different Filter ACLs for each VPN connection.

In an existing setup you might have problems changing the "sysopt" connection to require all VPN traffic to match the interface ACL as you might not know exactly everything that needs to be allowed and would potentially cause downtime for users behind VPN or resources behind VPN.

In a setup where you can freely decide which way to go with filtering VPN traffic I would suggest disabling the default behaviour with "no sysopt connection permit-vpn" and simply configure in the "outside" interface ACL what you want to allow.

The reason for me personally is that this keeps the setup simple. There is only one ACL where I need to make rules for VPN users and I dont have to manage multiple ACLs to do this. Naturally the single Interface ACL might bloat but personally so far it has not been a problem.

What you also have to consider especially with L2L VPN Filter ACL is that their format is different from interface ACL and Client VPN Filter ACL.

In the L2L VPN Filter ACLs you ALWAYS define the source address as the "remote network". This creates every now and then confusion on how the rules should actually look like. I also potentially allows more traffic than you want as the single ACL rule is bidirectional.

Lets say you want to open TCP/3389 traffic to a remote network then the Filter ACL format for L2L VPN would be

access-list VPN-FILTER permit tcp eq 3389

Now, while this would allow your network to connect to remote host with port TCP/3389 it would also allow the remote host to connect with source port 3389 to any host on your network with any destination port.

Hopefully the information was helpfull. Please rate if so.

And naturally ask more if needed.

- Jouni

j44mistry · ‎03-20-2013

Hi Jouni,

I dont see anything under sh run sysopt.

With the L2L VPN Filter ACLs I am confused I thought to make it bi-directional you need to specify ports at local end.

access-list VPN-FILTER extended permit tcp eq 3389

Is this not the case ?

I find both ACL methods are simple to configure as I have appled per tunnel.

Regards,

Javier Portuguez · ‎03-20-2013

Hi Jaya,

Just to add some input here.

The VPN filter checks the incoming connections over the VPN tunnel.

To define the traffic flow (direction) you must add / adjust the specific port according to your needs.

So for instance:

VPN filter:

access-list filter permit tcp 192.168.2.0 255.255.255.0 eq 23 192.168.1.0 255.255.255.0

TCP connection on port 23:

TCP	Source IP	Source Port	Destination IP	Destination Port

SYN	192.168.1.10	1025	192.168.2.10	23

SYN-ACK	192.168.2.10	23	192.168.1.10	1026

Since the VPN filter checks the inbound connections, in the ACL the source IP is the remote network.

When the local network initiates the TCP session, we will see the TCP port as the source in the SYN-ACK, so the filter will only allow the SYN-ACK packets with a source TCP port 23.

If the remote end initiates the TCP session, then the TCP port will be seen as the destination port, in this case since it is a random port and not 23, the filter will drop it.

TCP	Source IP	Source Port	Destination IP	Destination Port

SYN	192.168.2.10	1025	192.168.1.10	23

So, in this case, it only works in one way, from local 192.168.1.0/24 to remote 192.168.2.0/24 on TCP port 23.

HTH.

Portu.

Jouni Forss · ‎03-20-2013

Hi,

With bidirectional I mean that traffic gets matched agains the VPN Filter ACL both when connections are formed

Local Network to Remote Network
Remote Network to Local Network

Again using the example ACL I used before.

access-list VPN-FILTER permit tcp eq 3389

If the above ACL line was the ONLY ACL rule for a certain L2L VPN connection then the following would be true

When traffic was initiated from
to
- source TCP port could be anything
- destination TCP port could be TCP/3389
When traffic was initiated from
to
- source TCP port could only be TCP/3389
- destination TCP port could be anything

So only considering this Filter ACL the remote host could access any host on with any destination TCP port AS LONG AS its source port for the connection is TCP/3389.

Now if I understood your reply correctly you are talking about a different thing.

If you wanted to make a rule allow TCP/3389 connections from to then there would need to be another ACL rule like

access-list VPN-FILTER permit tcp eq 3389

So with the bidirectional rule I just mean that you have to consider that a single ACL Rule that you might have considered to only be used for other direction MIGHT open up an oppotunity to connect to your network also as that single ACL Rule works also for the remote network when they are initiating the connection

Hope I made any sense (And didnt get anything wrong )

- Jouni

j44mistry · ‎03-20-2013

Thank you both !

Just to clarify If I have to access a web server hosted at a remote site do I put ports on local or remote side ?

Also in terms of security I just need to know if VPN-filter is better or interface ACLs ?

Which block method is more effective or are they the same ?

Javier Portuguez · ‎03-20-2013

Jaya,

This is your LAN:

192.168.20.0/24

This is the remote server:
172.16.10.25

So the VPN filter will be:

access-list vpn-filter permit tcp 172.16.10.25 eq http 192.168.20.0 255.255.255.0

The port goes next to the remote server, since we will see port 80 on the SYN ACK when the server replies, which means that you initiated the connection.

On the other hand, these are two different methods to filter inbound connections (in case of the VPN filter). To filter VPN traffic, I suggest the VPN filter, for any other traffic, then and ACL is an option.

HTH.

Portu.

Jouni Forss · ‎03-20-2013

Hi,

I would have to say that I would prefer the interface ACL use for limiting inbound VPN traffic. Naturally in that case if you want to limit traffic heading to the VPN you will have to use the ACL of the source networks interface on the ASA which again might tip the scales to the other direction when making a decision

With regards to security its my understanding as I said above that the ACL might allow some connectivity from the remote site that your are not wanting and because of this I would prefer interface ACL over Filter ACL applied to VPN

Heres a document that might help you

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00808c9a87.shtml#intro

- Jouni

j44mistry · ‎03-21-2013

Bi-directional ACL

As ACL is stateful, if the traffic is allowed in one direction, then the return traffic for that flow is automatically allowed.

Note: If TCP/UDP ports are not used with the access list, both sides can access each other.

access-list 103 permit ip 172.16.1.2 host 172.22.1.1

Note: This ACL allows the traffic to be originated from 172.16.1.2 to 172.22.1.1 and also from 172.22.1.1 to 172.16.1.2, as the ACL is applied bi-directionally.

This is just like an any to any rule. If ports are specified then you can only access via those ports.

Also you would have to be more restrictive in what you are allowing.

Javier Portuguez · ‎03-21-2013

Dear Jaya,

Do you have any further questions at this point?

Otherwise, please rate any helpfuls posts and mark it as solved.

Thanks

fredy.maizelev · ‎08-20-2013

hello all,

how can we see blocked traffic that is blocked by the vpn filters?

thanks

fredy

Jouni Forss · ‎08-20-2013

Hi,

I would imagine that you would be looking for the following log messages from Syslog server

106102

Error Message    %ASA-6-106102: access-list acl_ID {permitted|denied} protocol for user 
username interface_name/source_address source_port interface_name/dest_address 
dest_port hit-cnt number {first hit|number-second interval} hash codes

Explanation A packet was either permitted or denied by an access-list that was applied through a VPN filter. This message is the VPN/AAA filter equivalent of message 106100.

Recommended Action None required.

106103

Error Message    %ASA-4-106103: access-list acl_ID denied protocol for user username 
interface_name/source_address source_port interface_name/dest_address dest_port 
hit-cnt number first hit hash codes

Explanation A packet was denied by an access-list that was applied through a VPN filter. This message is the VPN/AAA filter equivalent of message106023.

Recommended Action None required.

- Jouni

fredy.maizelev · ‎08-20-2013

Thanks jouni!

can somone please confirm me that vpn-filters under the group policy are valid for ssl-vpn clients config?

were trying to config a cisco ip phone that would connect via anyconnect to the main CUCM and we succseded in that but for some reaon we noticed that not all traffic that was allowed in the vpn filter under the group policy is able to pass..

any ideas?

thanks

fredy

Jouni Forss · ‎08-21-2013

Hi,

To my understanding the VPN Filter ACLs work for both IPsec and SSL VPN Client connections just fine.

Though I personally prefer to use other method of controlling the traffic.

I use the "no sysopt connection permit-vpn" global configuration to make it so that ASA wont automatically allow connections inbound from VPN connections. This permits me to use the "outside" interface ACL to allow/deny the traffic I need without using VPN Filter ACLs.

Naturally if you have existing VPN connections that dont need any limitations then those VPN networks traffic should be allowed in the "outside" interface ACL before changing the above mentioned global setting.

- Jouni

Dr.X · ‎04-29-2014

Hi jouni ,

let me ask u a question ,

u said that
no sysopt connection permit-vpn

allow u to use "outside" interface acl....

my question is , will it allow u ti use inside interface acl ??

can u clarify ?

regards