Source-Based Default Route Issue – MX68 to IPsec Remote Network (Invalid Next Hop)

Bartounet
Here to help

Source-Based Default Route Issue – MX68 to IPsec Remote Network (Invalid Next Hop)

Hello,

We would like to implement full traffic routing from one of our remote sites (behind an MX68) to a Public WiFi provider through an existing IPsec VPN tunnel established in our central datacenter.

Current Architecture

  • Remote site connected via SD-WAN (AutoVPN) to our central site

    • Remote MX: MX68 (Spoke)

    • Central MX: MX250 (Hub)

  • Remote site LAN subnet: 192.168.50.0/25

  • IPsec tunnel (Datacenter ↔ Public WiFi Provider)

    • Remote provider subnet behind IPsec: 172.21.0.0/30

    • Provider cloud equipment IP: 172.21.0.2

Current Status

  • Traffic from the remote site (192.168.50.0/25) successfully reaches the central site through SD-WAN (AutoVPN).

  • From the central site, traffic properly traverses the IPsec tunnel.

  • We can successfully reach the provider subnet (172.21.0.0/30) from the remote site.

  • End-to-end connectivity between 192.168.50.0/25 and 172.21.0.0/30 is working correctly.

Requirement

The Public WiFi provider will soon enforce traffic filtering.
Therefore, we must redirect all traffic originating from the remote site subnet (192.168.50.0/25) to the provider’s cloud equipment (172.21.0.2) through the existing IPsec tunnel.

In other words, we need to implement a source-based default route so that all outbound traffic from 192.168.50.0/25 uses 172.21.0.2 as next hop via the IPsec tunnel.

Issue Encountered

When attempting to configure a source-based default route on the MX, we receive the following error:

"There were errors in saving this configuration:
The source-based route 'UCOPIA' has an invalid next hop IP. The IP address 172.21.0.2 is not on a configured subnet."

It appears that the MX does not accept 172.21.0.2 as a valid next hop because it is not part of a locally configured subnet, even though it is reachable via the IPsec VPN.

Main Problem

We are unable to redirect all traffic from 192.168.50.0/25 to 172.21.0.2.

 

Bartounet_0-1770975053554.png

 

Bartounet_1-1770975112014.pngBartounet_2-1770975127856.pngBartounet_3-1770975149483.png

 

 

Route with 172.21.0.0/30 is kown and work with a ping !!!!

Bartounet_4-1770975229982.pngBartounet_5-1770975268218.png

 

1 Reply 1
alemabrahao
Kind of a big deal
Kind of a big deal

Actually, that's not a problem; you need to have an SVI with that subnet created to point to that IP as the next hop.

 

 

There are two types of source based default routes. The only difference between a LAN and VPN source-based default routes is the next hop.

i. LAN based default route

ii. VPN based default route

 

LAN source based default route - The next hop of a LAN source-based default route is on the LAN side of the MX security appliance. The next-hop IP is known to the security appliance on the LAN side either by a VLAN or a static route. 

 

VPN source based default route - The next-hop of a VPN source-based default route is an MX security appliance on another network within the same dashboard Organization. Use this option if the source subnet is participating in AutoVPN.

 

This doesn't work for a non-Meraki VPN.

I am not a Cisco Meraki employee. My suggestions are based on documentation of Meraki best practices and day-to-day experience.

Please, if this post was useful, leave your kudos and mark it as solved.
Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco ID. If you don't yet have a Cisco ID, you can sign up.
Labels