Routing between 2 MX devices over a WAN Link (without VPN)

Solved
Bigmadchopper
New here

Routing between 2 MX devices over a WAN Link (without VPN)

HI all

 have a customer with a setup (diagram below). they have an application which will not work over a VPN link and we need to get it routing across the native WAN Links (Private WAN Links on dedicated VRF). We have an MX85 Pair on one side and an MX 105 pair on the DC side. Both MX pairs are in routed mode. We need to route from Private IP address on the client site to a private IP address on the DC side

 

Bigmadchopper_0-1698751282960.png

Is there some way of routing this as opposed to Natting everything over the WAN Link ... ie NAT exemption ... i have read similar forums where meraki support can enable something for this but it works on a complete interface level

 

any help greatly appreciated 

 

1 Accepted Solution
alemabrahao
Kind of a big deal
Kind of a big deal

It's a @GreenMan 's answer in this post.

https://community.meraki.com/t5/Security-SD-WAN/MX-WAN-ports-Without-NAT/m-p/128618#M32004

You absolutely can use MX WAN ports to link to your MPLS - and in many cases, you probably should.

As mentioned previously, for any Spoke VLANs that are configured to be 'VPN mode = enabled', their IP addressing will remain native across the VPN, inside the tunnels.

It's where you have VLANs that are 'VPN mode = disabled' where NAT comes in.   This might be for a Guest VLAN, for example.   Traffic from those VLANs, bound for anything other than a VLAN or route on the local MX would indeed be NATed out of the preferred WAN interface.  That doesn't mean that those clients can't access resources on the MPLS network (in fact, you may well want to take steps to ensure that they can't) - but the MPLS routing will need to account for the source IP being different.  Bear in mind too that any inbound session requests, (e.g. to a server at the spoke site), outside of any tunnels, will also be dropped, by default.  You would need to configure port forwarding, 1:1 NAT etc. to allow such communications.   https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX

 

You may well have come across MPLS links being connected to MX LAN ports - this too is possible, but it delivers to a failover scenario - it's not SD-WAN:   https://documentation.meraki.com/MX/Deployment_Guides/MPLS_Failover_to_Meraki_Auto_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.

View solution in original post

4 Replies 4
alemabrahao
Kind of a big deal
Kind of a big deal

It's a @GreenMan 's answer in this post.

https://community.meraki.com/t5/Security-SD-WAN/MX-WAN-ports-Without-NAT/m-p/128618#M32004

You absolutely can use MX WAN ports to link to your MPLS - and in many cases, you probably should.

As mentioned previously, for any Spoke VLANs that are configured to be 'VPN mode = enabled', their IP addressing will remain native across the VPN, inside the tunnels.

It's where you have VLANs that are 'VPN mode = disabled' where NAT comes in.   This might be for a Guest VLAN, for example.   Traffic from those VLANs, bound for anything other than a VLAN or route on the local MX would indeed be NATed out of the preferred WAN interface.  That doesn't mean that those clients can't access resources on the MPLS network (in fact, you may well want to take steps to ensure that they can't) - but the MPLS routing will need to account for the source IP being different.  Bear in mind too that any inbound session requests, (e.g. to a server at the spoke site), outside of any tunnels, will also be dropped, by default.  You would need to configure port forwarding, 1:1 NAT etc. to allow such communications.   https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX

 

You may well have come across MPLS links being connected to MX LAN ports - this too is possible, but it delivers to a failover scenario - it's not SD-WAN:   https://documentation.meraki.com/MX/Deployment_Guides/MPLS_Failover_to_Meraki_Auto_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.
Bigmadchopper
New here

Thanks for response @alemabrahao 

 

 

GreenMan
Meraki Employee
Meraki Employee

A few things occur to me on this:

Unusual for an application simply not to work over VPN   (?)

You mention a private network, but the diagram shows only the Internet?

If you connect the MXs to the private network via a WAN port, you will need to ensure there is Internet breakout available to the MXs via that path, in order for the WAN links to come up.

Under the scenario referenced previously however, note that VPN mode = disabled VLANs do have their source addresses NATed outbound over the MX WAN port, which I think you want to avoid.

If you connect via a WAN port, you could have no-NAT enabled by Meraki Support (this is what you referenced in regards forum posts, in your query) - you can have this enabled per VLAN, so as not to affect other traffic.   If you set up the relevant clients / hosts at each end to be in such VLANs, this might work for you - but be aware that no-NAT is a beta capability.   Have a careful read of this:  https://documentation.meraki.com/MX/Networks_and_Routing/NAT_Exceptions-No_NAT_on_MX_Security_Applia...


You could interconnect the two MXs using LAN ports instead, via transit VLANs and some static routing - such traffic is not NATed    You'll need to consider that that path would then need to be OK for all traffic between those subnets.
https://documentation.meraki.com/MX/Networks_and_Routing/MX_Addressing_and_VLANs#Static_routes

https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior

 

Bigmadchopper
New here

thanks for the response @GreenMan  ... 

 

 I think there might be some mileage in connecting the LAN ports, as you suggested

 

Will test and update with any success 

Get notified when there are additional replies to this discussion.