Best approach to controlling L2L VPN access on an ASA

Unanswered Question
Feb 2nd, 2009

When building a site to site VPN (say for example one ASA to another) use an ACL to determine what traffic is interesting and shoudl thus be tunneled. You also use lets say the inbound ACL on the internal interface to control what specific ports are allowed and have more granular control over what traffic actually gets out to go to the other end of the tunnel.

My question is what is the best/preferred method for controlling inbound access coming from the remote side through the tunnel to your local resources. I think the options are as follows:

a) You trust the remote side to leverage their ACLs on traffic leaving their environment destined to your environment. Basically assuming if you only want to tunnel ssh traffic that their ACLs are only allowing ssh traffic through to you.

b) you disable to sysopt connection permit-ipsec feature. This allows you to put ACLs on the external interface of your firewall controlling traffic inside the tunnel. So on your outside ACL in addition to permitting the internet to access your web server on port 80 you also allow say to connect to on port 22.

c) you use sysopt connection permit ipsec to allow any and all VPN traffic to the firewall and then restrict where the remote users can get to using an EGRESS acl on the internal interface of your firewall.

IMO option "a" is unacceptable....but I can think of a couple pros and cons to both "b" and "c" so I am curious to hear what your thoughts are.

Please let me know which you use most often, which you think is best, which you prefer and why.


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Ivan Martinon Mon, 02/02/2009 - 17:20

There is another option that you can consider when using ASA devices to create lan to lan tunnels, this however is not as developed as we would want. Using VPN Filters on the group policy you can control what traffic goes through the tunnel. The consideration of this is that as soon as you apply a filter on the tunnel group, the Device automatically creates a rule that mirrors the applied rule for returning traffic. This becomes a problem when trying to permit everything from the trusted side to the other since it will inherently create the permit any from the destination. Check the link below for further information:

As for your options option A indeed is out of your hands, option B would be more viable but if you have many tunnels it could become an administrative pain. Option C is not viable for state connections.

slug420 Tue, 02/03/2009 - 05:16

so which do you use/prefer/reccomend?

And what do you mean C is not viable for state connections?

Ivan Martinon Tue, 02/03/2009 - 07:11

I would use filters, and what I for state connections mainly TCP once you pass an ACL check (outside) by the sysopt command, the reply to that connection will never be dropped by the ASA.

slug420 Tue, 02/03/2009 - 08:49

"once you pass an ACL check (outside) by the sysopt command, the reply to that connection will never be dropped by the ASA."

Are you saying that you cannot use EGRESS ACLs on the INSIDE interface to control what traffic (whether it came in over a L2L tunnel or through one of the directly connected networks) leaves that interface??

This is most surprising ( though certainly not the first ridiculous surprise with the code cisco has put out since 6.3(5) )

Ivan Martinon Tue, 02/03/2009 - 08:52

Yes this is how this work, once the acl is passed bypassed on the outside, you cannot block this on the inside that is what STATE CHECK does


This Discussion