We have 4 tunnels that will be built to one of our vendors, and they are using ASA's at both of their locations and we have 2 ASA's at both of ours. One tunnel came up OK, one is still not configured on the vendor end, and the final two tunnels won't come up. We've compared the configuration on our end to make sure the configuration is identical for the one tunnel that does work, and our vendor states they have done the same. We've also shared the configurations when one a Zoom conference, and things appear OK on both ends to me. Here is what we are seeing, and I'd really appreciate any ideas on this one:   1) IKEv2-PROTO-2: (54): Peer's policy verified 2) IKEv2-PROTO-2: (54): Verification of peer's authentication data PASSED 3) IKEv2-PROTO-2: (54): IKEV2 SA created; inserting SA into database. SA lifetime timer (86400 sec) started 4) IKEv2-PROTO-2: (54): Session with IKE ID PAIR (10.150.185.204, 10.11.10.10) is UP   *5*) IKEv2-PROTO-1: (54): Detected unsupported failover version One forum stated this was a problem with pfs, but we've confirmed both ends have pfs configured identically. There are limited hits when searching for this message on Google.   *6*) IKEv2-PROTO-2: (54): Process delete request from peer Debugging is set to 255 our end. We're regrouping this week, but I'm at a loss as to what to try next. Here is some debug info around the above #6 message: IKEv2-PROTO-2: (54): Sending Packet [To 10.150.185.204:4500/From 10.11.10.10:4500/VRF i0:f0] (54): Initiator SPI : 2B1AD530F5ADA576 - Responder SPI : A3773F2815F6BC2B Message id: 1 (54): IKEv2 INFORMATIONAL Exchange RESPONSEIKEv2-PROTO-3: (54): Next payload: ENCR, version: 2.0 (54): Exchange type: INFORMATIONAL, flags: INITIATOR MSG-RESPONSE (54): Message id: 1, length: 76(54): Payload contents: (54): ENCR(54): Next payload: DELETE, reserved: 0x0, length: 48 (54): Encrypted data: 44 bytes (54): IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000001 CurState: INFO_R Event: EV_CHK_INFO_TYPE IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000001 CurState: INFO_R Event: EV_RECV_DEL IKEv2-PROTO-2: (54): Process delete request from peer IKEv2-PROTO-2: (54): Processing DELETE INFO message for IKEv2 SA [ISPI: 0x2B1AD530F5ADA576 RSPI: 0xA3773F2815F6BC2B] IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000001 CurState: INFO_R Event: EV_CHK4_ACTIVE_SA IKEv2-PROTO-2: (54): Check for existing active SA IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000001 CurState: INFO_R Event: EV_STOP_ACCT IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000001 CurState: INFO_R Event: EV_IPSEC_DEL IKEv2-PROTO-2: (54): Delete all IKE SAs IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000001 CurState: INFO_R Event: EV_START_DEL_NEG_TMR IKEv2-PROTO-5: (54): Action: Action_Null IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000001 CurState: EXIT Event: EV_CHK_PENDING IKEv2-PROTO-5: (54): Sent response with message id 1, Requests can be accepted from range 2 to 2 IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000001 CurState: EXIT Event: EV_NO_EVENT IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (R) MsgID = 00000000 CurState: EXIT Event: EV_FREE_NEG IKEv2-PROTO-5: (54): Deleting negotiation context for peer message ID: 0x0 IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (I) MsgID = 00000001 CurState: READY Event: EV_RECV_DEL IKEv2-PROTO-5: (54): Action: Action_Null IKEv2-PROTO-5: (54): SM Trace-> SA: I_SPI=2B1AD530F5ADA576 R_SPI=A3773F2815F6BC2B (I) MsgID = 00000001 CurState: DELETE Event: EV_FREE_SA IKEv2-PROTO-2: (54): Deleting SA ... View more

We have an ASA 5555 running asa992-smp-k8.bin with multiple VPN tunnels and a 1 Gbps connection to the Internet. We recently installed a new tunnel to a Palo Alto firewall - unsure of the make or model or version of firmware. Speed is abysmal - less than 1 Mbps generally. On the ASA, the CPU is idling around 1-2%, free memory 73%, and 5 minute average traffic rate is typically around 100 Mbps. There aren't any errors or event on tunnel debugging or in the logs, but I have no visibility into the other side. I'm also not finding anything on Google. Any ideas? Thanks ... View more

