07-01-2024 01:34 PM - edited 07-01-2024 02:43 PM
Hi,
I have a router with dual ISPs and two tunnel interfaces. For ISP load-balancing I use floating default routes. Each tunnel interface uses as the source IP each WAN interface and the HUB's destination IP is the same for both tunnels. My problem is that the VPN negotiation fails because the Tunnel interface using the backup ISP seems to use the active default route.
In a nutshell, I want to force the the secondary generates and replies to the HUB using the stand-by ISP. Is that possible?
Configuration summary:
interface Tunnel1
tunnel source GigabitEthernet0/0/1
tunnel destination 1.1.1.1
interface Tunnel2
tunnel source GigabitEthernet0/0/0
tunnel destination 1.1.1.1
interface GigabitEthernet0/0/0
description Backup ISP
ip address 2.2.2.2 255.255.255.252
!
interface GigabitEthernet0/0/1
description Primary ISP
ip address 3.3.3.3 255.255.255.252
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0/0 2.2.2.1 10
ip route 0.0.0.0 0.0.0.0 GigabitEthernet0/0/1 3.3.3.1
Thanks
Solved! Go to Solution.
07-02-2024 06:14 AM - edited 07-02-2024 06:28 AM
It's definitely possible to use primary and backup tunnels via different ISPs to the same tunnel destination. Use local PBR to correctly route IKE packets. And use "tunnel route-via ... mandatory" tunnel interface CLI to correctly route GRE/ESP packets. Local PBR doesn't work for them because GRE and ESP packets are considered as transit traffic rather than the traffic which is originated by the router itself.
And to clarify: the "tunnel source" command sets sender IP address only. The packet is still routed according to the routing table. The "tunnel route-via <interface> mandatory" CLI restricts routes to be considered to just those which go via the configured <interface>.
07-01-2024 02:21 PM
can you more elaborate
you tag the issue with DMVPN and I dont see any config of DMVPN ?
MHM
07-01-2024 02:38 PM
Apologies. Let me elaborate a bit more the configurations. (Note that I'm replacing sensitive data)
Perhaps the issue is more related with a local PBR config needed to force the traffic.
crypto isakmp policy 1
encr aes 256
hash sha256
authentication pre-share
group 5
lifetime 28800
crypto isakmp key x.x.x.x address 1.1.1.1
crypto isakmp profile Main-HUB
keyring default
match identity address 1.1.1.1 255.255.255.255
!
crypto ipsec transform-set Main-HUB esp-aes 256 esp-sha256-hmac
mode tunnel
!
crypto ipsec profile DMVPN
set transform-set Main-HUB
!
interface Tunnel0
description Tunnel 1 to Main HUB
ip address 192.168.1.2 255.255.255.252
no ip redirects
no ip proxy-arp
ip flow ingress
ip flow egress
ip mtu 1400
ip ospf mtu-ignore
ip ospf 1 area 0
tunnel source GigabitEthernet0/0/0
tunnel mode ipsec ipv4
tunnel destination 1.1.1.1
tunnel protection ipsec profile DMVPN
!
interface Tunnel1
descriptionTunnel 1 to Main HUB
ip address 192.168.2.2 255.255.255.252
no ip redirects
no ip proxy-arp
ip flow ingress
ip flow egress
ip mtu 1400
ip ospf mtu-ignore
ip ospf 1 area 0
tunnel source GigabitEthernet0/0/1
tunnel mode ipsec ipv4
tunnel destination 1.1.1.1
tunnel protection ipsec profile DMVPN
!
07-01-2024 02:42 PM
Ok, I just realised that this router is no longer participating in DMVPN as some other routers in the customer network does. Apologies. It is in a traditional GRE/IPSec configuration.
07-02-2024 06:14 AM - edited 07-02-2024 06:28 AM
It's definitely possible to use primary and backup tunnels via different ISPs to the same tunnel destination. Use local PBR to correctly route IKE packets. And use "tunnel route-via ... mandatory" tunnel interface CLI to correctly route GRE/ESP packets. Local PBR doesn't work for them because GRE and ESP packets are considered as transit traffic rather than the traffic which is originated by the router itself.
And to clarify: the "tunnel source" command sets sender IP address only. The packet is still routed according to the routing table. The "tunnel route-via <interface> mandatory" CLI restricts routes to be considered to just those which go via the configured <interface>.
07-05-2024 12:52 PM
Working perfectly. Thanks!
07-06-2024 12:58 AM
Welcome.
07-02-2024 06:15 AM - edited 07-05-2024 01:02 PM
MHM
07-05-2024 01:04 PM
You change the tunnel source interface?
I am so sure I see same interface!!
MHM
07-06-2024 10:28 PM
I just added the "tunnel route-via... mandatory" command and two static route towards the same IP of the HUB using as a next hop the ISP routers. Did tests shutting down each ISP interface, reloading the routers and both tunnel interfaces worked.
07-07-2024 02:15 AM
No Friend in original post I totally sure I see both tunnel use same interface, maybe you edit later
Anyway
glad issue is solve
have a nice happy summer
MHM
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