How to prevent Guest Network users to communicate with VPN Clients?

[rkk2025]

Hi,
I have connected two LANs via OpenVPN. My RT-AC68U is acting as OpenVPN Server (TUN), and the other Router connects to it allowing me to communicate with any device from the other LAN.

On my RT-AC68U I also have a Guest network, which has no access to my intranet. But to my surprise the Guest network seems to be able to communicate with any Client that is connected to my OpenVPN Server on the Router. The routes are also working, allowing anybody from my Guest Network to access the whole LAN on the other end. A simple network scan from the Guest Network reveals all the IPs from the other LAN, which is a huge problem.

Is there any way to block the Guest Network from communicating with the OpenVPN Clients? Basically allowing the connected clients to communicate only with my personal intranet.

Is the VLAN1 interface on the Router the Guest Network? Maybe it would be possible to somehow block that interface from being able to communicate with the tunX interface by using iptables or firewall rules? (I'm not sure how that is done though). Any ideas?

P.D: I'm on Asuswrt-Merlin 384.4_2

 

[Sephula]

Now, that's intriguing.

 

[ColinTaylor]

Try this as a proof of concept (I'm just guessing here):

ebtables -t broute -I BROUTING -i wl0.1 --ip-dst 10.8.0.0/24 --ip-proto tcp -j DROP

This assumes that your guest network is the first 2.4GHz one (wl0.1) and your VPN subnet is 10.8.0.0/24.

If it works then there's probably a more elegant and robust way of automating it.

 

[Jack Yaz]

Try this as a proof of concept (I'm just guessing here):

ebtables -t broute -I BROUTING -i wl0.1 --ip-dst 10.8.0.0/24 --ip-proto tcp -j DROP

This assumes that your guest network is the first 2.4GHz one (wl0.1) and your VPN subnet is 10.8.0.0/24.

If it works then there's probably a more elegant and robust way of automating it.

Interesting - I'll add this to YazFi, though I drop everything in ebtables and utilise iptables, so I'll adapt your command to pick up the vpnserver1 + 2 subnets.

 

[ColinTaylor]

Interesting - I'll add this to YazFi, though I drop everything in ebtables and utilise iptables, so I'll adapt your command to pick up the vpnserver1 + 2 subnets.

Please don't assume this works, it's just a guess.

 

[RMerlin]

You could probably also use a similar trick to block access to the tun+ interfaces used by OpenVPN - I never tried that either.

 

[rkk2025]

Try this as a proof of concept (I'm just guessing here):

ebtables -t broute -I BROUTING -i wl0.1 --ip-dst 10.8.0.0/24 --ip-proto tcp -j DROP

This assumes that your guest network is the first 2.4GHz one (wl0.1) and your VPN subnet is 10.8.0.0/24.

If it works then there's probably a more elegant and robust way of automating it.

The command seems to be returning an error saying:
For IP filtering the protocol must be specified as IPv4.

Any idea why it's saying that?

 

[Jack Yaz]

The command seems to be returning an error saying:
For IP filtering the protocol must be specified as IPv4.

Any idea why it's saying that?

Try

ebtables -t broute -I BROUTING -i wl0.1 -p IPv4 --ip-dst 10.8.0.0/24 --ip-proto tcp -j DROP

 

[rkk2025]

Yes! It works!! Although it didn't work with the VPN tunnel IP, it did though work when I used the IP of the remote LAN. Now it successfully blocks any access to the remote LAN from my guest network. Thanks for helping out!!!

 

[ColinTaylor]

Glad to hear you got it working, and good catch on the destination address. Sorry for missing the IPv4 parameter (cut and paste issue ) and thanks to @Jack Yaz for helping.

I've tried to think of a way to automate this but haven't come up with anything nice at the moment. You could probably hard-code the command into an openvpn-event user script, but it's not very elegant. The problem that I see is trying to determine the remote client's IP address and subnet. I'll keep thinking.

 

[Jack Yaz]

Yes! It works!! Although it didn't work with the VPN tunnel IP, it did though work when I used the IP of the remote LAN. Now it successfully blocks any access to the remote LAN from my guest network. Thanks for helping out!!!

Out of interest what subnet are you using for VPN Server 1?

 

[rkk2025]

Out of interest what subnet are you using for VPN Server 1?

I left it all on defaults. On VPN Server 1 it is 10.8.0.0 and on VPN Server 2 (Where I have the LANs interconnected) it is 10.16.0.0

P.D: In case of doubt, I did change the subnet IP from the command to the 10.16.0.0 one.

 

[Jack Yaz]

I left it all on defaults. On VPN Server 1 it is 10.8.0.0 and on VPN Server 2 (Where I have the LANs interconnected) it is 10.16.0.0

P.D: In case of doubt, I did change the subnet IP from the command to the 10.16.0.0 one.

Can probably automate it then as @ColinTaylor says, using something like the below, and including in openvpn-event or firewall-start

ebtables -t broute -D BROUTING -i wl0.1 -p IPv4 --ip-dst $(nvram get vpn_server2_sn)/24 --ip-proto tcp -j DROP
ebtables -t broute -I BROUTING -i wl0.1 -p IPv4 --ip-dst $(nvram get vpn_server2_sn)/24 --ip-proto tcp -j DROP

 

[ColinTaylor]

Can probably automate it then as @ColinTaylor says, using something like the below, and including in openvpn-event or firewall-start

The problem is that the destination address isn't the VPN server subnet, it's the LAN subnet that the client device is using (that's the same mistake I made).

@rkk2025 What IP address did you have to use for the destination? Presumably something like 192.168.2.x?

 

[Martineau]

The problem is that the destination address isn't the VPN server subnet, it's the LAN subnet that the client device is using (that's the same mistake I made).

The OpenVPN Server directive

--client-connect   script_name

can be used to examine the exposed OpenVPN environment variable $trusted_ip during the initial client connection and may assist in creating the appropriate ebtables blocking rule?

Alternatively, if the OP has hardcoded OpenVPN Server related route statements for the remote LAN subnet, then the 'openvpnserver2.postconf' may be used to create the ebtables rule?

 

[ColinTaylor]

Thanks for the tips @Martineau

 

[Jack Yaz]

The problem is that the destination address isn't the VPN server subnet, it's the LAN subnet that the client device is using (that's the same mistake I made).

@rkk2025 What IP address did you have to use for the destination? Presumably something like 192.168.2.x?

I was going based on this!

P.D: In case of doubt, I did change the subnet IP from the command to the 10.16.0.0 one.

 

[ColinTaylor]

Well it looks like the $trusted_ip environment variable won't help us as it only gives us the WAN IP address of the client, whereas we want the internal network details (because it's a LAN to LAN connection). So Martineau's other suggestion is probably the way to go. But the precise solution would depend on how the OP is setting up the routing to the other network.

 

[rkk2025]

The problem is that the destination address isn't the VPN server subnet, it's the LAN subnet that the client device is using (that's the same mistake I made).

@rkk2025 What IP address did you have to use for the destination? Presumably something like 192.168.2.x?

In my case my own router (RT-AC68U -> Server) is using 192-168-2-x, and the remote network is using 192-168-178-x (For whatever reason the German Fritz.Boxes use 178 as default subnet).

P.D: For whatever reason Cloudflare seems to be blocking me whenever I put the IPs with the dots here and try to post it. I replaced the dots with "-" to avoid this.

 

[ColinTaylor]

Thanks for the clarification.