OpenVPN server with only one NIC possible?
Is is possible/feasible to use pfsense as an OpenVPN server (for road warriors) with one NIC and one IP address?
I have a location that has an ISP managed router. The ISP will do whatever port forwards I want, but will not set up any sort of VPN on the router. We have one public static IP address. They will not do a DMZ or any VLANs. They are the only ISP available.
Currently, the router port forwards PPTP ports to an old Windows server that uses RAS to supply vpn connectivity. This works well, but I want to retire that server, and PPTP isn't exactly known for its security. I also want to avoid requiring a Microsoft CAL for users.
What I'd like to do is set up pfsense with one NIC that would connect to the internal network with an internal IP address. (I could add another internal IP if needed). I'd have the ISP forward the OpenVPN ports to pfsense's IP address. I'd configure OpenVPN in bridged mode.
Unfortunately, internal devices have IP addresses scattered all through their /24, so I can't do something like divide the internal /24 into two /25s and use that for inside and pseudo outside subnets.
Is this possible/feasible?
Is this possible?
Yes, you can run pfSense as an OpenVPN server with just one NIC. You can also run it within a virtual environment.
But I don't recommend run it in bridged mode. It's better to use a separate tunnel subnet and and route the traffic to pfSense or do NAT.
I can't run it in routed mode because pfsense isn't my default router for the network. I suppose I could run a second subnet on the existing network for OpenVPN clients, but the ISP would have to agree to add a route for my 192.168.2.0/24 network.
In other words, lets say that my existing internal network is 192.168.1.0/24. The ISP router is 192.168.1.1 and is the default gateway for all the devices on the network. If I configure OpenVPN to use 192.168.2.0/24 for OpenVPN clients, my internal devices would not be able to communicate with them. When the internal devices send packets to anything in 192.168.2.0/24, they'll send to the default gateway which is the ISP's router. Unless the ISP will add a route to 192.168.2.0/24 , I can't get packets across the two subnets.
I suppose NAT would be an option. I could tell OpenVPN to hand out 192.168.2.101 to 192.168.2.110 to clients, then have pfsense do a one-to-one NAT to 192.168.1.101 to 192.168.1.110, but that's pretty ugly.
I understand why routed mode is superior to bridge mode in general. Is there something about running with one interface that makes bridge mode unsuitable?
A second subnet on one interface isn't really a good idea, unless your ISP router supports VLANs. With a separate VLAN for pfSense it could route VPN traffic to pfSense.
To add routes to each of your hosts you need to access from VPN isn't an option for you?
Bridge mode is a bit tricky to get it up. There are many threads in this forum, but I don't use it myself.
No, that has nothing to do with the one interface.
If you have no other option you can try it.
If you do NAT on pfSense for VPN the source address of packets from a VPN client is translated to the pfSense interface address. Subsequently it's not possible at a LAN host to determine which of client packets are coming from.