This document discusses static IPSec L2L configuration on an ASA firewall. It begins by showing the network diagram and basic static L2L configuration including IKE policies, tunnel groups, object groups, access lists, and crypto maps. It then examines the ASP table before the L2L tunnel is established, showing static rules with no associated VPN context. Finally, it looks at the ASP table after a ping between inside networks causes the L2L to come up, noting a rule with a non-null user data field indicating an associated VPN context.
This document discusses static IPSec L2L configuration on an ASA firewall. It begins by showing the network diagram and basic static L2L configuration including IKE policies, tunnel groups, object groups, access lists, and crypto maps. It then examines the ASP table before the L2L tunnel is established, showing static rules with no associated VPN context. Finally, it looks at the ASP table after a ping between inside networks causes the L2L to come up, noting a rule with a non-null user data field indicating an associated VPN context.
This document discusses static IPSec L2L configuration on an ASA firewall. It begins by showing the network diagram and basic static L2L configuration including IKE policies, tunnel groups, object groups, access lists, and crypto maps. It then examines the ASP table before the L2L tunnel is established, showing static rules with no associated VPN context. Finally, it looks at the ASP table after a ping between inside networks causes the L2L to come up, noting a rule with a non-null user data field indicating an associated VPN context.
This document discusses static IPSec L2L configuration on an ASA firewall. It begins by showing the network diagram and basic static L2L configuration including IKE policies, tunnel groups, object groups, access lists, and crypto maps. It then examines the ASP table before the L2L tunnel is established, showing static rules with no associated VPN context. Finally, it looks at the ASP table after a ping between inside networks causes the L2L to come up, noting a rule with a non-null user data field indicating an associated VPN context.
Contents 1 Configuring Static L2L to ASA-2 2 A Look at the ASP Table before L2L is Established 3 What Occurred to Bring Up the Tunnel on Data 4 What About VPN Filters 5 Troubleshooting Why a L2L is not Establishing on Data
Configuring Static L2L to ASA-2
Create IKEv1 Phase 1 Policy
crypto ikev1 policy 10
authentication pre-share encryption aes hash sha group 2 lifetime 86400
Create Tunnel-Group
asapedia/index.php/All_About_Static_IPSec_L2L_and_ASP_Table 1/7 3/23/2020 All About Static IPSec L2L and ASP Table - ASA 9.X - ASApedia
asapedia/index.php/All_About_Static_IPSec_L2L_and_ASP_Table 3/7 3/23/2020 All About Static IPSec L2L and ASP Table - ASA 9.X - ASApedia input_ifc=any, output_ifc=outside
L2 - Output Table:
L2 - Input Table:
Last clearing of hits counters: Never
The above output shows four "cascade delimiter" rules (IPv4/IPv6 and ipsec-tunnel-flow/encrypt domains), four static ACE ipsec-tunnel-flow rules (one for each ACL entry), and four static ACE encrypt rules (one for each ACL entry). The "cascade delimiter" encrypt rule is used to define the beginning of a set of static encrypt rules associated with a crypto map entry. All entries will have the same cascade identifier (cs_id). The cs_id value contains the address of the crypto map entry to guarantee uniqueness. The user_data field contains the VPN_CONTEXT ID. The VPN_CONTEXT will contain the crypto information associated to an inbound or outbound IPsec SA.
All the static rules have a user_data field of NULL indicating that they do not have a VPN_CONTEXT associated to them.
Let's look at the Crypto data in the ASP table after pinging 65.1.224.10 from 95.1.224.10 (PC on inside of ASA1).
ASA# show asp table classify interface outside domain permit
asapedia/index.php/All_About_Static_IPSec_L2L_and_ASP_Table 5/7 3/23/2020 All About Static IPSec L2L and ASP Table - ASA 9.X - ASApedia
L2 - Output Table:
L2 - Input Table:
Last clearing of hits counters: Never
What Occurred to Bring Up the Tunnel on Data
1. The ICMP packet (95.1.224.10 -> 65.1.224.10) arrives on the inside interface of ASA1. 2. ASA1 performs a flow lookup. 3. It does not find an existing flow so it creates a new flow. 4. Then the ASA performs a route-lookup and routes to outside. 5. Flow classification on outside searches the encrypt rules in order. The first rule matched is id=0xaef86be0. 6. Since this rule does not contain a VPN_CONTEXT (user_data==NULL), the NP copies the packet and queues it to the IKE_CMN subsystem to establish a Phase 2 tunnel. The NP drops the original packet and increments "Need to start IKE negotiation (need-ike)" flow drop count. 7. The IKE_CMN subsystem performs a lookup to determine crypto map entry. Based on the crypto map entry, IKE_CMN will dispatch to the IKEv2 (if configured) then to IKEv1 (if configured, if necessary) subsystems. 8. The IKEv1 subsystem checks for Phase 1 tunnel to peer defined in crypto map entry. 9. If necessary, Phase 1 tunnel will be established. 10. Now Phase 2 tunnel is established. 1. The data packet is compared against the crypto map access-list to determine which entry triggered the Phase 2. 2. The matching ACL entry defines the QM Identification payloads - source to IDci and destination to IDcr. 3. When the QM completes, new NP rules are installed: two permit, decrypt, ipsec-tunnel-flow, and dynamic encrypt rule. The two PERMIT rules that are added to ensure that the tunneled traffic is allowed into and out of the firewall. The inbound outer PERMIT rule is identical to the DECRYPT rule, but exists in the PERMIT domain to override any implicit deny rules that may be present. The outbound outer PERMIT rule is the mirror image of the inbound outer PERMIT rule (with the sources and destinations reversed) and allows the encrypted traffic out of the system regardless of the implicit deny rules that may exist on the interface. The decrypt rule is used to identify the encrypted packets sent from the peer. The ipsec-tunnel-flow rule is used to verify the decrypted packets from the peer conform to the negotiated tunnel and will perform inbound VPN filtering (if applied). This rule is inserted immediately before its matching static ipsec-tunnel-flow rule. The dynamic encrypt rule will perform outbound VPN filtering (if applied) and is used to encrypt subsequent packets from inside ASA1 to ASA2. This rule is inserted immediately before its matching static encrypt rule. This way this new rule with a VPN_CONTEXT is hit before the static rule without a VPN_CONTEXT.
NOTE: Hit counts increment on a per flow not on a per packet basis.
What About VPN Filters
Refer to [1] (http://asapedia.cisco.com/index.php/VPN_Filter_Enhancement) .
Troubleshooting Why a L2L is not Establishing on Data
1. Perform capture trace on ingress interface: capture whatsup interface inside trace detail 2. Look for routing decisions and drop location/reason: show capture whatsup trace detail 3. It should be drop at encrypt matching the static encrypt NP rule. 4. Now refer to Debugging_ISAKMP_Problems (http://asapedia.cisco.com/index.php/Debugging_ISAKMP_Problems) . asapedia/index.php/All_About_Static_IPSec_L2L_and_ASP_Table 6/7 3/23/2020 All About Static IPSec L2L and ASP Table - ASA 9.X - ASApedia
Retrieved from "http://asapedia/index.php/All_About_Static_IPSec_L2L_and_ASP_Table_-_ASA_9.X"
Categories: IPSec | Troubleshooting | LAN-to-LAN
This page was last modified on 10 September 2016, at 21:31.
