Shorewall Zones for the Two OpenVPN Packet Paths

Two packet flows cross a Shorewall gateway that terminates OpenVPN, and only one of them is encrypted. The first is the client's transport to the VPN listener on the internet-facing interface. The second is the decrypted request that leaves the tunnel interface for an office server or a service on the gateway. Map both before editing policy, because a rule that satisfies the first does nothing for the second.

Draw the Two Flows Before Editing Policy

Write the flows as rows with source, destination, protocol and port. On the outer path, the source is the client's public address and the destination is the gateway's listener port; Shorewall treats that as internet-to-firewall traffic. On the inner path, the source is the tunnel address range and the destination is the approved service. The two rows have different owners even when one administrator maintains both.

Add a row only if the request terminates on the gateway itself, such as resolver or management access. A service on the host follows host-input policy, not the forwarded path. Mixing the two is how a narrow tunnel rule ends up exposing an administration interface.

Assign the Tunnel Zone and Interface Scope

The road-warrior zone is declared in /etc/shorewall/zones, the tunnel interface is attached in /etc/shorewall/interfaces, and the outer connection is described in /etc/shorewall/tunnels. Match the installed release's syntax, because column order and option names have changed across major versions. The guide's example port is not a reason to permit a different port from the one the daemon actually listens on. TCP and UDP are not interchangeable just because the numbers match.

The guide groups interfaces with tun+. On a host with more than one tunnel, that wildcard can place a second VPN of a different trust level in the same zone. Review the scope against the interfaces that actually exist, and keep naming under the connection manager's lifecycle rather than editing interface names by hand.

The historical guide contains much older OpenVPN configuration samples, and its crypto advice should not be copied into a current deployment. Borrow the zone and flow model instead. Take the cryptographic baseline from the gateway's maintained OpenVPN policy.

Permit Only the Path You Classified

A broad VPN-zone-to-LAN acceptance is a starting diagram, not a finished policy. Write the permitted client source, the actual service address, the protocol and the port. Then read the rules above it and the zone default, because a narrow addition does not cancel a broad permit that already matches. Traffic to the gateway host is a separate relationship from traffic forwarded through it.

Peer-to-peer client traffic needs its own decision. OpenVPN's client-to-client and Shorewall's routeback both affect whether clients can reach each other, and neither should be enabled just to make one LAN application work. Decide where isolation is enforced before you test it.

Keep the reply path in the same plan. The service or its router must know how to return traffic to the tunnel range, or the design must translate the source deliberately and within the intended scope.

Validate, Then Prove Both Paths

Validate the configuration before restarting anything, and keep an independent administrative session open in case the new policy is wrong.

shorewall check

After a clean check, apply the configuration and read back what Shorewall loaded. These reads describe the running policy rather than what a file appears to say.

shorewall show zones
ip route get 192.168.10.20

Test one fresh permitted request and one deliberately denied request from the same client. A successful OpenVPN handshake proves the outer exchange only; the permitted service and the denied resource prove the inner policy you intended. Then reconnect the client and repeat, because the tunnel interface name and address can change between sessions. If the result differs, fix the zone scope rather than widening the rule.