Contractor VPN
-
Hi,
I would like to offer a contractor VPN access to a single server. Is the following a valid method?
- create a new server certificate for a second OpenVPN server (same CA could be used)
- create the second OpenVPN server on port 1195, with a different "IPv4 Tunnel Network", ie - 192.168.X.0/24 (where X = isolated contractor subnet)
- set "IPv4 Local Network/s" to the specific server, ie - 192.168.0.X/32 (single host)
- multiple contractors should not be able to contact each other as "Inter-client communication" is not ticked (default)
Creating the second OpenVPN server adds the standard rule to the "OpenVPN" portion of the firewall (IPv4, *, *, *, *, *, none). However, it seems that OpenVPN takes care of what can actually be accessed via "IPv4 Local Network/s" (ie 192.168.0.X/32). No other rules on the firewall are actually required?
"SSL/TLS + User Auth" would be used. The ".key" file would be deployed on contractor machine (Client Export - Standard Configurations Archive), which contains the TLS Authentication static key for the specific OpenVPN server. The contractor should never have access to the primary ".key" file of the primary OpenVPN server (1194), and should therefore never be able to authenticate against it.
Is the above good practice?
Thanks
ps. When I tested creating a second OpenVPN server via the Wizard, I chose the existing CA and new server certificate, but the wizard always created a new CA? (with identical name to the existing CA I chose). Has anyone come across this?
-
- create a new server certificate for a second OpenVPN server (same CA could be used)
Create a new CA for this server. Otherwise clients will be able to connect also to first OpenVPN server. The server just checks if the client cert is from the same CA as the server cert.
Creating the second OpenVPN server adds the standard rule to the "OpenVPN" portion of the firewall (IPv4, *, *, *, *, *, none). However, it seems that OpenVPN takes care of what can actually be accessed via "IPv4 Local Network/s" (ie 192.168.0.X/32). No other rules on the firewall are actually required?
The "IPv4 Local Network/s" setting is just for pushing routes to the clients. This doesn't prevent access to other hosts. A client may set the route by himself and get access to any other host.
So control access by firewall rules!
In some cases it's also necessary to assign a particular interface to each server. So each OpenVPN server get it's own firewall rule tab. -
In some cases it's also necessary to assign a particular interface to each server. So each OpenVPN server get it's own firewall rule tab.
Thanks.
Can you clarify on the additional tab? (they would both be against the same WAN int). I do recall elsewhere someone had mentioned they had to split the subnet in half so they could manage firewalling for both servers within the gui.
-
Assigning separate interfaces to each server is needed for routing issues. E.g. if you want to route traffic to a VPN client you have to route it to the virtual VPN gateway (the servers address) of the particular interface.
The default setting is that all OpenVPN interfaces are handled as an interface group.If you only have incoming connections over the OpenVPN tunnels, there is no need for assigning interfaces to each server. Firewalling can also be done at the one OpenVPN interface.
-
Thanks.
I find it interesting that pfsense serves up the login/management interface via the OpenVPN default gateway (ie https://192.168.2.1/). Contractors should not have any business here.
Although any login is not permitted ("An HTTP_REFERER was detected…").. it is interesting that it responds at all.
Perhaps a specific block to 22/80/443 for clients to 192.168.2.1 ?
-
As mentioned above, the contractors should only have access to a single host. So you have to put a firewall rule at OpenVPN interface to permit only this one destination from the contractors VPN tunnel.
If this rule is right in place there will be no access possible to the pfSense GUI.