OpenWrt VPN zone, forwarding and masquerading: which one?

Three changes get mixed together whenever a VPN meets OpenWrt: opening a port, allowing forwarding, and turning on masquerading. They answer different questions, and usually only one of them is the actual requirement. Reading each control by the traffic role it governs turns a guess into a decision, and it also tells you which symptom to expect when the change is wrong. Start by naming the role that failed, not the checkbox you remember.

Name the traffic role before you touch a control

Zone input decides what may reach the router itself. Zone output covers traffic the router originates, zone forwarding is the default for traffic passing through a zone, and masquerading decides whether the source address is rewritten on the way out. Those are four different questions, and a zone policy answers all of them at once with the same value, which is why a zone-wide change is a blunt instrument. A named rule can answer one of them without touching the rest.

The useful map is by traffic role, because that is what you can observe when something fails. Each role below has one control that decides it and one symptom that points at it:

A listener on the router needs one narrow input rule

An OpenVPN server on the router receives traffic addressed to the router, so its outer connection depends on the input policy of the zone that carries it. Permit the configured transport and port and leave everything else in that zone rejecting. A single port rule is a much smaller change than a zone-wide accept, and it is the one you can still explain a year later.

Two things make that rule safe to keep: it names the port the service actually uses, and it sits beside the zone definition so the next person sees why it exists. The lines below are the shape, with the port standing in for whatever the server is configured to use. Change that port in both places when the service moves, because a rule left on the old one is invisible until an audit.

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

Validate before you reload, because a syntax error in a firewall file can leave the router without a working ruleset. On a release that uses fw4 the check is a separate command, and it fails loudly rather than silently accepting a broken stanza. Reload only after the check passes, and keep the previous file where you can put it back.

fw4 check
service firewall reload

A client request crosses forwarding, not input

After authentication, a tunnel client asking for a LAN service produces a forwarded flow, so the control that decides it is the forwarding relationship between the tunnel zone and the LAN zone. Assign the tunnel interface to the intended zone, then declare the direction, the sources and the service. The zone assignment is what makes the forwarding rule mean anything, and the two only make sense read together. A forwarding relationship that names the tunnel zone as its source and the LAN zone as its destination reads as one deliberate decision, whereas two zone-wide accepts read as an accident.

Reaching the router itself still uses the input path, which is why a ping to the gateway says nothing about the file share behind it. Those two failures live in different stanzas and get fixed by different edits. Write both paths down separately before you change either one.

Masquerading is a routing decision, not a permission

Masquerading rewrites the source address of selected outbound traffic. It can rescue an egress design where the far side has no route back, and it also hides individual client addresses from any service that logs or authorizes by address. Turning it off is a routing choice about the return path, not a security toggle that closes an inbound hole. A tunnel that works with translation on and fails the moment it is disabled usually has a missing return route, not a missing firewall rule.

A routed alternative needs a return route on the far side instead of translation. Neither option supplies the firewall permission or the application account, which is why disabling masquerading almost never fixes a tunnel client that cannot reach anything. Treat IPv4 and IPv6 policy separately as well, since one translation setting does not describe both families.

Prove the decision with an allowed and a denied request

Send one request that should be allowed and one that should be refused, then identify the control that made each decision. A page that happens to load is not evidence; the evidence is the rule that matched, in the chain that matched it. The refusal matters as much as the success, because it shows the policy is doing something rather than everything being permitted.

Two commands give you that evidence on a current release. The counter on the matching rule moves when the request is accepted, and the log shows the drop if you enabled logging for the rule:

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

Keep an administration path you can still use before you change any firewall policy, and follow the configuration owner's validation and rollback process. A change that locks you out of the router is not a test result, it is a second incident. Record the zone and the traffic role next to each observation, so the pair of results explains the policy instead of describing a lucky page load.