LAN traffic bound for VPN clients not routed correctly in filtering bridge
-
Is this a site-to-site VPN or one for road warriors?
-
Road warrior.
-
Help? :(
-
Road Warrior is going to be more difficult as the remote network is going to change between connections. You could route all private nets to the pfSense gateway. Like:
172.16.0.0/16
10.0.0.0/8
192.168.0.0/16to <lanip>of the pfsense firewall. If you have control of the gateway that your servers use, you can add the routes there as well.</lanip>
-
Pretend I had another machine on the LAN that ran OpenVPN. I believe then I could make it work without much trouble. How can I run OpenVPN on the pfSense box, using an OPT port connected to the LAN switch, as if it was a different machine?
-
I am not sure an OpenVPN server behind the firewall would work. You would still have a broken route. I think you can use OpenVPN and give the remote connector a LIVE ip address at your DataCenter, but you would have to have a live IP for each connection. Past that, just think how packets would route once they arrive at the server.
-
This doesn't seem that hard to me, so I must be missing something. Let's say I had a server on the LAN to serve this purpose.
A client connects via the server's public IP. It gets a virtual IP (from OpenVPN dhcpd) on it's virtual tun interface and creates a route for the virtual network through the tun adapter.
The server NATs the client's virtual IP address to it's own public one, and passes the packet to its destination. When packets comes back to the OpenVPN server it NATs it back to the virtual IP address and sends it across the tun adapter. The client routes traffic to the tun adapter according to the routes pushed from OpenVPN. -
There is documentation covering that. look in docs.pfsense.org or buy the official book. I have not setup OpenVPN in that way. Mainly because I don't run a bridge. What could be better (if it even exists) is a knock routine that opens the firewall to a particular source if the correct packets are sent to the correct series of ports.
-
In this kind of situation, you might be better off running OpenVPN in tap mode and handing out some IPs in your public bridged segment to your connecting OpenVPN clients. 2.0 was broken for such a tap bridge, but I have recently fixed it up and made a package to apply the fixes to 2.0.
-
I sidestepped this issue by changing to 1:1 NAT with a separate subnet for VPN clients.
