Prevent LAN access from OpenVPN

[margentieri]

Hello all. So I just recently finished setting up both OpenVPN servers on my ac68u. The first is set up so that connected clients have access to my LAN (Push LAN to clients:Yes), and the second is set up so that connected clients do NOT have access to my LAN (Push LAN to clients: No).

Unfortunately, it appears that clients connected to the second server, where "Push LAN to clients" is set to No, can STILL access my LAN. I have attached a screenshot showing my current settings for this server (and in case it matters, my first server's settings are identical, aside from port number and the above mentioned LAN option).

Am i simply misunderstanding the meaning of this option? Is there something else I have to do to prevent access to my LAN? Or is this a bug?

Thanks!

 

[RMerlin]

All this option does is automatically push a route to VPN clients. It doesn't allow or prevent access in any way.

 

[Ford Prefect]

...and then, AFAIU what happens is that the clients will use their default route to access your LAN...and you are directing their default route (internet traffic) to your VPN-Server, too.

..you should block the TUN-addresses of that VPN-Server from LAN access in the FW.

 

[margentieri]

..you should block the TUN-addresses of that VPN-Server from LAN access in the FW.

And how would I establish what those tun addresses are? Would they just be the VPN IP addresses for that server? I assume I would need to block those addresses in my jffs firewall-start script with iptables?

 

[Ford Prefect]

Yes, according to your screenshot from above, the IP-Addresses of your VPN-Clients for that server are in the range of 10.1.0.0/24...these you should block from accessing your LAN (presumably 192.168.0.0/24 or similar?).

Just make sure the other VPN-Server is handing out IPs from a different range or your "push LAN to clients" will not work anymore

 

[margentieri]

Yes, according to your screenshot from above, the IP-Addresses of your VPN-Clients for that server are in the range of 10.1.0.0/24...these you should block from accessing your LAN (presumably 192.168.0.0/24 or similar?).

Just make sure the other VPN-Server is handing out IPs from a different range or your "push LAN to clients" will not work anymore

Great! I'll have to try that tomorrow when I have a chance. Thanks for all your help!

 

[margentieri]

...the IP-Addresses of your VPN-Clients for that server are in the range of 10.1.0.0/24...these you should block from accessing your LAN

Thanks Ford. It took me a little while to figure out the right iptables rule to use to accomplish what I wanted, but I finally have it working! Just wanted to post the rule I created here for anyone else who might be trying to do the same thing and is having the same problem.

I added the following to my firewall-start script:

iptables -I FORWARD -s 10.1.0.0/24 -d 192.168.1.0/24 -j DROP​

Silly me, it took me so long to get this working right, because despite the fact that the above rule was basically one of the first ones I tried, I was initially attempting to use INPUT rather than FORWARD! Changing the rule to FORWARD accomplished exactly what I was hoping for. So obvious and so simple, yet what a difference it makes.

 

[margentieri]

All this option does is automatically push a route to VPN clients. It doesn't allow or prevent access in any way.

So if I am understanding you correctly Merlin, selecting this option should provide those connected via the VPN with an IP on my router's main subnet and they would appear under the list of connected clients?

I'm honestly not sure what this option really does, because I'm not seeing any difference between VPN connections made when this option is selected and when it is not selected. Selected or not, I can see the active connection under the VPN connection menu, but the connection does not appear under the list of connected clients on the network map, and the connection does not appear to be assigned a LAN IP in the 192.168.1.* range.

The option really appears to do nothing at this point.

 

[Ford Prefect]

Ahh...yes...FORWARD seemed obvious to me as you are using the TUN interface in the VPN-Server.

...glad you sorted it out

 

[Ford Prefect]

I'm honestly not sure what this option really does, because I'm not seeing any difference between VPN connections made when this option is selected and when it is not selected.

This options pushes a route rule/config to the client, pointing your LAN-network through/towards
the VPN interface.

You probably don't see a difference, because you enabled internet access via
the VPN....meaning this pushes a rule to the client, where it's default route points to the VPN interface...and traffic to your LAN will be routed by the default route hence.

 

[margentieri]

Thanks for helping to clear that up for me.

And I know, the use of FORWARD was so obvious, I was kicking myself so hard when I realized the mistake I had made.

 

[margentieri]

So I just noticed that while the rest of my LAN has been blocked with the above iptables rule, I can still access my router settings on this LAN excluded VPN server. This isn't a huge issue as the settings UI is obviously password protected, but I would feel even better if I could block access to that as well. Is this possible? How would I go about blocking access to the settings UI as well?

 

[Ford Prefect]

With openVPN connection up, the router has multiple interfaces.
Once a packet manges to reache the router OS, it will hit the local service.

Meaning, the access via LAN is blocked, but not via the local TUN IP or interface of your openVPN server.

...you probably should block the UI port(s) for all local IPs or for the complete list of local interfaces of your choice.
Maybe the same way the rules are set for the WAN interface, but I haven't tried this myself..

 

[margentieri]

I think I already tried what you are saying, and without any success.

I tried using:

iptables -I FORWARD -s 10.2.0.0/24 -d 192.168.1.1:8443 -j DROP​

but I only received the error message, "host/network 192.168.1.1:8443 not found"

I also tried:

iptables -I FORWARD -p tcp -s 10.2.0.0/24 --dport 8443 -j DROP​

which was accepted, but has not blocked access to the UI.

While it shouldn't matter since I specified that the VPN server is to utilize tcp, I also tried adding the above rule with -p udp instead. Still no luck.

 

[Ford Prefect]

I am no expert using IPTables...but...

- I *think* the FORWARD chain does not apply here...IMHO it should be made an INPUT rule

...I gather the 10.2.0.0./24 net is the one from your other VPN-Server?
Do you want to disable access for just one or for both?
Try a "-i tun+" in the INPUT rule with destination port(s) of the UI, like

-> "iptables -I INPUT -i tun+ --dport 8443 -j DROP"

 

[margentieri]

Sorry, I forgot to mention that I changed the IP addresses of both VPN servers for simplicity. The first server (which I want to have full access to everything) operates on 10.1.0.0, and the second server (the one we have been talking about, that I wish to limit LAN access from) operates on 10.2.0.0.

Wouldn't the above rule block all tun communication with the UI, regardless of source? Also, if -i isn't specified, aren't all interfaces already implied? Meaning my previous rules implied -i tun+ already?

Also, if the rest of my LAN is blocked via FORWARD, why would I need to use INPUT here?

Sorry for all the questions. I am pretty new to iptables and I would just like to understand how this all works more.

Thanks again Ford, you have been really awesome helping me out so far!

 

[Ford Prefect]

OK, let's see if I can work that out...pls bare in mind, that I am not a firewall rules instructor

I think you need an INPUT rule (and as you proved that a FORWARD does have no effect), because:

FORWARD rules apply to communication *between* interfaces or IP-Networks.
This is where routing takes place.
The gateway (router) hosting the interfaces is responsible for routing between networks, but its OS is a destination on these networks too.

Your VPN clients are on their own network and their gateway is associated with the tunX interface in the router.
Your ISP network is associated with the wan interface
Your Home-LAN is associated with the eth0/lan/br0 interface (br0 links the wlan side),

So your router has multiple interfaces at the same time.
These interfaces with different IPs have the same endpoint...the local OS of the router (with their gateway address of that network, associated with the local Interface).
The UI is available on dedicated ports on *all* interfaces (if not specifically set to lan only).
All packets to one of these interfaces do not need routing locally.
So a packet to the router-OS itself, like to the UI, from tun-side to the lan-side do not need to get routed.
The packet is "already there, at its destination" when it reaches the tunX IF and no FORWARD gets applied....unlike for other computers/destinations on your lan.

...rules using interfaces instead of network/IPs:
You can base rules on interfaces (-i parameter) or networks (IP).
As an interface is associated with an IP ( or more IPs if part of multiple networks) using rules for IPs also inherit (partly) a rule for interface(s).
A rule for an interface however will work regardless of the IPs/networks associated with it.
So yes, a rule with "-i tun+" will block *all* traffic from *all* tun IF (the "+" is a wildcard).
Your rule, based on a network for one VPN-Server inherits the *one* tunX interface in its rule,..but not *all* tunX.

 

[MichaelR64]

Thanks Ford. It took me a little while to figure out the right iptables rule to use to accomplish what I wanted, but I finally have it working! Just wanted to post the rule I created here for anyone else who might be trying to do the same thing and is having the same problem.

I added the following to my firewall-start script:

iptables -I FORWARD -s 10.1.0.0/24 -d 192.168.1.0/24 -j DROP​

Silly me, it took me so long to get this working right, because despite the fact that the above rule was basically one of the first ones I tried, I was initially attempting to use INPUT rather than FORWARD! Changing the rule to FORWARD accomplished exactly what I was hoping for. So obvious and so simple, yet what a difference it makes.

Euuhhm,
So i have the same wish here, 2 OpenVPN servers wanting to use the second for non-lan access on my AC87.
Figured out that they have to have a different port and vpn subnet for them to work.
Stumbled upon the bit above.
I am stumped however trying to figure out where to put this. The firewall section doesn't have a option to do this ...
Can anyone shed some light as to where i need to put this ?

Tia

 

[MichaelR64]

Nobody ?

 

[Martineau]

Nobody ?

RTFM

https://github.com/RMerl/asuswrt-merlin/wiki

See User Scripts under Usage