OpenVPN in FreeNAS 11 jail; Connects, but...

CktDesigner

I installed OpenVPN in a jail on FreeNAS 11 using the many guides/posts/etc. available by Googling.

After a lot of reading and experimentation, I got the OpenVPN server to run in the jail and was able to connect from a Windows 10 client.

My local network is using 192.168.1.x with the appropriate netmask.
So the FreeNAS box and the OpenVPN jail have addresses in the 192.168.1.N range.
The OpenVPN server assigns addresses from 10.8.0.x

The OpenVPN server config file contains the statements:

push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 8.8.8.8"

My ipfw.rules file contains the statements:

ipfw -q nat 1 config if epairN
ipfw -q add nat 1 all from 10.8.0.0/24 to any out via epairN
ipfw -q add nat 1 all from any to any in via epairN

(where the N in epairN has the correct number)...

My testing (so far) has been with my client on the same local network as the FreeNAS server (that contains the OpenVPN jail).

So if I simply connect the Windows 10 client (with no OpenVPN tunnel), I can browse the internet and connect FreeNAS shares.

When I connect the Windows 10 client via OpenVPN, if the:
push "redirect-gateway def1 bypass-dhcp"
statement in the server config file is enabled (not commented), the Windows 10 client can not see the internet.
If that statement is commented out, the Windows 10 client can see the internet.

I suspect that packets (from the client) showing up at the OpenVPN server (with 10.8.0.x addresses) are not making it out of the server...
But I thought that the "redirect..." statement sent the internet traffic to the openvpn server (using its IP address), and that the ipfw statement that has 10.8.0.0 in it forwarded that traffic through the server (and then back...)

If the OpenVPN connection is disconnected, I can attach the FreeNAS shares on the client.
If the OpenVPN connection is connected, I can not attach the FreeNAS shares on the client.

While I realize that the intent of OpenVPN (or any VPN) is for use from outside the local network, I would still expect it to work inside the local network. I thought the statements handled that, but obviously I'm missing something...

Any suggestions are appreciated! Thanks!

TinCanTech

CktDesigner wrote My local network is using 192.168.1.x

Bad choice ..

NOTE: your local LAN uses the extremely common subnet address 192.168.0.x or 192.168.1.x. Be aware that this might create routing conflicts if you connect to the VPN server from public locations such as internet cafes that use the same subnet.

:arrow: Never use 192.168.0.0/24 or 192.168.1.0/24 (or other common subnets) for your OpenVPN Server LAN :!:

You are advised to change your server LAN to a more unique RFC1918 compliant subnet.
For example: 192.168.143.0/24

Also, ensure IP forwarding is enabled on your server.

CktDesigner wrote My ipfw.rules file contains the statements:

ipfw -q nat 1 config if epairN
ipfw -q add nat 1 all from 10.8.0.0/24 to any out via epairN
ipfw -q add nat 1 all from any to any in via epairN

I don't recognise those commands but they could be right.

This is the howto for what you are trying to do:
HOWTO: Routing all client traffic (including web-traffic) through the VPN

CktDesigner wrote While I realize that the intent of OpenVPN (or any VPN) is for use from outside the local network, I would still expect it to work inside the local network

It is all too easy to create routing conflicts from inside your LAN but it can be done. It is only worth using the VPN from your LAN for testing though ..

CktDesigner

Thanks.
I solved this problem by using "topology" with statements like this (in the server config file):

mode server
tls-server
topology subnet
ifconfig-pool start-ip end-ip mask
push "route-gateway gate"

where:
start-ip is the IP address where the OpenVPN server will begin issuing addresses
end-ip is the IP address where the OpenVPN server will run out of addresses
mask is the subnet mask
gate is the subnet gateway

Other than using 192.168.1.* addresses, do you see any issues with this method?
Thanks!

TinCanTech

--topology subnet is good and would be the default but for supporting older clients.

I cannot comment on the rest of your configuration because I cannot see it ..

CktDesigner

I took your advice and changed the addresses in my local network.
The local network now has an address that is not 192.168.1.0. Lets say it's 192.168.X.0.
The router from the ISP is set up to serve DHCP to addresses 2-127, with the rest used by me for local static addresses.
I also have two other wireless routers in a couple of places in the house where I was having trouble getting good signal strength.
They serve DHCP addresses to their local addresses of 192.168.X+1.0 and 192.168.X+2.0
I have a FreeNAS machine on the 192.168.X.0 network with its own locally static address.
I have a "jail" in the FreeNAS machine that runs OpenVPN that has its own locally static address (also on the 192.168.X.0 network).
OpenVPN uses a server config file that uses "topology subnet" to issue addresses in a "reserved" range of addresses in the 192.168.X.0 network

When I connect (from a Windows 10 client) to one of the wireless access points, I have full access to everything (pings to machines, shares from FreeNAS, Internet)
When I connect that same machine via OpenVPN, I get the an address in the expected range on the 192.168.X.0 network (one of the OpenVPN reserved addresses). I can access the Internet. However, I can't ping machines on the 192.168.X.0 network, so I can't access shares from FreeNAS.

With "verb" set to 6, I can see (what I believe to be) ping packets directed to the gateway of the 192.168.X.0 network. Since the OpenVPN addresses are part of the 192.168.X.0 network, I didn't think I needed any "routing statements" that "forward" to the same (192.168.X.0) network.

I tried a number of different things to try to get ping from the client to see the rest of the 192.168.X.0 network, but (obviously) no success...

How can I get the OpenVPN connected machines to see the rest of the network they are on?

Suggestions welcome!!! Thanks!

TinCanTech

Which sounds like a completely different problem altogether ..