Single interface (WAN) OpenVPN Concentrator
-
Has anyone used the Pfsense platform as just a VPN Concentrator? We are looking to set up a Pfsense box. With only a WAN interface at a Co-Location. We have multiple (work from home) users who would VPN into this box. We also would have multiple hosted VPS servers VPNed into this box. User would use this box as a way to reach the servers that VPN in as well as to other users for projects.
This would basically act as our VPN Hub.
Has any one done this? How did you set your up? Is it possible?
There really is no need for a LAN. As all communication would go in and out of this box via the WAN.
-
Maybe there are better or smaller solutions for your intention, however, it will be possible to do it with pfSense also.
I'd such setup as we switched from our former firewall to pfSense to provide sustained VPN service.Just give pfSense a WAN IP in your local network and disable "Block private networks" in the interface settings. Forward the OpenVPN port to pfSense and set up an OpenVPN server.
By default pfSense will do NAT and translate the source client address to WAN address when packets leave pfSense. So you are not able to differ the VPN clients by source IP at accessed hosts.
If you don't want this behaviour you have to switch outbound NAT to manual rule generation and deactivate the appropriate rule. Furthermore you have to set static routes in your network to direct respond packets to VPN subnet back to pfSense. -
No reason why you can't do so.
Just setup multiple OpenVPN server instances and use the firewall rules to restrict access accordingly.
For routing between the different VPN subnets, just include them in the remote networks for the individual instances where necessary.
You'll probably need to swap to a single subnet topology in order to be able to make the proper routes. Client overrides will allow you to identify individual clients since you can assign a fixed tunnel IP to each client.
-
Thanks. I thought it might be possible, didn't see anything that would prevent it. We are placing these in our co-locations as small physical servers. We are basically wanting to build a virtual network (SDN) between our users and our VPS based applications. But wanted our users connections to be secured, as well as inter-server/VPS communications. Leaving the public facing portal available to customers.
We have looked at smaller solutions, but their licensing fees are insane. A fully fledged traditional SDN setup is over $1M USD. Too steep for a 50 employee/10 Server company.
Thanks again.
-
Just remember to generate separate CA's and certs for the different OVPN instances and clients respectively.
Depending on the number of clients per instance, it might be quite tedious to do client overrides but you should at least do it for the servers.
If you use the internal user manager and generate the certs properly (the CN of the cert should match the username), you should be able to check the logs to determine who has logon to the VPN.While it is possible to setup pfSense without a LAN interface from 2.X onwards, I would recommend still having a LAN interface for management. Otherwise, pfSense would allow management access on WAN - not a good thing to have this exposed to the interwebs.
As for the multiple instances, once you have tag each instance with an interface name, you can simply regard them as being additional interfaces on pfSense. That is, they behave just like additional local networks on pfSense except that they don't exist physically.
Since these VPN connections are meant strictly for users to connect to your servers, you should make sure not to redirect the gateway (route all traffic through the VPN). In which case, you do not need to worry about NAT rules since all traffic is 'local' to pfSense.