ASA 8.4(1) L2L vpn-filter obscurity when specifying protocol and port

[tim.march]

Hi All - I've spent several hours trying to diagnose this and have read several threads and relevant Cisco docs to no avail...

Situation: two sites running Cisco ASA 5520's on 8.4(1) with L2L IPsec over the public internet between each. The IPsec configuration and associated routing is working as it should and we're able to pass traffic between the private networks behind each device as expected. The problem occurs when attempting to lock the sessions down using a group-policy vpn-filter configuration.

Each site has 3 private subnets, all of which are able to communicate correctly without the vpn-filter configuration. We would like to restrict access to particular protocols, hosts and ports between each network.

SITE A: 10.10.0.0/18, 10.10.64.0/18, 10.10.128.0/18

SITE B: 10.20.0.0/18, 10.20.64.0/18, 10.20.128.0/18

When we apply a vpn-filter configuration which restricts access only to two hosts, as follows...

SITE A: access-list vpn_acl_x_x_x_x extended permit ip host 10.20.0.1 host 10.10.0.1

SITE B: access-list vpn_acl_x_x_x_x extended permit ip host 10.10.0.1 host 10.20.0.1

... the configuration works correctly. However, when we try to lock the configuration down further and specify protocols and ports, as follows...

SITE A: access-list vpn_acl_x_x_x_x extended permit tcp host 10.20.0.1 host 10.10.0.1 eq 22

SITE B: access-list vpn_acl_x_x_x_x extended permit tcp host 10.10.0.1 host 10.20.0.1 eq 22

... and then try to establish an SSH connection between 10.10.0.1 and 10.20.0.1 or vice versa the packet is stopped on the SOURCE side. ..

Mar 22 11:58:01 x.x.x.x Mar 22 2011 14:34:56: %ASA-4-106103: access-list vpn_acl_x_x_x_x denied tcp for user '<unknown>' inside-data/10.10.0.1(59112) -> outside-iptrans/10.20.0.1(22) hit-cnt 1 first hit [0xd8d1c1b4, 0x0]

If anyone could shed some light on what is wrong with this configuration I'd really appreciate it.

SOLUTION

ACE's need to be implemented on both the source and destination end of the tunnel to facilitate this configuration.

EXMAPLE 1: Allow bi-directional SSH communication between hosts on each network (SITE A can connect to SITE B, SITE B can connect to SITE A) ...

SITE A:
access-list vpn_acl_x_x_x_x extended permit tcp host 10.20.0.1 host 10.10.0.1 eq 22
access-list vpn_acl_x_x_x_x extended permit tcp host 10.20.0.1 eq 22 host 10.10.0.1
SITE B:
access-list vpn_acl_x_x_x_x extended permit tcp host 10.10.0.1 host 10.20.0.1 eq 22
access-list vpn_acl_x_x_x_x extended permit tcp host 10.10.0.1 eq 22 host 10.20.0.1

EXAMPLE 2: Allow uni-directional SSH communication between hosts on each network (SITE A can connect to SITE B, SITE B can not connect to SITE A) ...

SITE A:
access-list vpn_acl_x_x_x_x extended permit tcp host 10.20.0.1 eq 22 host 10.10.0.1
SITE B:
access-list vpn_acl_x_x_x_x extended permit tcp host 10.10.0.1 host 10.20.0.1 eq 22

[Jennifer Halim]

This is the problem that is faced when using "vpn-filter" to restrict traffic for L2L VPN tunnel.

"vpn-filter" is originally used to restrict remote access VPN traffic because traffic only traverse in 1 direction, ie: always initiated from the remote access vpn client end.

For L2L VPN tunnel, because traffic can be initiated from both end, the "vpn-filter" needs to be configured in both direction.

Typically, for L2L VPN, if you have access to both sides of the VPN peers, then I would suggest that you use interface ACL to retrict traffic instead.

Eg: on site A, assuming that all subnets are connected to the inside interface:

access-list permit tcp host 10.10.0.1 host 10.20.0.1 eq 22

access-list deny ip 10.10.0.0 255.255.0.0 10.20.0.0 255.255.0.0

access-list permit ip any any  ----> this will be for internet traffic, or whatever more restricted access you want to provide

