Before you see any SAs, you must first send a ping from R1 to R2. You need to create traffic that will match the LAN1_LAN2 access list to trigger encryption and create the tunnel. Did you ping beforehand? If you did, was your ping successful? By answering those questions we’ll be able to help you further in your troubleshooting process.
OK, so if the ping failed, then there will be no established SAs, so the output that you are seeing is to be expected. You must troubleshoot the connectivity problem first. Go through the phase 1 and phase 2 configurations and ensure that your configurations are correct. Once you get the ping working, then you can check to see if SAs have formed for encrypting that traffic.
Cisco ASA Site-to-Site IKEv1 IPsec VPN same (nearly copy paste, except interface and password of course) and does not work in CML231 02.08.2022
In Cisco Packet Tracer as well does not work, but it should work in CML.
This lab should be doable on Cisco CML. Just to confirm, I went in to the lab and checked and was able to reproduce the results in the lesson. I suggest you approach the problem as you would when troubleshooting such an issue regardless of what emulator you are using. As for packet tracer, I can’t say since I( haven’t tried it there. If you need any help along the way, give us some more details so that we can help out…
When configuring IPSec, the tunnel-group command is used to configure what is called “the database of connection-specific records”. This database contains tunnel-specific information that is necessary to establish and maintain the tunnel. As shown in the lesson, this information includes the type of tunnel being created. In the lesson, this is a LAN to LAN tunnel, but you can also have remote access type.
Once the tunnel group is created, you can then change various attributes using one or more of the following commands:
tunnel-group general-attributes
tunnel-group ipsec-attributes
tunnel-group webvpn-attributes
tunnel-group ppp-attributes
In the lesson, the ipsec-attributes keyword is used. This configuration mode allows us to configure the IKE attributes such as the preshared key for the tunnel.
More information bout the tunnel-group command for the ASA can be found at the following Cisco command reference:
The tunnel group is typically used when you want to define different rules for different connections. Most often you will use it for VPN clients to connect with different rules such as when you’re implementing EZVpn. However, it is possible to not use it.
The alternative is to use a crypto map with an IPSec profile. This is what is done for example when you configure an IPSec tunnel as in this lesson:
or when you create an IPSec VTI like so:
Take a look at this Cisco Community thread for more information.
I configured a site-to-site similar to your example here using packet tracer by directly connecting two ASA and a router behind each, unfortunately my tunnels are not coming up and the router could not ping each other.
HERE ARE MY CONFIG:
ciscoasa1#sh run
: Saved
:
ASA Version 9.6(1)
!
hostname ciscoasa1
names
!
interface GigabitEthernet1/1
nameif inside
security-level 100
ip address 10.10.10.3 255.255.255.0
!
interface GigabitEthernet1/2
nameif outside
security-level 0
ip address 192.168.1.3 255.255.255.0
!
interface GigabitEthernet1/3
no nameif
no security-level
no ip address
shutdown
!
interface GigabitEthernet1/4
no nameif
no security-level
no ip address
shutdown
!
interface GigabitEthernet1/5
no nameif
no security-level
no ip address
shutdown
!
interface GigabitEthernet1/6
no nameif
no security-level
no ip address
shutdown
!
interface GigabitEthernet1/7
no nameif
no security-level
no ip address
shutdown
!
interface GigabitEthernet1/8
no nameif
no security-level
no ip address
shutdown
!
interface Management1/1
management-only
no nameif
no security-level
no ip address
shutdown
!
object network INSIDE
subnet 10.10.10.0 255.255.255.0
nat (inside,outside) dynamic interface
object network INSIDE1
subnet 10.10.20.0 255.255.255.0
!
route outside 0.0.0.0 0.0.0.0 192.168.1.2 1
!
access-list LAN1_LAN2 extended permit ip object INSIDE object INSIDE1
access-list LAN1_LAN2 extended permit ip 10.10.10.0 255.255.255.0 10.10.20.0 255.255.255.0
!
!
!
!
class-map inspection_default
match default-inspection-traffic
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect icmp
!
service-policy global_policy global
!
telnet timeout 5
ssh timeout 5
!
!
!
crypto map CRYPTO_MAP 1 match address LAN1_LAN2
crypto map CRYPTO_MAP 1 set peer 192.168.1.2
crypto map CRYPTO_MAP interface outside
crypto ikev1 enable outside
crypto ikev1 policy 1
encr aes
authentication pre-share
group 2
lifetime 3600
!
tunnel-group 192.168.1.2 type ipsec-l2l
tunnel-group 192.168.1.2 ipsec-attributes
ikev1 pre-shared-key cisco123
!
ciscoasa1#
CONFIG 2
ciscoasa2#SH RUN
: Saved
:
ASA Version 9.6(1)
!
hostname ciscoasa2
names
!
interface GigabitEthernet1/1
nameif inside
security-level 100
ip address 10.10.20.2 255.255.255.0
!
interface GigabitEthernet1/2
nameif outside
security-level 0
ip address 192.168.1.2 255.255.255.0
!
interface GigabitEthernet1/3
no nameif
no security-level
no ip address
shutdown
!
interface GigabitEthernet1/4
no nameif
no security-level
no ip address
shutdown
!
interface GigabitEthernet1/5
no nameif
no security-level
no ip address
shutdown
!
interface GigabitEthernet1/6
no nameif
no security-level
no ip address
shutdown
!
interface GigabitEthernet1/7
no nameif
no security-level
no ip address
shutdown
!
interface GigabitEthernet1/8
no nameif
no security-level
no ip address
shutdown
!
interface Management1/1
management-only
no nameif
no security-level
no ip address
shutdown
!
object network INSIDE
subnet 10.10.20.0 255.255.255.0
nat (inside,outside) dynamic interface
object network INSIDE0
subnet 10.10.10.0 255.255.255.0
!
route outside 0.0.0.0 0.0.0.0 192.168.1.3 1
!
access-list LAN2_LAN1 extended permit ip 10.10.20.0 255.255.255.0 10.10.10.0 255.255.255.0
access-list LAN2_LAN1 extended permit ip object INSIDE object INSIDE0
!
!
!
!
class-map inspection_default
match default-inspection-traffic
!
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect icmp
!
service-policy global_policy global
!
telnet timeout 5
ssh timeout 5
!
!
!
crypto map CRYPTO_MAP 1 match address LAN2_LAN1
crypto map CRYPTO_MAP 1 set peer 192.168.1.3
crypto map CRYPTO_MAP interface outside
crypto ikev1 enable outside
crypto ikev1 policy 1
encr aes
authentication pre-share
group 2
lifetime 3600
!
tunnel-group 192.168.1.3 type ipsec-l2l
tunnel-group 192.168.1.3 ipsec-attributes
ikev1 pre-shared-key cisco123
!
ciscoasa2#
The ASA Site to Site IKEv1 IPSec VPN feature can be accomplished using Packet Tracer. However, when you use Cisco’s Packet Tracer for such configurations, there may be some limitations as to the amount of troubleshooting you can perform, especially when looking at syslogs and debugs. Some of the suggested processes here may actually not work on packet tracer but hopefully they will give you some help and direction.
Looking at your configuration, I don’t see something that is immediately wrong with what you have configured. To resolve this, I suggest you go through some of the following troubleshooting steps:
Verify connectivity. Ensure that both sides of the VPN can reach each other using the IP addresses on their outside interfaces.
Use debug commands to check out the IKE process as well as the IPSec process. debug crypto ikev1 and debug crypto ipsec are two useful commands. If IKE or IPSec fails anywhere, you should see it there. However, I don’t know what kind of detail PacketTracer will show you here.
Check the IKEv1 configuration. Make sure both ASAs have matching IKEv1 policies, including authentication, encryption, hash, and Diffie-Hellman group settings and confirm that both ASAs have the correct pre-shared key configured for the peer.
Verify IPSec configuration. Ensure that both ASAs have matching transform sets (encryption and hash algorithms) and security associations (SAs) lifetime. Also check the access lists or traffic selectors on both ASAs to ensure they specify the correct local and remote subnets. You have changed the address ranges compared to the lesson so I’m not sure which address should be allowed in your case.
These are just some of the steps you can take. Check it out and let us know how you get along!
I have one issue with IPSec tunnel Lan-to-Lan between ASA 5525x (v9.8) and ASA FPR 2110 (v9.16). My Tunnel is up but ping between each client was not successful. Both peer shows status crypto isakmp sa in MM_ACTIVE.
I ran packet-tracer icmp between peer and result shows ALLOW for every phase 1 and 2. Debug command sh crypto ipsec sa shows packets encrypt is non zero but decrypt is zero.
First of all, where did you run the debug process? The encryption and decryption numbers you shared, are those on the same device? On the ASA 5505x? This will help us to further pinpoint the location of the problem.
I suggest you run the same debugs on both ends to see where you get encrypts and where you get decrypts. We will then be able to see if the pings reach the remote device or not.
In any case, it is a good assumption to suspect NAT, but you will have to do the debugs to verify that and see what needs to be changed.
Without knowing more about the diagnostics you have collected, I can give you some general guidelines that may help in performing your troubleshooting:
Check NAT Exemption: Make sure that you’ve set up NAT exemption correctly on both sides. The traffic that is going through the tunnel should be exempted from NAT.
Check Access Lists: Verify that the access lists used in the crypto map of both firewalls are mirror images of each other. They should permit the traffic from the local network to the remote network and vice versa.
Check Routing: Make sure that the routing is set up correctly. Both firewalls should know how to reach the subnets on the other side of the tunnel.
Check IPsec Parameters: Verify that the IPsec parameters (IKE version, encryption and hash algorithm, Diffie-Hellman group, and lifetime) match on both sides. It is likely that this is OK since your tunnel is up, however, it’s due diligence…
Check Tunnel Group: Check the tunnel group and group policy settings on the FPR 2110. Make sure that the correct settings are applied for the tunnel.
Debugging: Enable debugging on both devices to get more information about what’s happening. Use the ‘debug crypto ipsec’ and ‘debug crypto isakmp’ commands.
Let us know how you get along, and if you need further help.