08-20-2010 07:45 AM
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?
Solved! Go to Solution.
08-20-2010 08:13 AM
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.
08-20-2010 08:18 AM
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
08-20-2010 08:22 AM
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
08-20-2010 08:44 AM
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
08-20-2010 05:49 PM
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
08-20-2010 08:13 AM
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.
08-20-2010 08:22 AM
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
08-20-2010 08:28 AM
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?
08-20-2010 08:44 AM
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
08-20-2010 09:34 AM
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?
08-20-2010 05:49 PM
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
08-20-2010 08:18 AM
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
08-23-2010 07:37 AM
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.
12-19-2012 01:39 AM
Same here.
Ran into the problem and modified the ACL (Choose another ACL than the crypto map of course)
Works like a charm
Nicolas
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide