I have three machines I am trying to coordinate through a TUN connection.
FREEBSD
box running OpenVPN server (tun)
10.0.200.21/24 on local subnet
10.0.202.1/24 on VPN
REMOTE
Public IP
10.0.202.6/24 on VPN
WEBSERVER
10.0.200.31/24 on local subnet
I can get REMOTE
to VPN to FREEBSD
via OpenVPN and the connection is fine, but it is configured incorrectly. When I try to connect from REMOTE
to WEBSERVER
via typing WEBSERVER
's ip address into REMOTE
's browser, WEBSERVER
is unreachable. It is reachable if I attach REMOTE
to the local subnet directly.
I learned the following while troubleshooting.
REMOTE
can pingFREEBSD
and even SSH to it.- A packet capture set up on
FREEBSD
's ethernet port captures no packets from or toREMOTE
's VPN IP of 10.0.202.6. So REMOTE's packets are not making it to the local subnet. - The openvpn.log file on
FREEBSD
has the following line:GET INST BY VIRT: 10.0.200.31 [failed]
So, it seems that OpenVPN is not forwarding packets received on the TUN device to FREEBSD
's ethernet adapter and out to the local subnet.
I do have the following line in my server.conf file.
push "route 10.0.200.0 255.255.255.0"
I tried adding this line but it didn't help.
route 10.0.200.0 255.255.255.0
Here's the routing table on FREEBSD
Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.200.1 UGS 0 4306 re0 10.0.200.0 link#9 U 0 61582 re0 10.0.200.21 link#9 UHS 0 41 lo0 10.0.201.0 10.0.200.1 UGS 0 0 re0 10.0.202.0 10.0.202.2 UGS 0 0 tun0 10.0.202.1 link#12 UHS 0 0 lo0 10.0.202.2 link#12 UH 0 0 tun0 localhost link#11 UH 0 193743 lo0
I have read online about the GET INST BY VIRT: 10.0.200.31 [failed]
message and it was recommended for Linux machines to run the following command.
echo 1 > /proc/sys/net/ipv4/ip_forward
I am afraid to run it because I don't understand it and don't want to get FREEBSD
into a strange configuration. I also strongly prefer a solution that modifies the server.conf file to automatically create the necessary configuration so it is properly managed and torn down when OpenVPN is closed.
What is the solution to this problem?
Best Answer
Found the problem. Turns out that FreeNAS, the NAS appliance software based on FreeBSD and which I am referring to as
FREEBSD
above, has thenet.inet.ip.forwarding
set to 0. This can be viewed by using the commandsysctl -a | grep net.inet.ip.forwarding
. In order to get the packets to forward, I had to do asysctl net.inet.ip.forwarding=1
.This change does not persist through reboots. I think I may have to use the /etc/rc.conf file and set
gateway_enable="YES"
, but so far I have found that this setting does not get processed until reboot, and unfortunately on FreeNAS, rc.conf seems to be overwritten every reboot. It may be possible to write this variable to /etc/defaults/rc.conf, which is supposed to store the defaults for the system and is the overwritten by custom configurations in rc.conf, but the /etc/defaults/rc.conf file has a warning at the top to not edit it.So, this problem is not totally solved, but at least I have figured out what the issues seems to be. Now that I understand this, I am now noticing a problem with logging in to https web management appliances on the local subnet. That will be another problem to solve.