LAN computers can't reach computers behind OpenVPN Server
-
I think lufu and I want to do the same thing and as I mentioned in my posts above it IS possible to connect to a remote OpenVPN server
without having to explicitly specify routes on the client.
On my DD-WRT box this works out-of-the-box (and it even works as lufu wants it to: local LAN (openvpn client) can connect to remote LAN (openvpn server))The only issue I'm having is that I need to masquerade the ip addresses of the local clients, otherwise the server will drop the packages.
But I have no clue how to do this in pfSense.So any help on this would be greatly appreciated.
-
@gds:
I think lufu and I want to do the same thing and as I mentioned in my posts above it IS possible to connect to a remote OpenVPN server
without having to explicitly specify routes on the client.
On my DD-WRT box this works out-of-the-box (and it even works as lufu wants it to: local LAN (openvpn client) can connect to remote LAN (openvpn server))The only issue I'm having is that I need to masquerade the ip addresses of the local clients, otherwise the server will drop the packages.
But I have no clue how to do this in pfSense.So any help on this would be greatly appreciated.
You dont have to create routes on the clients.
This is why you should add the commandsin the client you should have something like:
route 192.168.200.0 255.255.255.0
The server would have something like:
route 192.168.0.0 255.255.255.0To the OpenVPN-config, so OpenVPN adds the routes for you.
I'm not sure how you imagine you would want to access an IP-range without ever telling the router where to send the traffic.
NAT/masquerade wont help with this. You still need a known destination. -
Sorry, I meant specifying a route option on the client, not creating a route on the client.
But believe it or not, both DD-WRT and Tomato are able to connect to the openvpn server at the office without having to specify this on the client:
in the client you should have something like: route 192.168.200.0 255.255.255.0
And yes all clients on my home LAN can access the pc's on the corporate LAN through this openvpn tunnel.
But the pc's on the corporate LAN can't access the pc's on my home LAN (which is what I want)So the openvpn server does a "push route", but not the client.
For completeness, this is the config on the server:
port 1194 proto udp dev tun ca keys/ca.crt cert keys/office.crt key keys/office.key dh keys/dh1024.pem server 10.1.10.0 255.255.255.0 push "route 10.0.10.0 255.255.255.0" ifconfig-pool-persist poolpersist.dat keepalive 120 900 comp-lzo user nobody group nobody persist-key persist-tun status openvpn-status.log verb 4 crl-verify /etc/openvpn/crl/crl.pem
By masquerading the ip's from my home LAN, the openvpn server thinks he is talking to my router/firewall (DD-WRT, Tomato, whatever)
instead of a client behind it.
It's my home router/firewall who (should) redirects the received packages to the corresponding client on the LAN.
Or at least that's my understanding of it.But as I said I have no idea how I can set up this masquerading on pfsense.
Or in other words, how can I specify SNAT rules on pfSense ? -
Firewall –> NAT --> Outbound.
But you can currently only specify "real" interfaces.I'm not sure if with the changes to allow firewalling of the OpenVPN interface it's now possible to NAT into the tunnel as well.
What you can try:- Update to a recent 1.2.3
- Enable OpenVPN filter as described here:
http://blog.pfsense.org/?p=428
Disable auto-added VPN rules option - added to System -> Advanced to prevent the addition of auto-added VPN rules for PPTP, IPsec, and OpenVPN tun/tap interfaces. Allows filtering of OpenVPN client-initiated traffic when tun/tap interfaces are assigned as an OPT.
- Add the OPT interface for OpenVPN.
- Now enable under Firewall –> NAT --> Outbound "manual outbound NAT" and create a new rule.
- When you create the new rule you should now be able to select as "interface" the OPT interface which represents the virtual OpenVPN tunnel.
I dont know if this really works.
In current versions it's not possible to select the OpenVPN interface for manual NAT.
But worth a try ;) -
That's what I was afraid for, no SNAT'ing on the vpn interface.
Thanks for the tip on trying v1.2.3, but how stable is this v1.2.3 ?
I already switched my entire LAN to pfSense, so I don't want to take any unnecessary risks by upgrading
to an unstable version and/or creating some experimental rules ;) -
1.2.3 is currently an RC.
Most people can run the RCs with absolutely no problems.@http://forum.pfsense.org/index.php/topic:
Usually the best thing is to watch http://redmine.pfsense.org and http://rcs.pfsense.org if you want to watch things in detail.
Interresting to look:
https://rcs.pfsense.org/projects/pfsense
https://rcs.pfsense.org/projects/pfsense/repos/mainline/logs/RELENG_1_2 -
thanks for the pointers.
I'm still undecided, but probably I'll set up a vmware image with the latest v1.2.3 and use that as a testing platform for the openvpn stuff…
-
Don't know why I didn't found this before, but I just stumbled upon this post, which describes a temporary workaround (see edit at the end):
http://forum.pfsense.org/index.php/topic,6341.msg36590.html#msg36590Adding that rule after having established the openvpn connection does make it work,
but as soon as you reboot or even restart the openvpn connection, the rule is gone again.Therefore I opened the file /etc/inc/filter.inc in an editor and added the following 2 lines at the end of the function "filter_nat_rules_generate()":
$natrules .= "\n# Custom NAT rule required for OpenVPN client connection\n"; $natrules .= "nat on tun0 from 192.168.1.0/24 to any -> (tun0)\n";
I know this is probably not supported ::) , but it does seem to do the job for now… 8)
-
@gds:
Don't know why I didn't found this before, but I just stumbled upon this post, which describes a temporary workaround (see edit at the end):
http://forum.pfsense.org/index.php/topic,6341.msg36590.html#msg36590Adding that rule after having established the openvpn connection does make it work,
but as soon as you reboot or even restart the openvpn connection, the rule is gone again.Therefore I opened the file /etc/inc/filter.inc in an editor and added the following 2 lines at the end of the function "filter_nat_rules_generate()":
$natrules .= "\n# Custom NAT rule required for OpenVPN client connection\n"; $natrules .= "nat on tun0 from 192.168.1.0/24 to any -> (tun0)\n";
I know this is probably not supported ::) , but it does seem to do the job for now… 8)
I don't see this function in /etc/inc/filter.inc running 1.2.3-RC1. I also need NAT on tun0. I need a way to automatically add this rule. Why did they bother putting an OpenVPN client in pfSense if they weren't going to run NAT on it?
-
Okay, Reply #13 was very helpful. I added tun0 as OPT1 and then added an outbound NAT entry and now LAN traffic is able to go out the OpenVPN client.
Thanks GruensFroeschli for that tip.