LAN traffic bound for VPN clients not routed correctly in filtering bridge
-
Why can't OpenVPN NAT the clients' private addresses to the public one the VPN server is running on? It seems like that is not being done, and I'm seeing private IP addresses on the LAN.
That is, OpenVPN would re-write the source address of packets from 10.0.0.* to 128.* (public), and the reverse in the opposite direction.
Craig
-
Have you setup advanced outbound nat (manual mode) to do that? I would think that NAT is disabled in a bridge.
-
So… I've tried a bunch of VPN and NAT rule combinations but I haven't gotten anything working.
I have a 3rd interface connected to the LAN that I could run OpenVPN on. I was thinking this would stop any confusion with the bridge. I've tried, but no luck with the NAT. Should I use it or have OpenVPN run on the WAN port?
What rules govern how packets are routed from the virtual VPN adapter to the real adapters?
What interface would the NAT rule be set on? OPT1? OpenVPN? LAN? For traditional NAT you set the rule on the WAN for private IPs on the LAN. I was thinking in my case I would use OPT1 because that's the outgoing port for the VPN traffic.
I'm setting the source range on the NAT rule to be the OpenVPN client range, 10.0.1.0/24.
And the translation should be to the interface address?
Thank you everyone!
-
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.