LAN computers can't reach computers behind OpenVPN Server

kpa

The remote end point needs to have a route back to the local LAN over the vpn tunnel. The best way to add this route is to use the route -option in openvpn config file.

gds

Thanks for your answer, but in that case it wouldn't work with the linksys router (DD-WRT) either.
Now, in the meantime I did some more investigation and found this in the openvpn server logs:

Aug 20 14:00:19 <server-name>openvpn[26185]: gds/<client-wan-ip>:21469 Need IPv6 code in mroute_extract_addr_from_packet
Aug 20 14:03:01 <server-name>openvpn[26185]: gds/<client-wan-ip>:21469 MULTI: bad source address from client [192.168.1.98], packet dropped</client-wan-ip></server-name></client-wan-ip></server-name>

So apparently the server is receiving the real ip adres of the client which it doesn't like.

This made me think that I should probably do some SNAT'ing in order to hide the clients ip address.
And indeed, that's what the "route-up.sh" and "route-down.sh" scripts on my DD-WRT router seem to do:

~ # cat /tmp/openvpn/route-up.sh
iptables -A POSTROUTING -t nat -o tun0 -j MASQUERADE
~ # cat /tmp/openvpn/route-down.sh .sh
iptables -D POSTROUTING -t nat -o tun0 -j MASQUERADE

Unfortunately I have no idea how to do this on the pfSense server

lufu

Hello Briantist,

1. Is the OpenVPN server pfSense or something else?
It is a OpenSuse Box runnig an OpenVPN Server

2. Can LAN clients (B) ping LAN clients (A)?
no they can't. And i would like to keep it that way.
But i can Ping the IP that the OpenVPN Server has assigned to my pfSense box from LAN B.

3. Post at least your OpenVPN client config, and if possible, the server config too.
Authentication method: PKI


client
dev tun
proto udp
remote xx.xx.xx.xx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert test.crt
key test.key
cipher AES-256-CBC
comp-lzo
auth SHA1

My Goal is that CLients on LAN A can Access Lan Clients B, but LAN Clients B shouldn't be able to have access to the Clients on LAN A.

LAN A
192.168.0.0/24
LAN B
192.168.200.0/24
OenVPN LAN
192.168.1.0/24

My pfSense Box has got the IP Addresses 192.168.0.50 (LAN A Subnet) and 192.168.1.2 (OpenVPN Subnet) and the OPEN VPN Server 192.168.1.1 (OpenVPN Subnet)

Let's say i would send a Ping fron LAN A to LAN B.
LAN A Client 192.168.0.10 sends the Ping request to his Gateway 192.168.0.50(pfSense).
Now the pfSense box should send the request via his OpenVPN Subnet IP 192.168.1.2
The Client on LAN B recieves the Ping request and sends the Answer back to the IP 192.168.1.2
Now my pfSense box should route the Ping back to the Client in LAN A.

Is this possible?

Briantist

@lufu:

Hello Briantist,

1. Is the OpenVPN server pfSense or something else?
It is a OpenSuse Box runnig an OpenVPN Server

2. Can LAN clients (B) ping LAN clients (A)?
no they can't. And i would like to keep it that way.
But i can Ping the IP that the OpenVPN Server has assigned to my pfSense box from LAN B.

3. Post at least your OpenVPN client config, and if possible, the server config too.
Authentication method: PKI
client
dev tun
proto udp
remote xx.xx.xx.xx 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert test.crt
key test.key
cipher AES-256-CBC
comp-lzo
auth SHA1
My Goal is that CLients on LAN A can Access Lan Clients B, but LAN Clients B shouldn't be able to have access to the Clients on LAN A.

LAN A
192.168.0.0/24
LAN B
192.168.200.0/24
OenVPN LAN
192.168.1.0/24

My pfSense Box has got the IP Addresses 192.168.0.50 (LAN A Subnet) and 192.168.1.2 (OpenVPN Subnet) and the OPEN VPN Server 192.168.1.1 (OpenVPN Subnet)

Let's say i would send a Ping fron LAN A to LAN B.
1. LAN A Client 192.168.0.10 sends the Ping request to his Gateway 192.168.0.50(pfSense).
2. Now the pfSense box should send the request via his OpenVPN Subnet IP 192.168.1.2
3. The Client on LAN B recieves the Ping request and sends the Answer back to the IP 192.168.1.2
4. Now my pfSense box should route the Ping back to the Client in LAN A.

Is this possible?

1. Consider this: unless you've added a static route to your client on LAN A, it has no idea how to get to LAN B's subnet, so it sends it to its default gateway, which is 192.168.0.50. This is the correct and expected behavior.
2. It should but if it doesn't have a route that tells it that it can get to LAN B's subnet by using the OVPN subnet, then the packet will not go across the VPN. Let's assume it does have this route.
3. The client does not send the reply to 192.168.1.2, it sends it to the address of the client on LAN A (192.168.0.X), and it since it has no route to it, it sends it back to its default gateway, 192.168.200.1(?). If that machine has no route to get to 192.168.0.X, then the reply will never reach you even if the original echo request packet got through.
4. If you get to this point, then yes that is what will happen.

Focus on 2 and 3. Look at the routing tables on both your pfSense box and on your OpenSUSE box. I see a distinct lack of a route command within your OpenVPN client config. I don't even see the ifconfig directive unless you left it our on purpose. Anyway, in 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.0

I know you desire not to have LAN B be able to ping LAN A, but you can't do that correctly with routing. You would have to have a firewall blocking the traffic (currently it's kind of buggy to filter an OpenVPN interface in pfSense and it only works in 1.2.3; see other posts for info). First get it working where the traffic flows through; you can try to worry about blocking LAN B after that.

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.

GruensFroeschli

@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 commands

in 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.0

To 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.

gds

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 ?

GruensFroeschli

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 ;)

gds

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 ;)

GruensFroeschli

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

gds

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…

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#msg36590

Adding 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)

ermax

@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#msg36590

Adding 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?

ermax

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.