Re: Last-resort tunnel recommendations on WAN network ...

[Bryan Holloway via NANOG <nanog () lists nanog org>]

Thank you to everyone who offered up suggestions.

To summarize, I agree that a UNIX VM is the most flexible solution, but 
we have concerns about supporting it. Router-jocks won't know how to 
troubleshoot if the guy who put it together gets hit by a bus.

Yes, Wireguard is hands-down easier to implement than IPsec!! I love it. 
I use it on my home networks, and it was trivial to set up. If only 
there were more appliances that used it out of the box. This would be my 
ideal solution.

And yes -- MikroTik supports Wireguard, but in our experience, 
Mikrotik's VRF implementation isn't ready for prime-time.

Thanks again to everyone that chimed in. Very much appreciated!

                        - bryan


On 3/12/26 19:25, Bryan Holloway via NANOG wrote:
> Greetings, Dear Community!
>
> Consider the following scenario: major colo with a pair of transits, 
> peering, and a single transport back to another colo on our backbone.
>
> Transport carries public but also several overlays (VRFs) for management 
> and whatnot.
>
> If the transport fails, we're good on transit/peering, but we can't get 
> back to the mothership for mgmt.
>
> We're looking at solutions (secure tunnels over transit) to bring the 
> severed colo back to "HQ" ... looking at a hub/spoke topology with the 
> intent of possibly doing this more than once.
>
> Requirements:
> * Multiple VRFs across the tunnel
>
> * OSPF - each VRF should have its own instance, so we need something 
> that supports interface-based tunneling since IPsec doesn't handle 
> multicast well. Open to other tunneling strategies. Wireguard? OpenVPN?
>
> * v6 a plus (OSPFv3)
>
> * 10G should suffice across the board, but it should have interfaces 
> that are LAGable.
>
> The appliances we have considered so far do most if not all of these 
> things, but they come with a lot of features (and cost) we simply don't 
> need (e.g., UTM, DPI)
>
> Also open to something server (VM) based since our traffic requirements 
> aren't that significant.
>
> Easy to support is obviously a plus.
>
> Curious if others have had similar needs and how they solved this problem.
>
> Recommendations (good or bad) greatly appreciated.
>
> Thank you!
>
>          - bryan
>
> _______________________________________________
> NANOG mailing list https://lists.nanog.org/archives/list/ 
> nanog () lists nanog org/message/77KTXLHWHFQTPIGG7EQCWQVNZVTJP3TS/

_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/X6D6QINEUUSUTJGTRUZGLAK6ZK36ELC7/