One-way L2L vpn config to conform to security requirements

Answered Question
Feb 22nd, 2009


I've successfully setup a L2L connection between ourselves (5510, 7.2) and a 3rd party (SonicWall).

The security requirements are such that users (contractors) at our office need to connect to various devices at the 3rd party BUT nothing at the 3rd party should connect to anything at our office.

I have tried an ACL outbound (access-group L2L-RESTRICT out interface INSIDE) on the inside interface. But the funny thing is I'm getting hits on the deny statements on the ACL although testing shows no problems connecting to various hosts at our site from the 3rd party. My ACL config looks like the following:



access-list L2L-RESTRICT extended permit icmp echo-reply

access-list L2L-RESTRICT extended deny ip any log


access-list L2L-RESTRICT extended permit ip any any


access-group L2L-RESTRICT out interface INSIDE


Their network is obviously 192.168.16.x and they won't be able to use a different source vlan as the 'interesting traffic' ACL will not permit it. So it sounds good in theory

Have I configured this correctly? Is there a better way?

Thanks in advance,


I have this problem too.
0 votes
Correct Answer by eddie.mitchell@... about 7 years 8 months ago


It looks like you might be able to assign a VPN filter ACL via a group policy assigned to each L2L tunnel. I've never done this personally before, but seems like it would work...

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
eddie.mitchell@... Tue, 02/24/2009 - 08:06

You config doesn't contain 'sysopt connection permit-vpn' right?

Have you tried running a capture on the inside interface of the ASA to verify that the traffic is leaving and the source IP is not being translated?

m.surtees Tue, 02/24/2009 - 16:57


That 'sysopt connection permit-vpn' is a funny one .. no trace of it in the config but a 'sh run sysopt' gives the follwing:

no sysopt connection timewait

sysopt connection tcpmss 1380

sysopt connection tcpmss minimum 0

no sysopt nodnsalias inbound

no sysopt nodnsalias outbound

no sysopt radius ignore-secret

sysopt connection permit-vpn

.. so I guess it is there. What does it do? Why does it not appear in the running or startup configs?

I have not yet done a packet capture - I know that's troubleshooting 101 but time been pushing hard. I will do it, but i have put nat exemptions in there and the fact the VPN works suggests that these rules are working fine. If NATing was taking place I doubt the interesting traffic ACLs would be getting hit and therefore prevent all necessary VPN activity for the link.

As I said the VPN is working fine ... I'm just looking for a way to stop the other end instigating connections to resources on our site to comply with the security requirements. I've configured quite a few VPN's but never had to prevent traffic in 1 direction unless my VPN terminater was seperate to my FW where it is easy to do. (From the 3000 series and PIX days)



eddie.mitchell@... Wed, 02/25/2009 - 06:05

This command is the newer version of 'sysopt connection permit-ipsec' which allows VPN traffic to bypass interface ACL's which is probably why your attempts to filter the VPN traffic have been unsuccessful. I would try adding the no form of the command and see if your interface ACL starts working. A word of warning though-this setting applies globally, so it will affect all VPN tunnels that terminate to your ASA. I believe you will also need to add an ACE on your outside ACL to permit ISAKMP and ESP from the remote termination device to your ASA.

m.surtees Wed, 02/25/2009 - 06:11

Thanks Eddie,

Yes I've had a look at the cmd and I don't think it's for me ... there are other L2L tunnels as well as a large number of client vpns terminating on the ASA so I'd need to open ISAKMP and ESP to everyone. I might be wrong but it sounds like a bad idea.

Can you think of another way my objective might be achieved? I'm not glued to the idea of an egress ACL.



m.surtees Wed, 02/25/2009 - 06:50

Looks interesting .. Cheers for that. It's a bit nerve-racking configuring these things on production devices where you really don't want to interfere with all the other work the ASA is doing but this looks tunnel specific and therefore worth a try.

Many thanks for your help



This Discussion