Bug in NAT for OpenVPN! (was: Routing issue / NAT inside of OpenVPN)
dklev last edited by
I was able to set up a lot locations with OpenVPN. There are a lot of subnets in 192.168.x.x. But to make connections from everybody to everybody possible, I have to push a lot of routes to the clients, and when I want to reach computers behind these clients, I have to add a lot of static routes to the routers at each location.
Imagine this simplified setup:
Now PC 1.17 in Network1 wants to ping PC 2.23 in Network 2.
Symptom: In order to reach Network2 from Network1, I must route 192.168.2.0/24 to pfSense or set Default Gateway accordingly. Additional In Network2 (there is a hardware router for DSL) all computers have Default Gateway to that router 2.1. So I have to create a static route for the way back to Network1 1.x to the pfSense/OpenVPN Client.
Now there comes Network 3. Now I have to change Network 2 again, and add another Static route 192.168.3.x to OpenVPN client.
Problem1: Some hardware routers doesn't have a "static route" setting. Then I have to add these static routes to EVERY CLIENT in the Network
Problem2: I am not allowed to set default Gateway to Openvpn client (because if machine with OpenVPN fails, the users loose VPN and the complete internet connection, which must be avoided)
Problem3: I can not setup one big route, e.g. 192.168.0.0/16, to Openvpn client, as this hides/kills their own local network, too (because their LAN is e.g. 192.168.3.0/24).
So for every new network the amount of setup work is growing, because on Network 78 I have to change 77 networks to add the new routes.
I was using M$ PPTP client before. When connection is there and I ping to that destination, my TCP packet was NATed at the destination client, as if the packet came from the LAN computer that accepted the VPN, so the way back is extremely easy, too. Is it possible to do that, too?
Thanks for your ideas, tipps or some links, how to setup in pfSense.
dklev last edited by
Oh - I was able to set up NAT within OpenVPN server. I added a virtual IP, then I was able to setup NAT/OpenVPN to "outgoing interface" or that virtual IP. I can see in Wireshark that it worked.
Here are my results (OpenVPN machine has IpEnableRouter=1, LAN adapter and OpenVPN adapter):
Test 0=No NAT, packet from my remote PC 192.168.0.38 can reach every computer, and as there are routes back (192.168.0.0/24 to VPN gateway) I get the reply soon.
Test 1= NAT to OpenVPN Adapter's IP: NAT works, packed will be forwarded to destination PC, but destination PC (wiresharked, too) doesn't answer.
Test 2= NAT to LAN adapter in OpenVPN machine: NAT works, packet will be forwarded to destination PC, destination PC answeres, Reply arrives at OpenVPN LAN adapter as expected, but there reply is not forwarded back to my remote test PC
Test 3=NAT to "Interface address" changes my ICMP packet to come from OpenVPNs transfer network (here 10.10.13.1). Destination computer responds to 10.10.13.1, but that packet is routed to default gateway. So i add a route 10.–>OpenVPN adapter: Now destination PC answers that packet 2x (double!!), OpenVPN gets the reply 2 times, but my remote client gets nothing. Okay, now I push the OpenVPN client a new route, too (10.): WORKS, and the 2x reply effect is gone... Strange.
So my prefered solutions 1 or 2 don't work, the emergency solution 3 is only a little bit better, as I have to setup a route 10.xxx --> OpenVPN Client at the destinations router as a static route OR setup a route 10.xxx --> OpenVPN Client to every PC.
AHA: I "feel", that the problem is, that when I assign a Virtual IP, I have to assign this to "WAN". Unfortunately "OpenVPN" interfaces are not selectable here!
Then there is a bug in Test 3 with NAT to "Interface address": As I have several OpenVPN servers, my wireshark shows NATted packages coming from 10.10.13.1, one minute later from 10.10.12.1, one minute later from 10.10.14.1...
Can somebody add this bug to the bugtracker, or can I do that on my own?
Saturn2888 last edited by
I'm in the same boat as you. I haven't been able to set this up in pfSense 2.0. Hopefully someone will have an answer at some point.