Feature Request: Automatically (optionally?) add masquerade rules for unsafe routes

[dmurray14]

Currently the unsafe route/subnet configuration requires the user to manually configure NAT/masquerade for traffic sourced from the overlay towards the unsafe route subnet. I'd like to propose (optionally?) automating the process of adding the masquerade configuration (step 5 in the Nebula subnet routing guide) when unsafe routes are present on a host.

It seems the majority of use cases rely on NAT being configured for unsafe routes to work correctly; not configuring NAT would be the exception in cases where there is an upstream router/gateway directing traffic towards the overlay. If NAT is not configured, all of the other hosts on the same subnet as the overlay "router" will require static routes for the overlay subnet pointing to the Nebula host acting as the router. Both of these configurations seem like they would be the exception, not the norm.

Making NAT the default configuration also makes sense if there will be more than one subnet "router" exposing the same subnet to the overlay as there will be less chance of assymetric routing.

[virtadpt]

That wound be handy. It took some doing to figure out how to get it working reliably the first time.

[JackDoan]

systemd-networkd can help with this, at least on Linux hosts.

Adding firewall manipulation support on all of the platforms Nebula supports is not impossible, but is a non-trivial task (even on Linux, there's several different "ways" to do firewalling). I'd also be pretty scared to blindly add rules to a non-empty chain.

I will admit that it'd be pretty slick to be able to do this automatically for Windows users.

[nbrownus]

We chatted a little about this today and it sounded like doing the source address rewriting in nebula would be interesting. There was some concern about information loss at the routers system level firewall that we need to noodle on.

For future discussions:

• What would we want from the nebula firewall to help protect these routes that we don't have today?
• What does the configuration look like?
• What stats and logs would we want to emit?