First, thanks for any suggestions. I'm stumped at this point.   "debug crypto ips 127" yields the following, and it continues repeating over an over. The only thing that seem important is the message "IPSEC DEBUG: Received a DELETE PFKey message from IKE for an inbound SA".    IPSEC(crypto_map_check)-3: Looking for crypto map matching 5-tuple: Prot=1, saddr=172.16.9.198, sport=256, daddr=172.50.1.5, dport=256 IPSEC(crypto_map_check)-5: Checking crypto map CRYPTOMAP 5: skipping because 5-tuple does not match ACL ACL5 ... IPSEC(crypto_map_check)-5: Checking crypto map CRYPTOMAP 99: skipping because 5-tuple does not match ACL ACL99 IPSEC(crypto_map_check)-3: Checking crypto map CRYPTOMAP 150: matched. IPSEC DEBUG: Received a DELETE PFKey message from IKE for an inbound SA (SPI 0xC995E875) IPSEC DEBUG: Inbound SA (SPI 0xC995E875) destroy started, state embryonic IPSEC DEBUG: Inbound SA (SPI 0xC995E875) free started, state embryonic IPSEC DEBUG: Inbound SA (SPI 0xC995E875) free completed IPSEC DEBUG: Inbound SA (SPI 0xC995E875) destroy completed ... <continues repeating the above> ...   Packet-tracer yield the following. I found few hits on Google, but I did see https://community.cisco.com/t5/vpn-and-anyconnect/site-to-site-vpn-between-asa-9-9-1-and-bintec-router/m-p/3230693. I put the nat statement for this tunnel at the very top of the list, but it didn't help. The parameters in phase 13 look good, but the ASA drops the packets. Any clue as to what is going on? Phase: 1 Type: ACCESS-LIST Subtype: Result: ALLOW Config: Implicit Rule Additional Information: Forward Flow based lookup yields rule: in id=0x2aaad7f32cd0, priority=1, domain=permit, deny=false hits=13878009971, user_data=0x0, cs_id=0x0, l3_type=0x8 src mac=0000.0000.0000, mask=0000.0000.0000 dst mac=0000.0000.0000, mask=0100.0000.0000 input_ifc=inside, output_ifc=any Phase: 2 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 1.1.1.1 using egress ifc outside Phase: 3 Type: UN-NAT Subtype: static Result: ALLOW Config: nat (inside,outside) source static LOCALSITE LOCALSITE destination static AZR-VNET AZR-VNET no-proxy-arp route-lookup Additional Information: NAT divert to egress interface outside Untranslate 172.50.1.5/443 to 172.50.1.5/443 Phase: 4 Type: ROUTE-LOOKUP Subtype: Resolve Egress Interface Result: ALLOW Config: Additional Information: found next-hop 172.16.9.198 using egress ifc inside Phase: 5 Type: ACCESS-LIST Subtype: log Result: ALLOW Config: access-group INSIDE in interface inside access-list INSIDE remark Permit all other traffic from inside interface access-list INSIDE extended permit ip any4 any4 Additional Information: Forward Flow based lookup yields rule: in id=0x2aaad873c690, priority=13, domain=permit, deny=false hits=45569604, user_data=0x2aaacdad3540, cs_id=0x0, use_real_addr, flags=0x0, protocol=0 src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0 input_ifc=inside, output_ifc=any Phase: 6 Type: NAT Subtype: Result: ALLOW Config: nat (inside,outside) source static LOCALSITE LOCALSITE destination static AZR-VNET AZR-VNET no-proxy-arp route-lookup Additional Information: Static translate 172.16.9.198/50000 to 172.16.9.198/50000 Forward Flow based lookup yields rule: in id=0x2aaadad6bc80, priority=6, domain=nat, deny=false hits=26433, user_data=0x2aaadaace9a0, cs_id=0x0, flags=0x0, protocol=0 src ip/id=172.16.0.0, mask=255.255.0.0, port=0, tag=any dst ip/id=172.50.0.0, mask=255.255.0.0, port=0, tag=any, dscp=0x0 input_ifc=inside, output_ifc=outside Phase: 7 Type: NAT Subtype: per-session Result: ALLOW Config: Additional Information: Forward Flow based lookup yields rule: in id=0x2aaac927a3c0, priority=1, domain=nat-per-session, deny=true hits=168128170, user_data=0x0, cs_id=0x0, reverse, use_real_addr, flags=0x0, protocol=6 src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0 input_ifc=any, output_ifc=any Phase: 8 Type: IP-OPTIONS Subtype: Result: ALLOW Config: Additional Information: Forward Flow based lookup yields rule: in id=0x2aaad7f3bb00, priority=0, domain=inspect-ip-options, deny=true hits=56989875, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0 src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0 input_ifc=inside, output_ifc=any Phase: 9 Type: SFR Subtype: Result: ALLOW Config: class-map sfr match access-list sfr-redirect policy-map global_policy class sfr sfr fail-open monitor-only service-policy global_policy global Additional Information: Forward Flow based lookup yields rule: in id=0x2aaadb037b30, priority=71, domain=sfr, deny=false hits=50429730, user_data=0x2aaada45d390, cs_id=0x0, use_real_addr, flags=0x0, protocol=0 src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0 input_ifc=inside, output_ifc=any Phase: 10 Type: INSPECT Subtype: np-inspect Result: ALLOW Config: class-map class_http match port tcp eq https policy-map global_policy class class_http inspect http service-policy global_policy global Additional Information: Forward Flow based lookup yields rule: in id=0x2aaada452cf0, priority=70, domain=inspect-http, deny=false hits=39394070, user_data=0x2aaada451590, cs_id=0x0, use_real_addr, flags=0x0, protocol=6 src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any dst ip/id=0.0.0.0, mask=0.0.0.0, port=443, tag=any, dscp=0x0 input_ifc=inside, output_ifc=any Phase: 11 Type: FOVER Subtype: standby-update Result: ALLOW Config: Additional Information: Forward Flow based lookup yields rule: in id=0x2aaad848c460, priority=20, domain=lu, deny=false hits=44831731, user_data=0x0, cs_id=0x0, flags=0x0, protocol=6 src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0 input_ifc=inside, output_ifc=any Phase: 12 Type: VPN Subtype: ipsec-tunnel-flow Result: ALLOW Config: Additional Information: Forward Flow based lookup yields rule: in id=0x2aaada31b840, priority=13, domain=ipsec-tunnel-flow, deny=true hits=50528167, user_data=0x0, cs_id=0x0, flags=0x0, protocol=0 src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=any, dscp=0x0 input_ifc=inside, output_ifc=any Phase: 13 Type: VPN Subtype: encrypt Result: DROP Config: Additional Information: Forward Flow based lookup yields rule: out id=0x2aaadaeb7220, priority=70, domain=encrypt, deny=false hits=213, user_data=0x0, cs_id=0x2aaada27ddd0, reverse, flags=0x0, protocol=0 src ip/id=172.16.0.0, mask=255.255.0.0, port=0, tag=any dst ip/id=172.50.0.0, mask=255.255.0.0, port=0, tag=any, dscp=0x0 input_ifc=any, output_ifc=outside Result: input-interface: inside input-status: up input-line-status: up output-interface: outside output-status: up output-line-status: up Action: drop Drop-reason: (acl-drop) Flow is denied by configured rule ... View more

We're in the process of restricting the lines in one of our access lists, and I've run across some interesting hits that seem strange. The UDP timeout is set for 2 minutes, but we  have some traffic I wasn't expecting - it seems to me as if the UDP timer times out, because what's being matched on appears to me to be return traffic. We have more entries similar to the following with the destination port gt 50000, and I also have a "permit udp any any" after these entries. If I take out these entries with the source ports lt 1024 and the destination ports gt 50000, the "permit udp any any" will start incrementing again.    access-list   MYACL  line 13 extended permit udp  172.20.0.0 255.255.248.0   eq domain 172.16.16.0 255.255.248.0 gt 50000 (hitcnt=109) 0x934d4385 access-list MYACL line 19 extended permit udp   172.20.0.0  255.255.248.0  eq snmp 172.16.16.0 255.255.248.0 gt 50000 (hitcnt=409) 0x5e40e624   I remember crafting packets in the 80's with source port of 53 to get around the stateless ACLs on routers for UDP traffic, so I'm a little paranoid about permitting traffic that could potentially be a problem. I'd appreciate any thoughts here. ... View more