Alternative route table and 0.0.0.0 routing

[dd0ke]

Added preliminary support for the creation of routes in alternative route tables on Linux, and using default routes via Nebula.
Nebula would crash anytime a default route was added or modified, regardless of the default route being added on to a separate table.

Requires new config param:

Specify the alternative routing table for created routes.

If unset, defaults to main routing table.

#alternative_routing_table: "my_alt_table"

[salesforce-cla]

Thanks for the contribution! Before we can merge this, we need @dd0ke to sign the Salesforce Inc. Contributor License Agreement.

[JackDoan]

The location of this file seems like it could be distro-specific. Should it be configurable? Can the information instead be obtained via netlink or /proc?

[JackDoan]

This comment is technically true, but #6 for IPv6 overlay support is gonna merge any day now!

[johnmaguire]

Hi @dd0ke - it's been a minute, so I wanted to touch base. We recently landed #1331 which may solve your needs. If not, could you share a bit about why you still prefer this approach? Additionally, I see there is some open review feedback. Are you still working on this PR?

[dd0ke]

Hello hello there, It’s been some time since I’ve tinkered with Nebula. The topic is somewhat digressing, but here is the scope objective: Permit default route or the use of alternative routing table to apply default route for Nebula traffic. Packet marking is related to the issue indirectly. Since alternative tables were not usable, the workaround was to mark packets to respond via the appropriate gateway. Packet marking is still necessary, and I will test your updates, as part of the end goal is to make Nebula behave like a stateless over-the-top VPN via anycast IPs for clients and gateways. I have this working with some of the modifications I suggested for a PR. Basically, my Nebula clients can get public IPs on an anycast subnet, and employ the most optimal gateway for the outbound and return path, also inducing some redundancy perks in the process. This is an improvement over how Wireguard works, as Wireguard creates persistent routes for all its peers which go to the void if the endpoint is not connected. I didn’t want to setup Wireguard with a distributed table or coordination service like Tailscale/Headscale, or over complicated implementations in the likes of Netbird. Will update when I can test your changes!

…

On Apr 3, 2025, at 5:15 PM, John Maguire ***@***.***> wrote: johnmaguire left a comment (slackhq/nebula#1324) Hi @dd0ke - it's been a minute, so I wanted to touch base. We recently landed #1331 which may solve your needs. If not, could you share a bit about why you still prefer this approach? Additionally, I see there is some open review feedback. Are you still working on this PR? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned. <https://github.com/dd0ke> <#1331> <#1324 (comment)> <https://github.com/notifications/unsubscribe-auth/AF7LKBP6DBMVH7VWGAFELD32XVGCZAVCNFSM6AAAAABWHRLPTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONZWGE2DANBYGI> johnmaguire left a comment (slackhq/nebula#1324) <#1324 (comment)> Hi @dd0ke <https://github.com/dd0ke> - it's been a minute, so I wanted to touch base. We recently landed #1331 <#1331> which may solve your needs. If not, could you share a bit about why you still prefer this approach? Additionally, I see there is some open review feedback. Are you still working on this PR? — Reply to this email directly, view it on GitHub <#1324 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AF7LKBP6DBMVH7VWGAFELD32XVGCZAVCNFSM6AAAAABWHRLPTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONZWGE2DANBYGI>. You are receiving this because you were mentioned.