Wireguard- How to restrict LAN resource access by WAN clients?

[0vrthnk]

Asus RG-58AXU
Merlin FW v3004.388.8_4

Hi, first post after much lurking/searching. I have to believe that this is not an uncommon use case, but no joy so far for Asus Merlin/wireguard.

I have a functional wireguard(server) vpn running in my RG-58AXU w/ one WAN Android client accessing my NVR over cellular data.
Works great. Orders of magnitude(subjectively) faster for this purpose than OpenVPN, which I tested first before trying wireguard. I'd like wireguard a WHOLE lot more with authentication, but that's a different challenge.

I am not using the VPN for any other LAN to WAN traffic.

Is there any way within the Merlin UI to limit incoming/outgoing WAN vpn access to specific LAN resources?

Example(not my actual numbers):

RG-58AXU LAN IP: 192.168.1.1
wireguard port: 56354
NVR on LAN, IP 192.168.1.101:14777
Android wireguard client 10.6.0.10

I need to restrict the wireguard client LAN access to the NVR _only_.
I'm not averse to blocking ALL wireguard traffic except port 14777, if that's doable, but it seems heavy-handed.
I do NOT want to resort to local firewall rules on the other devices on my LAN, etc

If not through the ui, if this can be accomplished w/ a script, etc through SSH, can anyone point me in the direction of some code that could be adapted to my use case?

My iptable kung-fu blows, but I'm very willing to try/learn.

Thanks so much for any help/thoughts.

 

[ZebMcKayhan]

Is there any way within the Merlin UI to limit incoming/outgoing WAN vpn access to specific LAN resources?

Well, yes... perhaps possible to setup something using network service filter. However, I would use firewall-start to add my custom firewall rules:
https://github.com/RMerl/asuswrt-merlin.ng/wiki/User-scripts

If you want to block all but one ip it could be done in one command:

iptables -I FORWARD -i wgs1 -o br0 ! -d 192.168.1.101 -j REJECT

-I = Insert on top
-i = input iface (wgs1 - wg server)
-o = output iface (br0 - lan)
-d = destination ip (all but 192.168.1.101)
! = not (inverted trouth)
REJECT = a reply is sent that this destination is not reachable. Could be DROP instead for silent dropping but it's usually causing issues with long timeouts.

So a typical firewall-start script could be:

#!/bin/sh
iptables -D FORWARD -i wgs1 -o br0 ! -d 192.168.1.101 -j REJECT
iptables -I FORWARD -i wgs1 -o br0 ! -d 192.168.1.101 -j REJECT

-D = delete

rule is deleted before added again to prevent duplication.

 

[0vrthnk]

Zeb, EXACTLY what I'm looking for. Will report back when I've had a chance to test it. Thanks!

 

[ZebMcKayhan]

Zeb, EXACTLY what I'm looking for. Will report back when I've had a chance to test it. Thanks!

Don't forget to set "Enable JFFS custom scripts and configs" to yes in the router gui (Administration -> system) if you have not already done so, otherwise firewall-start will never be executed.

Don't forget to make firewall-start executable with chmod +x /jffs/scripts/firewall-start

Finally, just adding the rules in the file will not add them to the firewall until the firewall restarts so you either need to reboot, restart the firewall manually or execute the file or commands manually. The delete rule may generate an error the first time as the rule does not exist to delete, but no worries, the next command will be executed anyway to insert the rule. This was alittle quick and dirty as the delete command should be piped so the error message does not show, but I'm lazy. Add a 2>/dev/null at the end of the delete command to skip seing the error message.

You can list your rules by

iptables -nvL FORWARD

Your added rule be right on top if all is well.

 

[0vrthnk]

You're a gentleman & a scholar . It just works. Man, sure hope someone else in my situation stumbles on this thread.

I decided to play around with the possibility of adding more inside hosts (for future expansion) and came up with the following:
(Disclaimer: I've been into iptables for a few hours, have NO clue what I'm doing/whether this is secure/efficient/etc. But it seems to work. I suspect there are more scientific ways to do this )

