1

I have a WireGuard VPN Server running on a Debian 12 host with no problems, listening on a specific UDP port, and all is working great with no issues. I can connect from my phone WireGuard client while on 5G etc and all works as intended.

However I want to temporarily allow somebody access to this server, but restrict them to only accessing devices on my local network, 192.168.0.x - No access to the public internet once they are connected to the VPN so they can't visit general websites etc. just access devices on 192.168.0.x as needed

I am just a novice home user and tried this set of commands:

iptables -I OUTPUT -d 192.168.0.0/16 -j ACCEPT; iptables -P OUTPUT DROP
iptables -A INPUT -p udp -m udp --dport ##### -j ACCEPT
iptables -A INPUT -p udp -m udp --sport ##### -j ACCEPT

where ##### is the correct listening port to the outside world. And on the host, generally seems to work as intended - I can communicate with all 192.168.0.0 devices and nothing outside of that scope - only problem is, I can also no longer connect via 5G to ######, my previously working VPN listen port.

Any assistance would be greatly appreciated, thank you!

Edit:

Another user told me to try FORWARD so I tried this but still no change, the daemon did not answer when tried from the outside world

iptables -I OUTPUT -d 192.168.0.0/16 -j ACCEPT; iptables -P OUTPUT DROP
iptables -A FORWARD -p udp -m udp --sport ##### -j ACCEPT
iptables -A FORWARD -p udp -m udp --dport ##### -j ACCEPT

1 Answer 1

0
  1. You did not permit OUTPUT from the server with that source port; you permitted INPUT instead (which will not match anything). You need an output rule that allows packets with --sport ##### to leave from the server back to your WireGuard clients.

  2. Packets from a VPN client going through the server are not OUTPUT – they are FORWARD. Your "VPN to LAN" access rules should be in the FORWARD chain.

    (Because of this, you don't actually need to filter output at all – you could leave the OUTPUT chain on the ACCEPT policy without any rules.)

  3. You also need rules that allow packets back from LAN to the VPN. Usually one would have a catch-all "established" rule in FORWARD, i.e. -m state --state ESTABLISHED,RELATED that uses conntrack to automatically permit reply packets belonging to existing connections.

3
  • Thank you very much for the quick reply - as mentioned I am a novice user trying to learn! I am not sure if this is what you mean, but I tried: iptables -I OUTPUT -d 192.168.0.0/16 -j ACCEPT; iptables -P OUTPUT DROP iptables -A FORWARD -p udp -m udp --sport ##### -j ACCEPT iptables -A FORWARD -p udp -m udp --dport ##### -j ACCEPT instead, and still no response on that port from the outside world. Still never gets past the trying to connect stage. Did I do it wrong? Commented Aug 4, 2023 at 20:15
  • You still don't have a rule that would allow the WireGuard packets to come out of the server – previously you had it in 'INPUT', now you have it in 'FORWARD', but you still don't have anything in 'OUTPUT'... i.e. you got it completely backwards. The "outer" WireGuard packets are input/output (they are consumed and generated by WG on the server); the "inner" tunneled packets from/to LAN are what's being forwarded. Commented Aug 4, 2023 at 20:31
  • I guess I vaguely understand, but only vaguely. I am unsure what I am supposed to be doing here to fix the problem, unfortunately, as I don't understand what you are telling me to do. Since I don't have any knowledge of such syntax or in depth knowledge of the program. Thanks for letting me know I have it backwards, but I am looking for assistance still if anyone else sees this. Thanks anyways! Commented Aug 5, 2023 at 1:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .