BGP Over IPsec Tunnel

[Bits-n-Bytes]

Hello,

I'm attempting to connect to a remote vendor subnet via a passthrough MX appliance. After some research, it appears this is not possible using static routes.

I did switch to using a BGP IPsec tunnel between our own MX appliances but that also presented a challenge. On the very bottom of the IPsec BGP Deployment Guide, there's a footnote that says Note: Statically defined local routes configured on passthrough MX devices are not exported to the eBGP peer over IPsec

When I tried the BGP tunnel, the local Azure LAN and remote vendor subnets were not exported to the on-prem MX250. Our vMX and MX250 are not AutoVPN peers as the MX250 is part of an old organization.

I feel like the only way to solve this is to enable BGP on the IPsec tunnel with the Vendor (unfortunately not an option here) and move the Azure LAN stuff to a completely different firewall that's part of our AutoVPN deployment. Am I off in left field? 

Here's a drawing that helps explain my problem. Thanks for reading.

[PhilipDAth]

What happens if you make it iBGP (and use the same ASN everywhere)?

[Bits-n-Bytes]

I did try this, but the dashboard will NOT let me configure iBGP on the S2S IPsec link. I tried using 64512 on both ends and it errors out. It wants a unique ASN on each end. Perhaps there's a work around for this?

[Tony-Sydney-AU]

Hi @Bits-n-Bytes ,

Yes, that's a current design limitation MX have. As per our doc, "iBGP sessions are automatically established between MX appliances over their Meraki AutoVPN tunnels. It is important to note that iBGP is only established between MX devices within the same AutoVPN domain".

So eBGP is the only option when doing non-Meraki VPN at the moment. You can make a Feature Request (FR) for that.

A possible workaround is to deploy a VPN hub/concentrator in a VMX in Azure. This VMX would be a transit network between your other MX (iBGP) and the non-Meraki (eBGP).

Alternatively, you may deploy Azure VPN Gateway to act like a VPN hub/concentrator instead of deploying VMX. Just like @PhilipDAth suggested later in this post.

I honestly don't know if VMX is cheaper than Azure VPN Gateway. But I believe it would be easier to support and troubleshoot than Azure VPN Gateway.

[PhilipDAth]

What about getting the vendor to build a second VPN to the MX250?

[Bits-n-Bytes]

This is my current plan. In a perfect world all of the vendor tunnels lived on the Azure vMX but this will work as a plan-b. 

My other plan is to try moving the MX250 and vMX into the same org, this will allow us to use AutoVPN... Maybe this bypasses the "hairpin" routing issue when trying to access a foreign network on an IPsec tunnel. I'll post here if this works.

[PhilipDAth]

Another option: what about terminating the vendor VPN on an Azure VPN Gateway?

[Bits-n-Bytes]

Oh I see, yes this would work. I asked but they have strict restrictions on what they will peer with. In theory they'd never know but I did ask and they're not willing to support this (unfortunately) 

[Tony-Sydney-AU]

@Bits-n-Bytes ,

You may convert your VMX from passthrough to routed mode. Or maybe deploy a new VMX in routed mode.

This post has a really nice example on how to deploy a routed mode VMX and establishing BGP peering over IPsec.