ā06-09-2023 04:47 AM - edited ā06-09-2023 06:18 AM
Hi all, currently I am working on a network project using a highly available core (2xISR4451) using HSRP to 3 different spokes, having 3 GRE tunnels, and using IPSEC. I used this method previously for point-to-point networks and worked perfectly. however, this time since I added another 2 sites and at the core introduced HSRP I had to change the tunnel source from the interface number to the HSRP virtual IP address in order to get the status UP. Up till here worked perfectly however when I came to include the IPSEC and under the tunnel interface used: tunnel protection ipsec profile {profile name } shared an error occurred:
Error: Tunnel11 - shared tunnel protection is not supported when tunnel source is specified as an IP address. Configure "tunnel source <interface>" when using shared tunnel protection.
Do I need to create a profile for each tunnel in order not to use the shared key ?
Is there any workaround ??? because if change tunnel source address to the interface the tunnel will never terminate on the virtual IP for high availability
Below is the sample code:
[Router R1 Core]
crypto ikev2 proposal ikev2propsal
encryption aes-cbc-256
integrity sha256
group 5
!
crypto ikev2 policy ikev2policy
match fvrf any
proposal ikev2propsal
!
crypto ikev2 keyring keys
peer site_B
address 20.100.255.4
pre-shared-key cNETkey2023
!
crypto ikev2 profile ikev2profile
match identity remote address 20.100.255.4 255.255.255.255
authentication local pre-share
authentication remote pre-share
keyring local keys
!
crypto ikev2 dpd 10 2 on-demand
crypto isakmp keepalive 10
!
crypto ipsec transform-set myset esp-aes 256 esp-sha-hmac
mode tunnel
!
crypto ipsec profile cnetprofile
set transform-set myset
set ikev2-profile ikev2profile
!
interface Tunnel11
description VOIP_FW
ip address 20.100.10.1 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1300
tunnel source 20.100.255.1
tunnel destination 20.100.255.4
tunnel key 11
!
!
interface Tunnel12
description dataB
ip address 20.100.20.1 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1300
tunnel source 20.100.255.1
tunnel destination 20.100.255.4
tunnel key 12
!
interface GigabitEthernet0/0/1
description UHF_LINK_FW
ip address 20.100.255.2 255.255.255.248
standby version 2
standby 11 ip 20.100.255.1
standby 11 timers msec 300 msec 900
standby 11 priority 105
standby 11 preempt
standby 11 authentication md5 key-string 7 14343C2E38
negotiation auto
!
[Spoke Router]
!
crypto ikev2 proposal ikev2propsal
encryption aes-cbc-256
integrity sha256
group 5
!
crypto ikev2 policy ikev2policy
match fvrf any
proposal ikev2propsal
!
crypto ikev2 keyring keys
peer site_A
address 20.100.255.1
pre-shared-key cNETkey2023
!
crypto ikev2 profile ikev2profile
match identity remote address 20.100.255.1 255.255.255.255
authentication remote pre-share
authentication local pre-share
keyring local keys
!
crypto ikev2 dpd 10 2 on-demand
!
crypto isakmp keepalive 10
!
crypto ipsec transform-set myset esp-aes 256 esp-sha-hmac
mode tunnel
!
crypto ipsec profile cnetprofile
set transform-set myset
set ikev2-profile ikev2profile
!
!
interface Tunnel11
description VOIP
ip address 20.100.10.2 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1300
tunnel source GigabitEthernet0/0/0
tunnel destination 20.100.255.1
tunnel key 11
!
!
interface Tunnel12
description dataB
ip address 20.100.20.2 255.255.255.252
ip mtu 1400
ip tcp adjust-mss 1300
tunnel source GigabitEthernet0/0/0
tunnel destination 20.100.255.1
tunnel key 12
!
interface GigabitEthernet0/0/0
description UHF_LINK
ip address 20.100.255.4 255.255.255.248
negotiation auto
!
Under the tunnel interface due to error I did not include tunnel protection in the above code.
below is the network diagram :
ā06-09-2023 04:55 AM
In hub and spoke I see only one tunnel why you need shared for ipsec profile???
ā06-09-2023 06:20 AM
sorry i was posting an abstract of the actual configuration as it is a bit long I added another tunnel. For each spoke I have 3 tunnels Data A, data B and Managment Data
ā06-09-2023 06:23 AM - edited ā06-09-2023 07:02 AM
It true shared keyword can use only if you use interface in tunnel source not IP'
will make lab check this issue
thanks
MHM
ā06-09-2023 07:43 AM - edited ā06-09-2023 07:44 AM
thanks a lot, if needed i can provide the whole config.
ā06-09-2023 08:11 AM
No need
Thanks
MHM
ā08-04-2023 01:02 AM
Hello sir by any chance did you find any solution for the above issue ? meanwhile I did a small workaround by using the 2nd router rising floating static route from the spoke routers and to keep track of the main tunnel I am using IP SLA as these will be encrypted pings rather using GRE keepalives where the reply will unencrypted.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide