topic Karsten, thanks for your in Network Security

ASA LAN-to-LAN access-list direction

Kurt Lei — Tue, 12 Mar 2019 04:39:32 GMT

Hi All,

I'm setting up the LAN-to-LAN IPSec VPN on below setting. Phase 1 & 2 comes up successfully.

172.25.139.64/26 --- ASA1 ----- Checkpoint ------ 172.25.128.0/24

==============================ASA 1 ==================================================

access-list 120 extended permit ip 172.25.128.0 255.255.255.0 172.25.139.64 255.255.255.192

access-list 220 extended permit ip 172.25.139.64 255.255.255.192 172.25.128.0 255.255.255.0

crypto map cpdc1 20 match address 220
crypto map cpdc1 20 set peer x.x.x.x
crypto map cpdc1 20 set transform-set dcset1
crypto map cpdc1 20 set security-association lifetime seconds 120
crypto map cpdc1 interface outside

========================================================================================

For my understanding, the access-list used to define the interesting traffic to be encrypted. However, in ASA, which access-list is used to define the reserve path (i.e. 172.25.128.0/24 to 172.25.139.64/26) ? Is it used with access-group 120 access_in in outside command ?

I found I can still ping on both direction even I didn't set access-group command. I'm wondering whether access-group is controlling the reverse path.

Regards,

Kurt

You have to distinguish two

Karsten Iwen — Wed, 20 Aug 2014 16:42:43 GMT

You have to distinguish two things:

1) Which traffic is protected by IPsec.

That is done with the ACL 220 that you specified in your crypto map. The traffic from 172.25.128./24 to 172.25.139.64/26 has to be protected. At the same time, the reverse treffic is expected to arrive IPsec-protected.

2) Which traffic you want to allow inside the tunnel.

By default, the complete traffic that is specified in the crypto ACL is allowed to flow in both directions. You can reach the other side and the other side can reach you.

If you want to restrict that, there are two choices:

1) Using a "vpn-filter" in a group-policy that is applied to your tunnel-group. That's the new way of controling traffic. But in reality it's a PITA as there is only one ACL and that ACL controls the traffic in both directions. The used ACL does not use the "normal" syntax of Source and Destination but Remote and Local which makes filtering outbound traffic a little bit complex.

2) The old way where the incoming traffic has to be allowed by the outside ACL. That's the ACL that you apply with the access-group command and that normally is used to control traffic from the outside to your DMZ/inside ...

To enable the old behavior, you need the command "no sysopt connection permit-vpn".

Karsten, thanks for your

Kurt Lei — Wed, 20 Aug 2014 17:34:32 GMT

Karsten, thanks for your reply.

I understand the traffic is expected IPSec-protected in both direction.

At point 2, are you meaning "the complete traffic" consist all of the protocol can be passed through by default even I didn't configure the access-group command ?

Again you have to look at two

Karsten Iwen — Wed, 20 Aug 2014 17:44:30 GMT

Again you have to look at two ways of the communication:

1) inside to outside

If you have an ACL on the internal interface, that always has to allow the traffic for the VPN. If it's denied there the traffic doesn't even really "enter the ASA".

2) VPN to inside

Long time ago the interface ACL was needed because after decryption, the cleartext packet was compared to the interface ACL. So this ACL had to allow the wanted traffic which also gave you a way to have a very specific way of allowing and denying traffic.

In actual releases, this is not done any more by default. Think of it as if the VPN would be terminated inside the ASA and not at the outside interface where you apply your crypto map. If the traffic is inside, it can freely flow to all attached networks. I assume here that you don't use outgoing ACLs, but they are only rarely used. In this situation you don't need any ACL on the outside interface. Even more, if you have one, it doesn't matter what's in there.