Learn WireGuard - Firewall & Access Control

#Introduction

WireGuard secures the tunnel, but it is not a firewall replacement. The firewall determines who can reach port 51820, what traffic may pass through the wg0 interface, and what happens to packets arriving from the tunnel. The two work together: WireGuard handles the cryptography, the firewall handles the network policy.

Episode 14 covers integrating WireGuard with nftables and iptables, policies through PostUp and PostDown, and key-based access control that makes revoking access instantaneous.

#Opening the UDP Port

#Minimal Prerequisite

For peers to handshake, the UDP ListenPort must be reachable from the outside. In nftables:

table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        udp dport 51820 accept
    }
}

The equivalent line in iptables:

sudo iptables -A INPUT -p udp --dport 51820 -j ACCEPT

The rule above allows handshakes from anyone on the internet. To restrict it, add -s <peer public address> to the iptables rule.

#Integration with PostUp and PostDown

#A Policy That Rises with the Interface

PostUp and PostDown run commands when the interface goes up and down. This is the right place for rules that live and die with wg0 — no separate script needed:

[Interface]
Address = 10.0.0.1/24
ListenPort = 51820
PrivateKey = <kunci privat server>
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

Two things to note:

• Commands are separated by semicolons, not &&.
• Every PostUp rule must have its removal counterpart in PostDown, so no rule is left dangling when the interface goes down.

#Zone-Based Firewall

#Restricting Access Between Subnets

For finer control, separate policies by traffic direction. For example, remote access clients may reach the application subnet but not the admin subnet:

table inet filter {
    chain forward {
        type filter hook forward priority 0; policy drop;
        iifname "wg0" oifname "eth0" ip saddr 10.0.0.0/24 accept
        iifname "eth0" oifname "wg0" ct state related,established accept
    }
}

These rules build a zone model: wg0 is the client zone and eth0 is the internal network zone. Clients may only leave toward eth0, and reply packets are only accepted when they are part of an already permitted connection. Zone models like this are what firewalld uses internally.

#Using firewalld

If you use firewalld, register the tunnel interface in a dedicated zone and allow the required inter-zone traffic. The approach is consistent with the same concept — distinguishing trusted interfaces, tunnels, and the internet.

#Key-Based Access Control

#Keys as Policy

Because WireGuard's identity is the public key, controlling access is the same as controlling the peer list. Adding access means adding a peer; revoking access means removing a peer. There is no user list to sync.

sudo wg set wg0 peer <PUBLIK_CLIENT> remove

The wg set wg0 peer ... remove command makes that peer immediately unable to handshake. Combined with zone firewall rules, the result: unknown peers can never send valid packets, and known peers are still restricted by the zone policy.

#Combining Both Layers

The best policy uses both layers at once: cryptokey routing decides who can enter the tunnel, and the zone firewall decides where traffic may go once inside. The first layer answers "are you legitimate," the second answers "what are you allowed to do."

#Policy Audit

#Checking the Installed Rules

Before considering a configuration safe, check what is actually active:

sudo nft list ruleset
sudo iptables -S
sudo iptables -t nat -S

Compare the output with what was planned. Unknown FORWARD and NAT rules are the first sign of a deviating configuration. Add this audit to your maintenance habits along with the peer audit in episode 12.

#Closing

Episode 14 completed firewall and access control integration: opening the UDP port, arranging policies through PostUp and PostDown, applying a zone model with nftables, and controlling access on a key basis.

Key takeaways:

• Open UDP on ListenPort so handshakes can happen.
• PostUp and PostDown use semicolons for multiple commands.
• Every PostUp rule has its removal counterpart in PostDown.
• A zone model restricts access between tunnel subnets.
• Revoking access is as simple as removing a peer.
• Routine nft list ruleset and iptables -S audits keep the policy clean.

In episode 15 we cover performance and kernel optimizations — multiqueue TUN, GRO and GSO offloading, throughput benchmarking with iperf3, and a performance comparison of WireGuard with OpenVPN and IPsec.