🐛 BUG: Routing non‑Nebula source traffic through Nebula interface fails

[maj0rmil4d]

What version of nebula are you using? (nebula -version)

1.6.1

What operating system are you using?

Linux

Describe the Bug

I’m trying to use a Nebula node as an internet gateway for traffic that originates outside the Nebula overlay (from the host system or other routed networks). The goal is to route specific destinations (e.g. adobe.com) through a Nebula peer.

However, Nebula appears to drop this traffic because the source IP is not part of the Nebula certificate, and the internal firewall rejects it.

Environment:

node-edge (client machine)
node-1 (gateway / exit node)
node-2 (gateway / exit node)
Goal:

Route selected external traffic from node-edge through node-1,node-2 using the Nebula tunnel.

What I tried:

Routing traffic to a specific destination through the Nebula interface:
Example:

text
ip route add <destination_ip>/32 dev nebula1
Enabling IP forwarding and NAT on the gateway node:
text
sysctl -w net.ipv4.ip_forward=1

Firewall rules allowing traffic between hosts.
Observed behavior:

Nebula drops the packets maybe because the source IP is not a Nebula IP present in the certificate. From what I can tell, Nebula’s internal firewall requires that packet sources match the Nebula network identities defined in certificates.

This prevents using Nebula as a generic routed tunnel or exit gateway for system traffic.

Expected behavior:

Ideally it would be possible to allow routing of non‑Nebula source traffic through the overlay when explicitly configured, for example:

allowing forwarded packets with non‑Nebula source IPs
or an option to bypass the Nebula firewall for routed traffic
or a documented method for implementing an exit node / internet gateway
Questions:

Is routing non‑Nebula source traffic through a Nebula interface supported?
Is there a recommended configuration for implementing an exit node / gateway?
If not supported, is there a design reason the firewall strictly enforces certificate source IPs for forwarded traffic?
If helpful I can provide additional configs and packet captures.

Thanks!

Logs from affected hosts

Tcpdump show icmp, but it doesn't show any traffic that I routed to my exit node

Config files from affected hosts

[alemonmk]

I just did my little POC for that, though not for 0.0.0.0/0.

1. You should have 0.0.0.0/0 in unsafeNetworks (nebula-cert sign -unsafe-networks) in your gateway's certificate. Restrict traffic to your specific destinations with netfilter forward chain.
2. You need to have local_cidr equal to your Nebula network prefix in Nebula firewall rules. Those need to be added to every node. Rules itself I just allowed any to any, again netfilter forward chain.
3. Just turn on tun.use_system_route_table and not bother with tun.unsafe_routes to eliminate headaches.

[johnmaguire]

Hi @maj0rmil4d - as 1.6.1 is nearly 4 years old now, you may find that docs or advice you receive does not apply cleanly to your version. I highly recommend updating to a more recent version.

Nebula's unsafe_routes feature was originally built to expose nodes which are unable to run Nebula themselves (e.g. printers, Amazon RDS) to the network - not for running exit nodes. That said it should be possible to achieve the behavior you desire.

As @alemonmk correctly pointed out, you'll need the 0.0.0.0/0 in unsafeNetworks - otherwise other Nebula nodes will reject traffic from this host because the forwarded traffic's source IP doesn't match the certificate's IP. This explicitly allows the host to spoof traffic onto the Nebula network from any address within the unsafeNetworks CIDR. We encode this into the certificate to ensure that only users with access to the CA can grant this ability.

local_cidr does not exist in 1.6.1 (introduced in 1.7) and is permissive by default until 1.10. local_cidr is a per-rule filter on the address local to this node - the destination IP for inbound rules, the source IP for outbound rules.

If you upgrade to 1.10+ (strongly recommended), local_cidr on a firewall rule defaults to the node's own Nebula address. So, to forward traffic to or from unsafeNetworks ranges, you'll need to set it explicitly to the range being forwarded to or from:

• On the gateway: an inbound rule with local_cidr: 0.0.0.0/0 so it accepts traffic destined for the internet.
• On node-edge (if forwarding for other networks): an outbound rule with local_cidr: <lan-cidr> (or 0.0.0.0/0) so its own firewall doesn't drop packets whose source IP isn't node-edge's Nebula address.

Return traffic in both directions is allowed automatically via conntrack, so you don't generally need inbound rules on node-edge or outbound rules on the gateway for this scenario.