Skip to content

Configurable source-CIDR transit allowlist for router/gateway use cases #5338

@ebfull

Description

@ebfull

Add a firewall setting that exposes a configurable list of source CIDRs whose forwarded/transit traffic should be accepted by Nym's killswitch/firewall policy. (This should be distinct from the existing lan set allow|block toggle.)

Motivation

The existing LAN setting accepts forward-chain traffic based on destination address, via add_allow_lan_rules drawing from the hard-coded ALLOWED_LAN_NETS list. That behavior is correct for endpoint use cases such as letting the machine reach printers, routers, NAS devices, or other LAN services while the killswitch is enabled.

However, it does not cover router/gateway use cases where the NymVPN host is forwarding transit traffic from a downstream network out through the tunnel. Basically, I have a machine advertising as a tailnet exit node, forwarding client traffic (commonly sourced from 100.64.0.0/10 shared address space) through Nym.

In these cases, the forwarded traffic's source IP is well-defined and under the admin's control. The destination is arbitrary internet traffic, so the existing destination-based LAN accept rule does not match. As a result, Nym's forward chain drops the traffic by policy, and there is currently no clean opt-in mechanism for this router/gateway mode.

Current workaround

The current workaround is to delete Nym's forward chain after nym-vpnd brings it up, plus a watcher to re-delete it if recreated. That is brittle, hostile to Nym's firewall design, and much broader than the policy exception actually needed.

Requested behavior

Add a new setting along the lines of:

[firewall]
killswitch_transit_allow_source_cidrs = [
  "100.64.0.0/10",     # tailnet / RFC 6598 shared address space
  "192.168.50.0/24",   # downstream LAN
  "fd00:1234::/64"
]

For each configured CIDR, Nym should generate a forward chain rule that accepts forwarded traffic whose source IP matches that CIDR.

Ideally, the rule should be scoped so that the accepted transit traffic is still expected to egress via the Nym tunnel interface, e.g. nymtun0, rather than turning this into a broad physical-interface leak path.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions