Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

ASA LAN-to-LAN access-list direction

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

 

 

 

 

2 ACCEPTED SOLUTIONS

Accepted Solutions
VIP Purple

You have to distinguish two

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".


--
Don't stop after you've improved your network! Improve the world by lending money to the working poor: http://www.kiva.org/invitedby/karsteni
VIP Purple

Again you have to look at two

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.


--
Don't stop after you've improved your network! Improve the world by lending money to the working poor: http://www.kiva.org/invitedby/karsteni
3 REPLIES
VIP Purple

You have to distinguish two

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".


--
Don't stop after you've improved your network! Improve the world by lending money to the working poor: http://www.kiva.org/invitedby/karsteni
New Member

Karsten, thanks for your

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 ?

VIP Purple

Again you have to look at two

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.


--
Don't stop after you've improved your network! Improve the world by lending money to the working poor: http://www.kiva.org/invitedby/karsteni
276
Views
0
Helpful
3
Replies
CreatePlease login to create content