08-20-2014 08:33 AM - edited 03-11-2019 09:39 PM
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
Solved! Go to Solution.
08-20-2014 09:42 AM
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".
08-20-2014 10:44 AM
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.
08-20-2014 09:42 AM
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".
08-20-2014 10:34 AM
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 ?
08-20-2014 10:44 AM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: