ufw route allow: permit forwarded traffic between interfaces (VPN, Docker, routers)
- tool
- ufw
- command
- ufw
- flag
- route allow
- default
- no route rules; forwarded traffic follows the routed default policy (deny on a standard install)
sudo ufw route allow in on wg0 out on eth0 allows packets that arrive on wg0 and leave on eth0 to be forwarded through the host. ufw's ordinary allow rules filter traffic addressed to the machine itself (the INPUT chain); traffic that only passes through it, from a VPN to the LAN, from containers or virtual machines to the internet, or between two networks on a router, goes through the FORWARD path and is governed by route rules and the routed default policy. Without a route rule, that traffic is dropped by the default deny (routed) policy.
Examples from the manual and common setups
sudo ufw route allow in on eth1 out on eth2 # everything eth1 -> eth2
sudo ufw route allow in on eth0 out on eth1 to 12.34.45.67 port 80 proto tcp # one service only
sudo ufw route allow in on wg0 out on eth0 # WireGuard clients to the LAN/internet
sudo ufw route delete allow in on wg0 out on eth0 # remove it againRoute rules accept the same from, to, port, proto, app, log and comment parts as normal rules, plus in on IFACE and out on IFACE.
Forwarding also has to be enabled
The ufw manual lists the kernel settings that must be enabled, in /etc/ufw/sysctl.conf:
net/ipv4/ip_forward=1
net/ipv6/conf/default/forwarding=1
net/ipv6/conf/all/forwarding=1followed by ufw disable and ufw enable to restart the firewall. The manual warns that sysctl settings are operating-system specific and may be overridden elsewhere.
Route rules versus the routed policy
| Setting | Effect |
|---|---|
| ufw default deny routed | Forwarded traffic is dropped unless a route rule allows it |
| ufw default allow routed | All forwarded traffic passes; route deny rules can still block parts |
| ufw route allow ... | Opens one forwarding path |
| ufw route deny / reject / limit ... | Blocks, rejects or rate-limits a forwarding path |
The underlying DEFAULT_FORWARD_POLICY in /etc/default/ufw is explained in ufw default forward policy.
Pitfalls
- NAT is separate. For a VPN server that gives clients internet access, add a masquerade rule in the
*nattable of/etc/ufw/before.rules; route rules do not translate addresses. - Docker. Docker inserts its own FORWARD rules ahead of ufw's, so published container ports may bypass ufw entirely; filtering container traffic needs Docker's
DOCKER-USERchain or a different setup. - Direction words. For route rules,
in onnames the interface the packet arrives on andout onthe one it leaves through; swapping them opens the opposite direction only. - Check before applying. Preview the generated FORWARD rules with ufw --dry-run. For WireGuard, the peer's
AllowedIPsmust also cover the routed network; see WireGuard AllowedIPs.
FAQ
Why does my VPN connect but clients cannot reach the LAN?
Traffic from the VPN interface to the LAN is forwarded, not addressed to the host, so ufw's incoming rules do not apply. With the default routed policy deny, it is dropped until you add a route allow rule (and enable IP forwarding).
Do I need route rules if I set the routed policy to allow?
No, ufw default allow routed lets all forwarded traffic through. Specific route allow rules with a deny policy are the safer choice, because they open only the paths you need.
Does ufw route allow enable NAT?
No. Route rules only filter the FORWARD path. Masquerading for a VPN or a private network is configured separately, usually with a *nat section in /etc/ufw/before.rules.