Remote Access
This is the classic setup where remote peers initiate a connection to a server that is reachable through the internet, that then forwards their traffic onward.
Traffic Handling
The main choice is route or masquerade .
Routing
If you route, the client’s VPN IP address is what other devices see. This is generally preferred as it allows you to log who was doing what at the individual servers. But you must update your network equipment to treat the central server as a router.
Masquerading
Masquerading causes the server to translate all the traffic. This makes everything look like its coming from the server. It’s less secure, but less complicated and much quicker to implement.
For this first example, we will masquerade traffic from the server.
Central Server Config
Enable Forwarding and Masquerade
Use sysctl
to enable forwarding on the server and nft
to add masquerade.
# as root
sysctl -w net.ipv4.ip_forward=1
nft flush ruleset
nft add table nat
nft add chain nat postrouting { type nat hook postrouting priority 100\; }
nft add rule nat postrouting masquerade
Persist Rules
It’s best if we add our new rules onto the defaults and enable the nftables service.
# as root
echo "net.ipv4.ip_forward=1" >> /etc/sysctl.conf
nft list ruleset >> /etc/nftables.conf
systemctl enable --now nftables.service
Client Config
Your remote peer - the one you created when setting up the server - needs it’s AllowedIPs
adjusted so it knows to send more traffic through the tunnel.
Full Tunnel
This sends all traffic from the client over the VPN.
AllowedIPs = 0.0.0.0/0
Split Tunnel
The most common config is to send specific networks through the tunnel. This keeps netflix and such off the VPN
AllowedIPs = 192.168.100.0/24, 192.168.XXX.XXX, 192.168.XXX.YYY
DNS
In some cases, you’ll need the client to use your internal DNS server to resolve private domain names. Make sure this server is in the AllowedIPs above.
[Interface]
PrivateKey = ....
Address = ...
DNS = 192.168.1.1
Firewall Rules
You may want to apply some controls to your clients, such as preventing them from talking to each other while still letting them ping the server and having an ‘admin’ station. You can do this by adding rules to the forward chain.
# Allow an 'admin' peer at .2 full access to others and accept their replies
sudo nft add rule inet filter forward iifname "wg0" ip saddr 192.168.100.2 accept
sudo nft add rule inet filter forward ct state {established, related} accept
# Reject any other traffic between peers
sudo nft add rule inet filter forward iifname "wg0" oifname "wg0" reject with icmp type admin-prohibited
You can persist this change by editing your /etc/nftables.conf
file to look like this.
sudo vi /etc/nftables.conf
#!/usr/sbin/nft -f
flush ruleset
table inet filter {
chain input {
type filter hook input priority 0;
}
chain forward {
type filter hook forward priority 0;
# Accept admin traffic
iifname "wg0" ip saddr 192.168.40.4 accept
iifname "wg0" ct state {established, related} accept
# Reject other traffic between peers
iifname "wg0" oifname "wg0" reject with icmp type admin-prohibited
}
chain output {
type filter hook output priority 0;
}
}
table ip nat {
chain postrouting {
type nat hook postrouting priority srcnat; policy accept;
masquerade
}
}
Note: The syntax of the file is slightly different than the command. You can use nft list ruleset
to see how nft commands translate into running rules. If you get desperate, you can install iptables to add old examples (that get translated on the fly into nft) and list rules to see how to they turn out
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.