Similarly to be configured on site B.

[tim.march]

Thanks for getting back to me.

I understand what you're saying, but it seems fishy to me. The documentation I've found seems to specifically indicate that what I'm trying to do should work...

The VPN Filter works bi-directionally with a single ACL. The remote host/network is always defined at the beginning of the ACE , regardless of the direction of the ACE (inbound or outbound).
As ACL is stateful, if the traffic is allowed in one direction, then the return traffic for that flow is automatically allowed.

The specific example given in the documentation (http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00808c9a87.shtml#bidf) is...

!--- This access list allows the traffic for the remote network 172.16.1.0 
!--- to the local web server on port 80. 
access-list 105 extended permit tcp 172.16.1.0 255.255.255.0 host 172.22.1.1 eq www
!--- This access list allows the traffic in the reverse direction,
!--- from 172.22.1.0 to 172.16.1.3 (ftp server). The remote host/network 
!--- is always defined as the first entry in 
!--- the ACE regardless of the direction.
access-list 105 extended permit tcp host 172.16.1.3 eq ftp 172.22.1.0 255.255.255.0

We do see the devices behave as expected when doing a 'permit ip' between the subnets, but when we 'permit tcp ... eq $PORT' the traffic is blocked. This is also the case where we specifically permit all traffic egress from the internal subnets with the access list and only filter return traffic, for example...

access-list vpn_acl_x_x_x_x extended permit tcp host 10.20.0.1 host 10.10.0.1 eq ssh

access-list vpn_acl_x_x_x_x extended permit ip 10.10.0.0 255.255.192.0 any

access-list vpn_acl_x_x_x_x extended deny ip any any

... According to the documentation this should not be necessary but should take care of any bi-directionality issues you've described. I understand that applying acess controls to the internal interfaces will work, but it the documentation I've read indicates that we should be able to do this with the vpn-filter directive.

This seems like a pretty common question and I can't help but feel we're just missing something obvious. I'd love to get to the bottom of it... Thoughts?

[Jennifer Halim]

Your ACL theory is absolutely correct when it is applied on ASA interfaces.

In this instant, the ACL is applied to vpn-filter, so it works a little differently, especially on L2L VPN as advised earlier.

I agree that it will allow the return traffic as it is stateful, but what you would need to add is the initial packet on the vpn-filter ACL, and the return traffic will definitely be allowed automatically.

OK, so with your example, here is what is required on the VPN filter:

SITE A:

access-list vpn_acl_x_x_x_x extended permit tcp host 10.20.0.1 host 10.10.0.1 eq 22

access-list vpn_acl_x_x_x_x extended permit tcp host 10.10.0.1 host 10.20.0.1 eq 22

(line 1 is to allow SSH from 10.20.0.1 towards 10.10.0.1, and line 2 is to allow SSH from 10.10.0.1 and 10.20.0.1).

SITE B:

access-list vpn_acl_x_x_x_x extended permit tcp host 10.10.0.1 host 10.20.0.1 eq 22

access-list vpn_acl_x_x_x_x extended permit tcp host 10.20.0.1 host 10.10.0.1 eq 22

Because vpn-filter ACL is actually applied on the local ASA, that is why you would need to allow traffic as it is inspected through the vpn-filter ACL. Think about the vpn-filter ACL as a global ACL (both inbound and outbound ACL) applied on the local ASA for the traffic within the VPN tunnel.

[tim.march]

The configuration you've posted doesn't work in production because the source port is always a random unprivileged port, so you're unable to specify it in the ACL (unless, I guess you say 'gt 1023', which is a security issue in itself).

I understand what you're saying, but it's conflicting with the documentation, which specifically states that it should work;

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

Interestingly, it also notes...

When a vpn-filter is applied to a group-policy 
that governs an L2L VPN connection, the ACL must be configured with the 
remote network in the src_ip position of the ACL and the local network 
in the dest_ip position of the ACL.
access-list   ip  


Exercise caution when you construct the ACLs for use with the  vpn-filter feature. The ACLs are constructed with the post-decrypted  traffic (inbound VPN traffic) in mind. However, they are also applied to  the traffic originated in the opposite direction.

... This explains why doing something like I posted in my last reply doesn't work. It's expecting the local network to be on the other side of the statement. In practice if this were implemented it would just allow all traffic from the other side of the network, defeating the point of having the filter in place.

The actual deny statements we're seeing are (on the source side)...

Mar 23 02:50:49 172.22.0.5 Mar 23 2011 05:27:43: %ASA-4-106103: access-list vpn_acl_x_x_x_x denied tcp for user '' inside-data/10.10.0.1(54747) -> outside-iptrans/10.20.0.1(22) hit-cnt 1 first hit [0xd8d1c1b4, 0x0

When we try to apply a rule allowing all ip traffic from the source side it doesn't make a difference (although the documentation states that we don't need to do this).

[Jennifer Halim]

Apology, it should be as follows:

SITE A:

access-list vpn_acl_x_x_x_x extended permit tcp host 10.20.0.1 host 10.10.0.1 eq 22

access-list vpn_acl_x_x_x_x extended permit tcp host 10.20.0.1 eq 22 host 10.10.0.1

SITE B:

access-list vpn_acl_x_x_x_x extended permit tcp host 10.10.0.1 host 10.20.0.1 eq 22

access-list vpn_acl_x_x_x_x extended permit tcp host 10.10.0.1 eq 22 host 10.20.0.1

Here is the documentation bug that has been raised, and I agree, it is quite confusing with vpn-filter on L2L: CSCse74848

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCse74848

[tim.march]

Awesome! So, we can do what we need to do with the vpn-filter directive, it's just that each statement requires 2 ACE's. I knew I wasn't completely insane. Thanks for your help and clarification, it's greatly appreciated.

[Jennifer Halim · Accepted solution]

Great, and thanks for this post. Please kindly mark the post as answered so others can learn from your post. I believe you have initiated a very good discussion on vpn-filter for L2L tunnel.

[tim.march]

Done & Done. I've updated the thread name to make it easier to find. Thanks again.

[soundmouse]

There seems to be a fundamental problem with vpn-filter.

I want to allow all traffic from site A to site B, but none originated from site B to site A (site A is the trusted/management network, site B is the untrusted/service network)

Even though vpn-filter is supposed to be stateful, the same filter is applied to both inbound and outbound traffic. So as soon as you add a filter which permits traffic from A to B, it also permits traffic from B to A!

Tested between an ASA5505 and an ASA5520, both running 8.4(3).

So far I have been unable to find a way around this problem, other than:

(1) applying interface ACLs on all the interfaces at site B, blocking traffic to site A's address range; or

(2) "no sysopt connection permit-vpn" at site A, then having to apply explicit ACLs for all the other VPNs coming into site A (e.g. remote-access clients)

Both of these approaches seem to defeat the intended purpose of vpn-filter.

Regards,

Brian.

[Fabian L]

Apologies for reopening this answered thread, but it seems the right place because it contains very useful information.

SITE A:
access-list vpn_acl_x_x_x_x extended permit tcp host 10.20.0.1 host 10.10.0.1 eq 22
access-list vpn_acl_x_x_x_x extended permit tcp host 10.20.0.1 eq 22 host 10.10.0.1

In this example for allowing bi-directional communication, it seems to me that this also would allow:

Trafffic coming from the remote end with source 10.20.0.1 and a forced source port 22 to connect to ANY port on 10.10.0.1

I came accross this issue because i was trying to allow all traffic from local to remote,  and only allow tcp/http traffic from remote to local. But it seems this can't be done with a vpn-filter

[Jouni Forss · Accepted solution]

Hi,

You save yourself from A LOT of headache if you configure the command

no sysopt connection permit-vpn

This will set a global setting on the firewall so that connections coming through VPN connections will not be allowed to bypass the "outside" inteface ACL (where the VPN is usually terminated)

This gives you an option to control inbound traffic from remote site using the "outside" interface ACL just like you were allowing traffic from behind any other interface on the firewall.

The key thing to notice ofcourse is that if you have existing VPN Client or L2L VPN configurations then BEFORE issuing the command you will have to make sure that the needed traffic is allowed or it will start to get blocked until you open it on the "outside" interface ACL.

Hope this helps

Please rate if the answer was helpfull

Ask more if needed

- Jouni