#!/bin/sh
iptables -D FORWARD -i wgs1 -o br0 -d 0/0 -j REJECT
iptables -D FORWARD -i wgs1 -o br0 -d <first-allowed-ip-addr> -j ACCEPT
iptables -D FORWARD -i wgs1 -o br0 -d <second-allowed-ip-addr> -j ACCEPT
iptables -D FORWARD -i wgs1 -o br0 -d <third-allowed-ip-addr> -j ACCEPT
iptables -I FORWARD -i wgs1 -o br0 -d 0/0 -j REJECT
iptables -I FORWARD -i wgs1 -o br0 -d <first-allowed-ip-addr> -j ACCEPT
iptables -I FORWARD -i wgs1 -o br0 -d <second-allowed-ip-addr> -j ACCEPT
iptables -I FORWARD -i wgs1 -o br0 -d <third-allowed-ip-addr> -j ACCEPT
etc.
etc.

For other noobs such as myself: iptables rules are evaluated IN ORDER. Because the -I parameter forces that line to the top of the iptables chain, and because the lines in this script are executed in order, you want make sure "most restrictive" rules are added AFTER your permissive rules, if that makes sense. Just think "script line order is reverse of the execution order". NOTE: ONLY applies when using -I on every line!

That said:
1st 4 rules: Delete any other possible instances of the same rule, per Zeb's advice further up the thread.
5th rule: Sh!tcans all traffic(any destination ip) from the wireguard iface (I think).
Subsequent rules: Will be inserted above the REJECT everything rule, allowing traffic to slip through to that allowed ip.

NOTE: I tried to do this using IPSET, but no joy. Got errors related to "set" not being a valid command, or similar.

 

[ZebMcKayhan]

Great work!

iptables -I FORWARD -i wgs1 -o br0 -d 0/0 -j REJECT

The -d 0/0 could be completally omitted from the command and it do the same in this case.

NOTE: I tried to do this using IPSET, but no joy. Got errors related to "set" not being a valid command, or sisimilar.

Shouldnt be any problems with using ipsets for this purpose. Here is something to get you started: https://github.com/ZebMcKayhan/WireguardManager?tab=readme-ov-file#create-and-setup-ipsets

 

[ZebMcKayhan]

5th rule: Sh!tcans all traffic(any destination ip) from the wireguard iface (I think).

Not all traffic. Forwarding are still allowed to other interfaces, like internet data to wan and dns requests to router and potential guest network are still allowed. It just blocks all traffic from wgs1 to lan (br0).
If you would like to completally block forwarding to any interface you should skip -o br0 from it, but you will still be able to reach router via wgs1 ip (for those services listening to this ip) as that is not FORWARDed but should go into INPUT chain instead.

 

[0vrthnk]

Great work!


The -d 0/0 could be completally omitted from the command and it do the same in this case.


Shouldnt be any problems with using ipsets for this purpose. Here is something to get you started: https://github.com/ZebMcKayhan/WireguardManager?tab=readme-ov-file#create-and-setup-ipsets

Thanks, man! I'll check it out.
One thing I forgot to mention: It seems that all of the approaches above leave the router ip open on the WAN side of the wireguard VPN. Is that unavoidable since it's the wireguard "server"? Obviously, I have WAN access to the webgui turned off, but I'm getting to the webgui router login page from my wireguard connected phone. Not good. Any fix you can think of???

 

[ZebMcKayhan]

One thing I forgot to mention: It seems that all of the approaches above leave the router ip open on the WAN side of the wireguard VPN. Is that unavoidable since it's the wireguard "server"?

Yes, we have only blocked br0 access.

Regarding router itself its not in that firewall chain, since this is not forwarded we need rules in the input chain to control access.

To block access to the gui:

iptables -I INPUT -i wgs1 -d 192.168.50.1 -j REJECT

If you want to completally block router access remove -d <router ip> part but dns won't work anymore, if you do like that.

 

[0vrthnk]

That did the trick! Thanks so much. Now all I have to do is get all the cameras working reliably, lol.
RE: IPSET, yeah, I found the problem

I initially tried:

ipset create wg-hosts hash:net
ipset add wg-hosts 192.168.1.3
ipset add wg-hosts 192.168.1.4

iptables -I FORWARD -i wgs1 -o br0 -d -m set --match-set wg-hosts -j ACCEPT

I got:

bad argument 'set'
(pretty misleading, if you ask me, lol)

I then tried:

iptables -I FORWARD -i wgs1 -o br0 -m set --match-set wg-hosts dst -j ACCEPT

Success!

Nice little router w/ the Merlin enhancements. I can see I'm gonna have to spend more time w/ iptables. Enormously useful stuff.

Have a great weekend.