Sysopt permit-vpn: internal ACL's

[John Vankoningsveld]

Hi,

I'm currently in the process of testing some configurations for IPSEC L2L VPN's on a pair of Cisco ASA devices.

My configuration sets up a VPN tunnel to build between the two external interfaces of the devices.

I then have a single internal LAN interface configured at each location.

I am using an extended ACL to specify the traffic for which the VPN tunnel builds. At present I am allowing the entire LAN subnet range to be passed over the VPN.

So, the entries for the allowed traffic look something like this:

access-list test_l2l extended permit ip 10.1.10.0 255.255.255.0 10.1.20.0 255.255.255.0

crypto map l2l 10 match address test_l2l

My understanding was that I could then use a combination of ACL's applied to the internal interface to control the "actual traffic" allowed to be sent over the VPN. So use an inbound ACL to control local --> remote traffic, then use an outbound ACL to control remote --> local traffic.

When doing this, I have no problem with the inbound ACL, as this permits/denies traffic as I would expect. However the outbound ACL seems to be completely ignored. Traffic from the remote site passes into the local subnet without registering on the outbound ACL at all...

From reading I came across the "no sysopt connection permit-vpn" option - but by using the option, traffic is inspected at the inbound external interface ACL, and I would need to add entries for ISAKMP and everything else needed to actually build the tunnel itself.

My understanding was that as the VPN tunnel terminates at the external interface, traffic would be unencrypted at a point before being routed to the internal interface. My assumption was therefore that the traffic would be treated as "normal non-vpn traffic" when being checked against the outbound internal ACL.

Can someone confirm if my assumptions are in fact false and if so explain why the traffic is still considered "VPN traffic" at this point?

Also, if this is the case, do I have any other options for controlling the traffic through a IPSEC L2L VPN, other than the "no sysopt connection permit-vpn" option ?

Thanks in advance,

John Vankoningsveld.

[Maykol Rojas · Accepted solution]

Hello John,

I hope you are doing great. By default the ASA security appliance will trust and create an stateful connection for your remote network that is connecting to the ASA, that being said, if you want to block the traffic from the L2L tunnel, you will need to use the no sysopt connection permit vpn or apply vpn filters to the L2L tunnel group, here is a quick link for reference,

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

That includes an example of how you can achieve this.

Hope it helps.

Mike

[John Vankoningsveld]

Hi Mike,

Thanks for the quick reply!

The VPN filter works well. I had read a bit about them, but thought that they were only for use with Remote Access VPN's - not with L2L. So thanks for clearing that up for me.

To me this seems a much better way of approaching the issue, rather than using to no sysopt connection permit-vpn option. Am I correct in thinking that this method has less overhead on the ASA - due to not needing to read every packet passed through the external interface in order to check against the external ACL?

The only thing that seems a little strange is that the ACL's in the VPN filter are considered bi-directional. I understand that this is to allow reply traffic back to the initiator, but does this also mean that it allows initiations in both directions?

For example, if I create a VPN filter to only allow LocalSite/Host_A to talk to RemoteSite/Host_B on port 80, then if RemoteSite/Host_B had the ability to set it's send port to 80, then it could in theory initiate conversation with LocalSite/Host_A on any port ? regardless of whether it was initiating conversation or replying?

Does that make sense?? It's probably a reasonably small risk, but as I do not have control over the remote site, I'd like to understand any possible risks...

[Maykol Rojas]

Hello John

Thanks!  I am glad I was able to help, to conclude with your final doubts here are the answers for your questions:

Am I correct in thinking that this method has less overhead on the ASA?

Totally, it will make the firewall not to look into the entire ACL that may be applied on the outside.

I understand that this is to allow reply traffic back to the initiator, but does this also mean that it allows initiations in both directions?

Yes, both can initiate connections only IF there is no protocol specified on the ACL.

Hope this helps.

Cheers

Mike

[John Vankoningsveld]

Hi Mike,

OK - that clears things up nicely! Thanks again for the help.

Cheers,

John.