Client cert-based access-control/firewalling?
-
Hello,
We're running pfSense 2.26 on an OPNSense rack appliance. We use this device to provide remote access over OpenVPN to our lan, as well as to route traffic between multiple lan segments and OpenVPN site-to-site gateways. I'm looking for a way to restrict individual users' access to other network segments based on their identity, either username or, preferably their client certificates.
My first thought was to give static IP addresses using CSC's, then create firewall rules based on these IPs. This turns out not only to be unwieldy to maintain, but also relatively useless in terms of security - any user with admin rights on his own box can simply change his IP address and the server will happily accept packets from the new address.Is there a way to enforce network access rules based on OpenVPN certificates? Or is there a better way of accomplishing this?
Thanks,
Frank
-
According to
https://forums.openvpn.net/viewtopic.php?t=22598
the client will be dropped if they change the IP address assigned bythe CSO. -
Use a separate VPN with a different CA/Cert structure for each class of users. They can't break out of the separate tunnel networks that way.
Another more confusing and difficult option would be to setup multiple copies of the same VPN on different ports with the same CA structure and different tunnel networks, but add overrides and/or a CRL that restricts who can connect to what.
Using separate VPNs is cleaner and less confusing to maintain, however.
-
According to
https://forums.openvpn.net/viewtopic.php?t=22598
the client will be dropped if they change the IP address assigned bythe CSO.Hmm, my setup seems not to work that way. I tried setting "ifconfig-push 192.168.100.100 255.255.255.0" in a cso for my common-name, and did indeed receive that address. However, after manually altering my local tap0 address to 192.168.100.101, I was still able to use the connection. Perhaps I'm missing some configuration parameter?
-
Use a separate VPN with a different CA/Cert structure for each class of users. They can't break out of the separate tunnel networks that way.
Another more confusing and difficult option would be to setup multiple copies of the same VPN on different ports with the same CA structure and different tunnel networks, but add overrides and/or a CRL that restricts who can connect to what.
Using separate VPNs is cleaner and less confusing to maintain, however.
Looks like I may have to go the multiple server route. I had rather hoped I could avoid the hassle of distributing new certs/configs to the users - if experience is any guide, I'll be spending a lot of time on the phone hand-holding :-\
-
Hmm, my setup seems not to work that way. I tried setting "ifconfig-push 192.168.100.100 255.255.255.0" in a cso for my common-name, and did indeed receive that address. However, after manually altering my local tap0 address to 192.168.100.101, I was still able to use the connection. Perhaps I'm missing some configuration parameter?
Tested it today: I don't get the log similar to
MULTI: Bad source address from client [192.168.151.248], packet dropped
but i can confirm : if the client changes to another ip the packets don't enter the VPN. -
Are you using tun interfaces? I suspect that my setup doesn't behave that way because I'm using Layer 2 (tap) devices.
-
If you are using tap then you absolutely need separate VPNs. Even if you could filter them at layer 3 they could still send out L2 frames you may not want them to do.
Do you really need tap?
-
Not anymore. My predecessor set up the vpn with tap in order to use our central DHCP server, but now we push addresses from the the OpenVPN server instead.
I guess I'll have to bite the bullet and restructure the whole setup with multiple networks. I guess it won't need to be that disruptive - I can migrate users to the networks incrementally, leaving the old setup running in parallel until everybody gets on the new setup.Thanks.