Not allow clients to LAN?
-
You can firewall them off as Derelict suggested or you can simply just not push that particular route to your clients.
-
If I want traffic blocked, I like the positive nature of a block rule.
I have never tried it. Can a client just add a route that isn't pushed?
-
I have never tried it. Can a client just add a route that isn't pushed?
Yes. Never rely on routing or lack thereof for access control.
-
Not giving a route to the remote would be an attempt at obscurity, which we all know is not security ;)
-
I agree with the arguments that have been brought forth, but I also think that presenting a route that you just intend to deny access to is also a security hole in and of itself isn't it?
I also wasn't trying to pass off the exclusion of a route as security, I am merely presenting options. Can a savvy client manually add routes on their end in an attempt to access my LAN? Sure, but first they have to know what subnets I'm using. If someone wants to take the time to manually route all reserved addresses over the tunnel and scan 17+ million IP's (IPv4) in the hopes of finding something that responds, so be it, but that's where firewall rules come in. Not to mention, if someone were that security conscious they would have IPS/IDS running to detect that kind of activity anyway.
Firewall rules are definitely the way to go but I just wanted to point out that if you don't want people accessing a resource… you can start by not pushing a route to that resource to begin with, which should eliminate an obvious target for the average or above average user.
-
It is perfectly acceptable, and might even be preferred, to just push a supernet to the client endpoints, say 172.23.128.0/20.
That network could cover many sites. Firewall rules could pass traffic to the private assets they need access to then block the whole /20 then pass any for internet. Changes can be made to the rules without touching/bouncing the VPN. Anyone could be granted access to any VPN asset on the entire network with nothing but a rule change and without micro-managing what routes are pushed where.
And, in this case, a default next-hop gateway is being pushed so all the traffic is coming in the VPN no matter what routes you push so you're going to need block rules regardless.
-
I wrote up a reply, but just erased it all because we were just going to keep talking in circles… lol!
We all have different experiences, every network is different and we all have our own opinions. Basically, the OP has the option of how he wants to balance security, complexity, management overhead, and time. Then plan accordingly.
-
Thanks guys for commenting. Sorry that I'm not as experienced as you :P
What I was trying to say is that I want connected client's internet traffic to to go though the tunnel. But I don't want the client to access my LAN network.
Could you explain to me what does the checkbox "force clients traffic to go through the tunnel" do? Because from what you said, I think I understood it wrong.
-
On the OpenVPN tab, above the rule that is already there, place a rule that blocks traffic on IPv4 protocol any source any dest LAN net
And probably dest This firewall (self) too.
I have more than one OpenVPN server. Is there a way that I can block clients to the LAN on one server but not for another?
Example, I have one server that runs on udp and another one on tcp. I want client to be able to access lan on the udp server but not the tcp.
-
So your VPN servers use different tunnel subnets. Enter the tunnel subnet of the server you want to block from LAN as source in the block rule instead of any.
-
The best solution is probably OpenVPN assigned interfaces so you can put rules specific to each VPN endpoint on their own firewall rules tabs. You could just block source any dest LAN net and dest This firewall (self).
Otherwise you probably want to block traffic from both the tunnel endpoint (in case they assign an interface and outbound NAT) so that would have to be static in a CSO, and the remote network(s), in both cases with destination LAN net and probably This firewall (self).
