cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5931
Views
0
Helpful
9
Replies

VPN-filter question in 8.2.3 or 8.3.2

jkeeffe
Level 2
Level 2

There is a 2008 document titled "PIX/ASA 7.x and Later:VPN Filter (Permit Specific Port or Protocol) Configuration Example for L2L and Remote Access" found here:  PIX/ASA 7.x and Later: VPN Filter (Permit Specific Port or Protocol) Configuration Example for L2L and Remote Access

In it is written:

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.

This has always been strange to me because in every other Cisco product, ACLs are constructed with the source being in the src_ip - the first position - of the ACL syntax.

Has this been changed in either 8.2.3 or 8.3.2 to follow the normal ACL syntax - where the source is in the src_ip and the destination is in the dest_ip positions of the syntax?

5 Accepted Solutions

Accepted Solutions

rahgovin
Level 4
Level 4

Hi,

The idea for a vpn-filter was to pemit or deny particular certain traffic entering the security device through vpn based on       criteria such as source address, destination address, and protocol. Hence the access-list configuration is different from the normal access-list configured on the ASA. So it basically considers the traffic sourced from the remote end to the internal network behind the ASA to matched for filtering hence the reversal of source and destination. This has not changed in 8.2.3 or 8.3.2.

View solution in original post

praprama
Cisco Employee
Cisco Employee

Hi,

This is the config guide for the ASA version 8.3 which explains the same about vpn-filters:

http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/vpngrp.html#wp1134794

The thing is that vpn-filters filter traffic bidirectionally, that is, both from the local subnet to the remote subnet and vice versa.This is just the way it has to be configured for it to work.

Thanks and Regards,

Prapanch

View solution in original post

the logic behind this being a simple requirement

if i dont want to send something from my end to the other end i would probably just not include that in the crypto acl or play with the nat-exempt feature

however if i want to block the other site from accessing some of my resources i would rather just put an access-list on my end to block the traffic rather than get into the high level approval process of asking the other site to stop sending something

also this gives a lot of flexibility when i am too chossy about what i want to permit from the other end

the key being as rahul said, it is always in the inbound direction

View solution in original post

Hi,

Well firstly the group-policy and hence the vpn-filters will take effect only after tunnel comes up. So you would not be able to restrict what traffic brings up the tunnel using vpn-filters.

Better option would be to have an access-list on the inside interface of side A allowing traffic from host A to B only on tcp 104 and not on other ports.

Also, if you would like only Site A (which has host A) to initiate the tunnel and not Site B (which has host B), you will need to add the follwing command to the crypto map on Site B:


http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/c5.html#wp2238363

That is, Site B should be answer-only. Hence, Site B will no initiate the tunnel.

Regards,

Prapanch

View solution in original post

Hi,

I am afraid that's the only way to go about if you want to restrict traffic that brings up the VPN tunnel. If you would only like to restric traffic passing through the VPN tunnel, then VPN filters would be the way to go a about with it.

Regards,

Prapanch

View solution in original post

9 Replies 9

rahgovin
Level 4
Level 4

Hi,

The idea for a vpn-filter was to pemit or deny particular certain traffic entering the security device through vpn based on       criteria such as source address, destination address, and protocol. Hence the access-list configuration is different from the normal access-list configured on the ASA. So it basically considers the traffic sourced from the remote end to the internal network behind the ASA to matched for filtering hence the reversal of source and destination. This has not changed in 8.2.3 or 8.3.2.

the logic behind this being a simple requirement

if i dont want to send something from my end to the other end i would probably just not include that in the crypto acl or play with the nat-exempt feature

however if i want to block the other site from accessing some of my resources i would rather just put an access-list on my end to block the traffic rather than get into the high level approval process of asking the other site to stop sending something

also this gives a lot of flexibility when i am too chossy about what i want to permit from the other end

the key being as rahul said, it is always in the inbound direction

The reason why I want to use a vpn_filter is to limit what traffic can initiate the tunnel and bring it up. Say I want local host A to open a tcp sockets connection to remote host B on tcp port 104. I want only tcp 104 from A to B to bring the tunnel up. I don't want any IP to bring the tunnel up and then have to restrict traffic to only tcp 104 after the tunnel is up. The way the vpn-filter ACL syntax seems to work then - since it's bidirectional - is it will allow host B to bring the tunnel up too.

access-list permit host B 104 host A    (this will allow both host A and B to bring the tunnel up?)

How do I do a L2L config where only local host A opening a tpc 104 connection to remote host B will bring the tunnel up?  Or is this not possible with the ASA?

Hi,

Well firstly the group-policy and hence the vpn-filters will take effect only after tunnel comes up. So you would not be able to restrict what traffic brings up the tunnel using vpn-filters.

Better option would be to have an access-list on the inside interface of side A allowing traffic from host A to B only on tcp 104 and not on other ports.

Also, if you would like only Site A (which has host A) to initiate the tunnel and not Site B (which has host B), you will need to add the follwing command to the crypto map on Site B:


http://www.cisco.com/en/US/docs/security/asa/asa82/command/reference/c5.html#wp2238363

That is, Site B should be answer-only. Hence, Site B will no initiate the tunnel.

Regards,

Prapanch

I understand now the reasoning for, and workings of, the vpn-filter.

You mention if I want to restrict what traffic will bring the tunnel up, to put that in an ACL attached to the inside interface of the ASA. This would be OK if I only had a limited number of L2L tunnels. But how reasonable is that to do if there are literally dozens and dozens of L2L tunnels (we have 125 L2L tunnels in our existing 3030 concentrator that we're planning on moving to the ASA)? That would be one HUGE internal interface ACL if all the L2L tunnels used that ACL to limit what traffic can initiate each tunnel. Can you imaging trying to work with an ACL of that size when troubleshooting one individual L2L problem?

In the 3030 concentrator each L2L tunnel config has its own set of network lists, rules, and filters, making it very easy to configure and troubleshoot for large numbers of tunnels. It seems that that simplicity is lost in the ASA - unless I don't care what initiates a tunnel and just allow any IP traffic to bring it up.

That's not a very secure way of doing things. That means that some rogue ping sweep could bring up a tunnel and my security would rest on the vpn-filter. Am I still missing something here?

Hi,

I am afraid that's the only way to go about if you want to restrict traffic that brings up the VPN tunnel. If you would only like to restric traffic passing through the VPN tunnel, then VPN filters would be the way to go a about with it.

Regards,

Prapanch

praprama
Cisco Employee
Cisco Employee

Hi,

This is the config guide for the ASA version 8.3 which explains the same about vpn-filters:

http://www.cisco.com/en/US/docs/security/asa/asa83/configuration/guide/vpngrp.html#wp1134794

The thing is that vpn-filters filter traffic bidirectionally, that is, both from the local subnet to the remote subnet and vice versa.This is just the way it has to be configured for it to work.

Thanks and Regards,

Prapanch

We just ran into this problem last week.   Pulled our hair tryign to figure out why the tradtitional ACL wouldn't work for a specifuc remote VPN profile attempting to access a host across a site-to-site tunnel.


IE:  Local subnet > remote host, in the end we had to switch it due the vpn filter stipulations...remote host > local subnet and it started working.

Same here.

Ran into the problem and modified the ACL (Choose another ACL than the crypto map of course)

Works like a charm

Nicolas

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: