OpenVPN client IPs see each other
-
Forgive me for maybe asking an FAQ, I am in a hurry right now.
At a customer I run an OpenVPN server instance with maybe 30-40 parallel clients.
The server is configured to allow 64, that's enough.
Today the admin of my customer had to debug some printer issue on a VPN client, and ran an IP scan on that PC.
And the scanner found and listed all the other OpenVPN clients in the Tunnel Network ... That's maybe expected, but unwanted ...
The checkbox "Inter-client communication" is disabled.
How to quickly and safely change this?Add a firewall rule to the OpenVPN interface rejecting ICMP, for example?
This is production, I better ask before I ruin more.
Thanks for any pointers! -
@sgw said in OpenVPN client IPs see each other:
That's maybe expected, but unwanted ...
This is not expected, is it a tun or tap OpenVPN and how look the firewall rules on OpenVPN?
-
if the VPN client is a Microsoft device, this choice does what you want it to do
(sorry, for some reason my version wants to talk french to me)
Pick the 'public network' (Recommanded !).
From then on, the PC will use it's own IP, and the gateway IP (the open VN server) and allows nothing 'to' and 'from' elsewhere.
You might be able to ping something else, I'm not sure. Afaik, ping is harmless.Btw, funny actually, on any other wired or not network segment, you would be able to harass any other device in that 'LAN' segment and pfSense won't be able to stop that.
VPN is different, as I resume it's an end to end point connection, so maybe you can enforce what you want with a pfSense OpenVPN server firewall rule.
Instead of the open bar style of VPN firewalling - the one I use :
use / try :
-
@Gertjan thank you.
I will only have time and brains to look into that tomorrow.
I have to map what "PORTAL subnets" and "VPN subnets" mean in my context.Ah, btw: most of the clients are pfSenses also, as VPN-gateways on the sites of the customers of my customer ;-)
In my case the Tunnel Network is 172.31.0.0/23 and for example a client 172.31.0.16 should be able to access one particular VM in a local net like 172.31.110.60 only.
And pinging or accessing something like 172.31.0.17 (= other openvpn client) or 172.31.110.61 (=other server VM) should be disabled.
When I write this it sounds to me as if I have to write one rule per ovpn-client, to only allow access (RDP, to be exactly, and maybe ICMP) to his related server-VM-IP.
This relates to one of my earlier postings: I had assumed that I could limit access by setting "IPv4 Local Network/s" in the ovpn-CSC/CSO. But as I learned this only relates to the routing table entry created. It doesn't block anything ...
thanks so far, I have to get afk now. busy day.
-
I would solve this on the OpenVPN firewall rules, not with the CSO "local network" field. That field only decides what routes get pushed/installed; it is not an ACL.
For production I would make it explicit: pass rules first for each client tunnel IP/alias to only its allowed VM and port(s), for example 172.31.0.16 -> 172.31.110.60 TCP/3389 plus ICMP if you need it. Then add a reject/block rule below for source 172.31.0.0/23 to destination 172.31.0.0/23 and to the local server subnets you do not want reachable. The rule order matters, so test with one client before copying it to the rest.
-
@sgw said in OpenVPN client IPs see each other:
I have to map what "PORTAL subnets" and "VPN subnets" mean in my context.
Me being not careful. The "PORTAL Subnets" alias doesn't belong here. It should be "VPNS Subnets" (my VPN Server interface).
It should be :
edit :
When firewall rules are created for every (VPN) user, you beter make sure that every known VPN user (device) gets it's own 'static' (== the same tunnel IP) every time it connects.
I've played with this a bit a while ago, and there are forum posts about it in this forum (OpenVPN).
Search with "Client Specific Overrides".
An example :
My iPad, - and I selected my OpenVPN server from the list.
The common name of the certificate used is "iPad-Gertjan". I used only certificates = "Remote Access (SSL/TLS)".
Entered the Tunnel network
and at the bottom :
where I assign 192.168.3.10 to my iPad every time it connects.
-
@MalagaFirewall8 said in OpenVPN client IPs see each other:
I would solve this on the OpenVPN firewall rules, not with the CSO "local network" field. That field only decides what routes get pushed/installed; it is not an ACL.
It would be a great feature if an ACL would be created out of these CSO-configs.
Very helpful: I'd have every client plus its target-VM-IP in one place.For production I would make it explicit: pass rules first for each client tunnel IP/alias to only its allowed VM and port(s), for example 172.31.0.16 -> 172.31.110.60 TCP/3389 plus ICMP if you need it. Then add a reject/block rule below for source 172.31.0.0/23 to destination 172.31.0.0/23 and to the local server subnets you do not want reachable. The rule order matters, so test with one client before copying it to the rest.
I will test this out with a test user asap. Thanks.
I have to come up with a rather compact ruleset, as I have to create rules for all the already existing clients. -
My tests look promising:
I set up a tunnel-user with static Tunnel-IP 172.31.0.79/23, and created an alias for that IP (maybe overkill, the alias can only be used in the FW-rules, not in the CSC, afaik. That's more for readability maybe, unsure so far).
I then created 3 test-rules on the OpenVPN interface:
pass IPv4 TCP/UDP from that tunnelip to the server-IP, Port 3389 (RDP)
pass IPv4 ICMP from that tunnelip to the server-IP
block IPv4 ANY from that tunnelip to the Tunnel Network of that OpenVPN server(like @MalagaFirewall8 suggested)
Tests with nmap work as expected.
If I modify the last rule to "from Tunnel Network to Tunnel Network" my main issue would already be resolved (all openvpn client Tunnel IPs don't see each other anymore).
btw: what about the connection to the IP of the pfSense in that network? doesn't ping, OK, but the tunnel works, ok so far.
My secondary goal to only allow Client X to connect to Server Y needs at least one allow-rule for RDP, better a second for ICMP to help the support guys testing connectivity now and then.
All that sounds like scripting in in Ansible ( https://github.com/pfsensible/core/wiki/pfsense_rule etc) but I have to check which approach is faster. Will discuss that with their tech guys etc
But the direction seems clear. Thanks all!
-
@sgw if you have only this two pass rules another block rules is not needed, because blocking is the default...
-
@slu said in OpenVPN client IPs see each other:
@sgw if you have only this two pass rules another block rules is not needed, because blocking is the default...
yes, sure. But currently there is an allow-all rule at the end ... not good.
But I won't touch too much right now with active users during the day. -
That sounds like the right direction. I’d keep the final broad block/reject while you still have the old allow-all rule around, mostly because it makes mistakes visible in the rule counters/logs. Once the per-client pass rules are complete and the allow-all is gone, the implicit deny can do the same job. For rollout, aliases per static tunnel IP are not wasted if they make the rule set readable for the next person.
-
@MalagaFirewall8 thanks. I will take these into the discussions with my customer next week.
-
I plan to generate aliases and fw-rules via pfsensible ... at first I asked the customer to set fix tunnel IPs via CSOs and then give me a list of "tunnel-IP; target VM IP". From that I will try to write some playbook.
There are also VMs with more than only RDP: postgres-DBs etc ... so that adds up to more complexity.
AND customers with multiple tunnels.The fun has no end ;-)
