Inability to Forward Traffic on OpenWrt When Using --accept-clients #996

New Issue

MrUnknownDE · 2026-04-05T18:05:35+02:00

MrUnknownDE commented

2026-04-05 18:05:35 +02:00

Originally created by @burjuyz on 8/28/2025

I am trying to use newt on an OpenWrt router to provide access to my local LAN (192.168.10.0/24) for remote clients. This is often referred to as a "site-to-site" or "subnet router" configuration.

The newt client on the OpenWrt router is configured as a "site" (gateway) and runs with the --accept-clients flag. The local subnet is correctly configured as a "Resource" on the Pangolin server, associated with the OpenWrt client.

Remote clients (e.g., a Windows machine running newt) connect successfully. The remote client correctly receives the route for 192.168.10.0/24.

The Problem

While the tunnel is established, there is a fundamental issue with traffic forwarding:

Pinging the Gateway's Virtual IP works: The remote client can successfully ping the virtual IP address of the OpenWrt newt instance (e.g., 100.90.128.1). This confirms that the tunnel itself is up and the newt process on the router is responsive.
Pinging the LAN Fails: The remote client cannot ping any device on the local LAN (e.g., 192.168.10.200). The packets are lost.

Root Cause Analysis & Diagnostics

After extensive debugging, we have determined that the issue stems from the fact that newt operates entirely in userspace and does not create a kernel TUN/TAP interface.

This creates a disconnect between the newt process and the OpenWrt's kernel networking stack (which uses nftables).

Here’s what we've confirmed through diagnostics:

Encrypted traffic arrives: tcpdump on the router's WAN interface shows encrypted UDP packets arriving from the Pangolin server when the remote client sends a ping.
Decrypted packets never enter the kernel's forwarding path:
- tcpdump on the br-lan interface (or any interface) never shows the decrypted ICMP packets.
- Packet counters on the nftables FORWARD chain rules remain at zero.
- This proves that the decrypted packet is never handed off from the newt process to the kernel for routing and firewall processing.
Kernel is correctly configured for forwarding: We have verified that net.ipv4.ip_forward = 1 and net.ipv4.conf.all.rp_filter = 0.
Firewall rules have no effect: We have tried multiple firewall configurations (both iptables-compat and native nftables via uci), including creating dedicated zones, masquerading (NAT), and explicit ACCEPT rules for the traffic. None of these rules are ever triggered because the packets never reach the firewall subsystem.

Conclusion

The core issue is a lack of integration between the userspace newt process and the kernel's routing and firewall engine. For traffic forwarding to work, the decrypted packets must be injected into the kernel's networking stack. The most standard and robust way to achieve this is by using a TUN virtual network interface.

Without the ability for newt to create or bind to a TUN interface, it appears impossible to use it as a proper subnet gateway on OpenWrt (and likely other Linux-based systems). The --accept-clients functionality seems to be broken for any scenario that requires kernel-level packet forwarding.

Suggested Solution / Feature Request

Please consider adding a feature to the newt client, possibly via a new command-line flag (e.g., --create-tun), that creates a TUN interface and forwards all site-to-site traffic through it. This would allow for seamless and standard integration with the host operating system's networking and firewall capabilities, making the subnet routing feature truly functional.

*Originally created by @burjuyz on 8/28/2025* I am trying to use `newt` on an OpenWrt router to provide access to my local LAN (`192.168.10.0/24`) for remote clients. This is often referred to as a "site-to-site" or "subnet router" configuration. The `newt` client on the OpenWrt router is configured as a "site" (gateway) and runs with the `--accept-clients` flag. The local subnet is correctly configured as a "Resource" on the Pangolin server, associated with the OpenWrt client. Remote clients (e.g., a Windows machine running `newt`) connect successfully. The remote client correctly receives the route for `192.168.10.0/24`. #### **The Problem** While the tunnel is established, there is a fundamental issue with traffic forwarding: 1. **Pinging the Gateway's Virtual IP works:** The remote client can successfully ping the virtual IP address of the OpenWrt `newt` instance (e.g., `100.90.128.1`). This confirms that the tunnel itself is up and the `newt` process on the router is responsive. 2. **Pinging the LAN Fails:** The remote client **cannot** ping any device on the local LAN (e.g., `192.168.10.200`). The packets are lost. #### **Root Cause Analysis & Diagnostics** After extensive debugging, we have determined that the issue stems from the fact that **`newt` operates entirely in userspace and does not create a kernel TUN/TAP interface.** This creates a disconnect between the `newt` process and the OpenWrt's kernel networking stack (which uses `nftables`). Here’s what we've confirmed through diagnostics: * **Encrypted traffic arrives:** `tcpdump` on the router's WAN interface shows encrypted UDP packets arriving from the Pangolin server when the remote client sends a ping. * **Decrypted packets never enter the kernel's forwarding path:** * `tcpdump` on the `br-lan` interface (or `any` interface) **never** shows the decrypted ICMP packets. * Packet counters on the `nftables` `FORWARD` chain rules remain at zero. * This proves that the decrypted packet is never handed off from the `newt` process to the kernel for routing and firewall processing. * **Kernel is correctly configured for forwarding:** We have verified that `net.ipv4.ip_forward = 1` and `net.ipv4.conf.all.rp_filter = 0`. * **Firewall rules have no effect:** We have tried multiple firewall configurations (both `iptables-compat` and native `nftables` via `uci`), including creating dedicated zones, masquerading (NAT), and explicit `ACCEPT` rules for the traffic. None of these rules are ever triggered because the packets never reach the firewall subsystem. #### **Conclusion** The core issue is a lack of integration between the userspace `newt` process and the kernel's routing and firewall engine. For traffic forwarding to work, the decrypted packets must be injected into the kernel's networking stack. The most standard and robust way to achieve this is by using a **TUN virtual network interface**. Without the ability for `newt` to create or bind to a TUN interface, it appears impossible to use it as a proper subnet gateway on OpenWrt (and likely other Linux-based systems). The `--accept-clients` functionality seems to be broken for any scenario that requires kernel-level packet forwarding. #### **Suggested Solution / Feature Request** Please consider adding a feature to the `newt` client, possibly via a new command-line flag (e.g., `--create-tun`), that creates a TUN interface and forwards all site-to-site traffic through it. This would allow for seamless and standard integration with the host operating system's networking and firewall capabilities, making the subnet routing feature truly functional.

MrUnknownDE closed this issue

2026-04-05 18:05:35 +02:00

Sign in to join this conversation.

Branches Tags

main

dev

dependabot/npm_and_yarn/dev-minor-updates-b4e5d6b9c5

revert-2766-feature/systemd-install-instructions

dependabot/npm_and_yarn/prod-patch-updates-05702d39f2

dependabot/npm_and_yarn/next-16.2.1

dependabot/npm_and_yarn/recharts-3.8.1

alerting-rules

private-site-ha

dependabot/docker/docker/library/node-25-slim

ssh

delete-account

msg-delivery

org-only-idp

cicd

patch

site-targets-auto-login

No Label

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/pangolin#996