One-arm for a branch site?

[Aaron_Wilson]

Stick with me on this one, it's an odd request.....

Lets say I have two companies, A & B.

A is 192.168.0.0/24

B is 192.168.10.0/24

Company A has a normal MX hub, nothing special. For arguments sake, dual-arm with public IP on WAN interface.

Company A buys Company B (again argument sake, no legal concerns) and wants to access their network for whatever reason (again, this is all technical).

I have been trying to lab this out but am failing. My thought was to slap a MX on Company B network in single arm mode.

• Company B MX would receive 192.168.10.10 IP address and access internet from existing local network connection.
• Company B adds static route of 192.168.0.0/24 via 192.168.10.10
• Company A learns of 192.168.10.0/24 via VPN route table

For the most part the Meraki gear seems to accept this configuration. The part which doesn't work is the AutoVPN between spoke and hub. It sees the peer but has red indicators showing it's not established.

I know this is reverse of your typical deployment, but I am trying to work around the fact you cannot create a L3 interface on a MX of the local LAN.

[KRobert]

Rather than a Single Arm Concentrator at Company B, why don't you make it a spoke MX and have the HUB be Company at Company A? As for as your statement regarding L3 interface on a MX Local LAN, you could achieve this by enabling VLANs on the MX and adding the desired IP information. Add the VLAN just to the port you want to have an "L3 Interface" and that would be a way to create an L3 interface on the local LAN.

[KarstenI · Accepted solution]

First, this should work and it is pretty much what I am running in my office (MX in routed mode) and home-office (Z3 in concentrator mode in a DMZ of a Firepower Appliance).

If it does not work I would first look at the internet-connection of the spoke-MX. Is the access-control and NAT ready to support the MX?

But I would also evaluate if you can replace the current firewall with the MX or add the MX to the given setup in routed mode with a direct connection to the internet. That could make everything a little easier.

[Aaron_Wilson]

KRobert - Company B is spoke, in single arm mode.

Regarding making a LAN port a L3 interface, how do you define the gateway/next hop? If I create a VLAN on the MX at Company B of 192.168.0.0/24 and give the MX an IP of 192.168.10.2, how do I tell it and Company A to use 192.168.10.1 (the actual Company B router) for everything?

Karstenl - Maybe it is a NAT issue. The spoke works fine when in dual-arm mode, but flip to single-arm and it gets all kind of angry. To me it would seem weird that the VPN can establish in dual-arm mode but not establish in single arm mode. Also, my testing is with just the WAN port connected, I didn't move beyond that because of the lack of VPN connection.

I can't place it in a DMZ because A) one may not exist and B) trying to make this as low config as possible. The desire was to just drop a single-arm Meraki into an office to bring in the tunnel. Then with just a static route on their network for return traffic (192.168.0.0/24 via MX LAN IP) the Company A location could access their entire 192.168.10.0/24 network.

My goal is to not require separate internet or DMZ for the outside interface terminating the VPN. Trying to go with a cookie cutter method for unknown networks. It's a funky setup I know, but just trying out something new.

[KarstenI]

The approach of configuring a 192.168.0.0 network on Site B can not work. That would be L2 bridging which is not available on the MX and in most cases not a good solution.

There should be no difference in the VPN connectivity of dual-armed vs. one-armed. Is it only the VPN-connection that is failing or also the connection to the VPN registry?

Have you done any changes at the site1 MX? Is there any config for the 192.168.10.0 in MX1? That could be a problem.

[Aaron_Wilson]

I have made further progress today. I finally got things to connect after I switch my testing from a Z3 and MX67 to a MX67 and MX65. The Z3 was NOT happy with the VPN to the MX67 for who knows why. Either there was something wrong with the hardware or the auto vpn was getting seriously screwed up.

Yea, I was hoping for layer 2 bridging, but I'd be OK with a single static entry.

Here is what I have working so far:

-Company A configured as hub using 192.168.10.0/24 for vlan and injecting into VPN

-Company B configured as single arm spoke, has 192.168.1.70 from 192.168.1.0/24 range

-Company A can ping Company B 192.168.1.70 over VPN

-Company B can ping Company A VLAN IP 192.168.10.1

-Company A devices can ping Company B 192.168.1.70

As soon as I get Company B to enter a static route for 192.168.10.0/24 via 192.168.1.70 I think that will get things to work! *fingers crossed*

[KarstenI]

Sounds good, I would also expect that it will work. When adding the route to the router/firewall, make sure that this device is able to "hairpin" the traffic. For example, a Cisco ASA would not do that without dirty config.

[Aaron_Wilson]

All is working fine with static route in place. Time now to see why the Z3 keeps freaking out.

Thanks all!

[ww]

Can you share a screen of the red/errors

Did you also advertise 192.168.10.0/24 at the s2s-vpn settings, local networks, on the one arm site?