Hello can FlexVPN implemented on Cat 9500 and 9300 switches pls ?
Hello Hab
FlexVPN is a feature that is available only on Cisco routers. You can see more info about compatibility and platform support of FlexVPN in the following documentation:
So, unfortunately, the 9500 and 9300 do not support FlexVPN, because these devices are primarily designed for campus and data center switching, rather than being VPN concentrators.
I hope this has been helpful!
Laz
I followed the outline but Iâm getting a few errors.
001609: *Jan 6 03:26:24.389: %ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of Tunnel1 - looped chain attempting to stack
001610: *Jan 6 03:26:26.037: %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing
001611: *Jan 6 03:26:26.037: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down
001612: *Jan 6 03:26:26.289: IKEv2:(SA ID = 1):Retransmitting packet
001613: *Jan 6 03:26:26.289: IKEv2:(SA ID = 1):Sending Packet [To 98.xx.xx.xx:4500/From 192.168.1.190:4500/VRF i0:f0]
Initiator SPI : 06D974DD25B1A0DF - Responder SPI : 0FEBD183B05898BB Message id: 2
IKEv2 INFORMATIONAL Exchange REQUEST
Payload contents:
ENCR
001614: *Jan 6 03:26:26.297: IKEv2:Detected an invalid IKE SPI
001615: *Jan 6 03:26:26.297: IKEv2:Couldn't find matching SA
001616: *Jan 6 03:26:26.297: IKEv2:(SA ID = 0):Received Packet [From 98.xx.xx.xx:4500/To 192.168.1.190:4500/VRF i0:f0]
Initiator SPI : ABCEA0BC8F907150 - Responder SPI : 037F1AFB09699BCE Message id: 0
IKEv2 INFORMATIONAL Exchange REQUEST
001617: *Jan 6 03:26:26.297: IKEv2:A supplied parameter is incorrect
001618: *Jan 6 03:26:26.297: IKEv2:
001619: *Jan 6 03:26:30.157: IKEv2:Detected an invalid IKE SPI
001620: *Jan 6 03:26:30.157: IKEv2:Couldn't find matching SA
001621: *Jan 6 03:26:30.157: IKEv2:(SA ID = 0):Received Packet [From 98.xx.xx.xx.xx:4500/To 192.168.1.190:4500/VRF i0:f0]
Initiator SPI : ABCEA0BC8F907150 - Responder SPI : 037F1AFB09699BCE Message id: 0
IKEv2 INFORMATIONAL Exchange REQUEST
001622: *Jan 6 03:26:30.157: IKEv2:A supplied parameter is incorrect
Hello Matthew
The error messages youâre encountering while configuring FlexVPN on Cisco devices indicate several issues that need to be addressed:
The first one has to do with Recursive Routing Issues. The messages %TUN-5-RECURDOWN: Tunnel1 temporarily disabled due to recursive routing and %ADJ-5-PARENT: Midchain parent maintenance... suggest a recursive routing problem. This typically happens when the route to the tunnel destination is learned through the tunnel itself, causing a loop.
Secondly, it seems that you have IKEv2 Errors. The repeated IKEv2 errors (Detected an invalid IKE SPI, Couldn't find matching SA, A supplied parameter is incorrect) point to issues with the IKEv2 Security Association (SA) negotiation. This could be due to a mismatch in the IKEv2 policy parameters (encryption, hash, authentication, etc.) between the FlexVPN peers.
Without knowing more about your configuration, I can make some suggestions and give you some guidelines as to how you can proceed in your troubleshooting:
-
Check Routing Configuration: Ensure that the routes to the tunnel endpoints are not learned through the tunnel itself. You might need to define specific static routes or adjust your dynamic routing protocol configuration to prevent recursive routing.
-
Verify IKEv2 Configuration:
- Check the IKEv2 policies on both ends of the VPN to ensure they match exactly in terms of encryption algorithms, hash algorithms, and other parameters.
- Ensure that the correct keyring and profiles are being used and that the endpoint addresses in the IKEv2 profiles are correctly configured.
- The
IKEv2:A supplied parameter is incorrecterror suggests that there might be a misconfiguration in one of the IKEv2 parameters. Double-check all the parameters carefully.
-
Review Tunnel Configuration: Verify the tunnel interface settings, including source and destination addresses, and ensure they are correctly configured.
Looking at these configuration parameters you should be able to determine the problem in your topology. Let us know how you get along and if you need any further assistance.
I hope this has been helpful!
Laz
Hi,
I used this lesson as a model to build my own FexVPN hub and spoke. I did NOT wish to use ikev2 routing and instead plan to use BGP at a future date. so my hub and spoke crypto ikev2 profile has only:
show run | se crypto ikev2 profile
crypto ikev2 profile LNEFLEXVPN_PROFILE
match identity remote address 44.228.114.254 255.255.255.255
match identity remote address 0.0.0.0
authentication remote pre-share
authentication local pre-share
keyring local LNBRwestspoke_KEYRING
aaa authorization group psk list LNE-FLEXVPN default
Currently the tunnel is showing up up on the spoke and I see a âVirtual-Access1â interface on my hub.
AWSBR02aDC-NEW#show crypto ipsec sa
interface: Virtual-Access1
Crypto map tag: Virtual-Access1-head-0, local addr 10.149.135.44
protected vrf: (none)
local ident (addr/mask/prot/port): (10.149.135.44/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (65.243.77.214/255.255.255.255/47/0)
current_peer 65.243.77.214 port 5761
PERMIT, flags={origin_is_acl,}
#pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 10.149.135.44, remote crypto endpt.: 65.243.77.214
plaintext mtu 1426, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet2
current outbound spi: 0x487A84DA(1215988954)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0x29F1C09F(703709343)
transform: esp-256-aes esp-sha512-hmac ,
in use settings ={Transport UDP-Encaps, }
conn id: 2001, flow_id: CSR:1, sibling_flags FFFFFFFF80000008, crypto map: Virtual-Access1-head-0, initiator : False
sa timing: remaining key lifetime (k/sec): (4608000/2342)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x487A84DA(1215988954)
transform: esp-256-aes esp-sha512-hmac ,
in use settings ={Transport UDP-Encaps, }
conn id: 2002, flow_id: CSR:2, sibling_flags FFFFFFFF80000008, crypto map: Virtual-Access1-head-0, initiator : False
sa timing: remaining key lifetime (k/sec): (4607999/2342)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
and on spoke:
show crypto ipsec sa
interface: Tunnel150
Crypto map tag: Tunnel150-head-0, local addr 10.44.86.2
protected vrf: (none)
local ident (addr/mask/prot/port): (10.44.86.2/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (44.228.114.254/255.255.255.255/47/0)
current_peer 44.228.114.254 port 4500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 176, #pkts encrypt: 176, #pkts digest: 176
#pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 10.44.86.2, remote crypto endpt.: 44.228.114.254
plaintext mtu 1426, path mtu 1500, ip mtu 1500, ip mtu idb Port-channel1.801
current outbound spi: 0x29F1C09F(703709343)
PFS (Y/N): N, DH group: none
inbound esp sas:
spi: 0x487A84DA(1215988954)
transform: esp-256-aes esp-sha512-hmac ,
in use settings ={Transport UDP-Encaps, }
conn id: 2020, flow_id: ESG:20, sibling_flags FFFFFFFF80004008, crypto map: Tunnel150-head-0, initiator : True
sa timing: remaining key lifetime (k/sec): (4607999/2307)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0x29F1C09F(703709343)
transform: esp-256-aes esp-sha512-hmac ,
in use settings ={Transport UDP-Encaps, }
conn id: 2019, flow_id: ESG:19, sibling_flags FFFFFFFF80004008, crypto map: Tunnel150-head-0, initiator : True
sa timing: remaining key lifetime (k/sec): (4607985/2307)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE(ACTIVE)
outbound ah sas:
outbound pcp sas:
I am unable to ping the hub (172.16.150.1) from the spoke (172.16.150.5).
Any ideas on how I can troubleshoot this issue further?
-Brian
Hello Brian
From the configs you have shared, there donât seem to be any outstanding issues that immediately point to the problem. The IPsec tunnel itself is successfully established (both inbound and outbound SAs are ACTIVE), so Phase 1 and Phase 2 look fine. The main problem is that there is no end-to-end connectivity to transfer traffic inside the tunnel.
This could be due to several factors. I can share with you some thoughts that may help point you in the right direction for your troubleshooting process:
- Since youâre not using IKEv2 routing, the first thing that comes to mind is that you need to look at your routing configuration. Verify that the hubâs routing table includes the spokeâs subnet. Spokes should have a default route pointing to the hubâs tunnel IP.
- Ensure that the tunnel interfaces are configured correctly and are in the same subnet.
- Verify using
debug cyrpto ikev2 packetanddebug crypto ipsec. See below document for more debugging information:
I hope this gives you some insight into your next steps, let us know how you get along!
I hope this has been helpful!
Laz
Hello, I found a typo in 1.1.1. IKEv2 Keyring.
Dash between pre-shared and key is missing.
Hub1(config)#crypto ikev2 keyring IKEV2_KEYRING
Hub1(config-ikev2-keyring)#peer SPOKE_ROUTERS
Hub1(config-ikev2-keyring-peer)#address 0.0.0.0 0.0.0.0
Hub1(config-ikev2-keyring-peer)#pre-shared key local CISCO
Hub1(config-ikev2-keyring-peer)#pre-shared key remote CISCO
Hello Bernd
Indeed you are correct, thanks for pointing that out! I will let @ReneMolenaar know to make the correction.
Thanks again!
Laz