A stupid question how to block access to my LAN when using OpenVPN

[Scaner]

Hello people

I use OpenVPN client (Merlin-LTS firmware, Asus RT-N66U) but I don`t want somebody connect to my private network (LAN) from Server side, how can I block it (maybe add something in OpenVPN client-config or use iptables for tun12 interface?

 

[ColinTaylor]

IIRC If your VPN client is using a TUN interface type the connection creates a NAT tunnel by default. Therefore unsolicited incoming connections can't reach the LAN. If you have disabled the NAT tunnel or are using a TAP interface type that's a different matter.

 

[Scaner]

IIRC If your VPN client is using a TUN interface type the connection creates a NAT tunnel by default. Therefore unsolicited incoming connections can't reach the LAN. If you have disabled the NAT tunnel are using a TAP interface type that's a different matter.

Many thanks, i use TUN interface and NAT creates by default enabled so nothing to do as i understood

 

[martinr]

And there’s no such thing as a stupid question, only a stupid answer, something there’s no danger of ever getting from Colin.

 

[eibgrad]

IIRC If your VPN client is using a TUN interface type the connection creates a NAT tunnel by default. Therefore unsolicited incoming connections can't reach the LAN. If you have disabled the NAT tunnel or are using a TAP interface type that's a different matter.

NAT does NOT prevent unsolicited incoming traffic over the OpenVPN client. That's the reason the Inbound Firewall setting was added, which is set to Block by default.

 

[ColinTaylor]

NAT does NOT prevent unsolicited incoming traffic over the OpenVPN client. That's the reason the Inbound Firewall setting was added, which is set to Block by default.

My recollection was that the VPN client implementation in John's firmware (which the OP is using) was slightly different than Merlin's. That's why I prefaced my reply with "IIRC".

I've dug out my old router with John's firmware and tried to test this. I can see that there is indeed no firewall rule that blocks traffic from the tun interface. But try as I might I am unable to create a scenario where the server side can initiate a connection to something on the client's LAN. There just isn't the routing setup on the server side to do this. Even when I create static routes I can't make it work. That's not to say it isn't possible, just that I've not managed to do it.

I guess it might depend on what kind of client-server setup the OP is talking about. Is he connecting to a commercial VPN provider (e.g. NordVPN) or is this a LAN to LAN setup.

 

[eibgrad]

My recollection was that the VPN client implementation in John's firmware (which the OP is using) was slightly different than Merlin's. That's why I prefaced my reply with "IIRC".

I've dug out my old router with John's firmware and tried to test this. I can see that there is indeed no firewall rule that blocks traffic from the tun interface. But try as I might I am unable to create a scenario where the server side can initiate a connection to something on the client's LAN. There just isn't the routing setup on the server side to do this. Even when I create static routes I can't make it work. That's not to say it isn't possible, just that I've not managed to do it.

I guess it might depend on what kind of client-server setup the OP is talking about. Is he connecting to a commercial VPN provider (e.g. NordVPN) or is this a LAN to LAN setup.

I agree the OP is vague here, which makes it more difficult to provide specific examples. So we have to assume the worst case scenario.

At the very least, the OpenVPN client itself is reachable. And that may be sufficient for a hacker if it can be breached (e.g., some users *assume* unsolicited access to the OpenVPN client isn't possible, and so are willing to use weak passwords).

Beyond the router itself, without explicit inbound protection, any rogue elements on the server side will likely be able to deduce (or brute force) the local IP network on which the OpenVPN client is running and reach those devices by NAT'ing their side of the tunnel. Of course, like any OpenVPN site-to-site config, they also have to configure the server appropriately, which means adding the OpenVPN client's IP network as a route in the server's routing table, creating an iroute directive containing the same routing information in a file by the CN (Common Name) of the client's cert in the CCD directory, etc. IOW, site-to-site from the server's perspective requires some additional changes (that's why ASUS and other tomato variants have the Manage Client-Specific Options section on the server; it does all this for you, under the covers). You can't just add a static route and expect it to work.

In short, once the server side knows the correct routing information, is configured correctly, and there's no firewall rules to prevent unsolicited inbound traffic to the OpenVPN client, there's nothing to prevent access to the rest of the WLAN/LAN other than personal firewalls.

Let's look at this way. It's at least as vulnerable as if your WAN wasn't explicitly blocking unsolicited incoming connections either. But because it is, that's why you need port forwarding to get beyond it. But no one would claim allowing unsolicited incoming connections was therefore OK and the WAN's inbound firewall is unnecessary because of NAT.

IMO, you're asking for problems if you don't use the Inbound Firewall option (or employ the equivalent firewall rules).

 

[visortgw]

You can also configure LAN access using rules in VPN Director.