LAN traffic bound for VPN clients not routed correctly in filtering bridge
I have a filtering bridge (no NATing, WAN and LAN bridged, public IPs on LAN). OpenVPN clients have a private subnet.
LAN traffic bound for the OpenVPN private subnet hits the pfSense box and then goes out the WAN interface instead of being routed to OpenVPN.
VPN client traffic bound for the LAN is routed correctly to the LAN interface.
Pings from VPN clients go through, but the reply goes out the WAN interface.
Can anyone point me in the right direction? Why is pfSense not routing the traffic correctly? Thank you!
The OpenVPN server config:
keepalive 10 60
server 10.0.1.0 255.255.255.0
auth-user-pass-verify /var/etc/openvpn/server1.php via-env
management /var/etc/openvpn/server1.sock unix
push "route a.b.c.0 255.255.255.0"
tls-auth /var/etc/openvpn/server1.tls-auth 0
push "route remote_host 255.255.255.255 net_gateway"
I am going to take a guess that VPN would not work in a bridge for any product. Reason being that the servers them selves are not using pfSense as a router/gateway. You would have to put a route on the servers themselves to point a.b.c.0/24 to the pfSense machine so that a point to point VPN can work. A road warrior setup might never work as the private ips might change, unless you point all private domain to the pfSense IP on every server in the LAN. Still, that is not saying that it will work.
Can't I just add a route to direct the VPN traffic to the OpenVPN gateway? What would the gateway be?
That is what I am saying to do, but on the each server. The gateway would be the pfSense management IP.
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.
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 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:
to <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.