I have three machines I am trying to coordinate through a TUN connection.

FREEBSD box running OpenVPN server (tun) on local subnet on VPN

Public IP on VPN

WEBSERVER 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 ping FREEBSD and even SSH to it.
  • A packet capture set up on FREEBSD's ethernet port captures no packets from or to REMOTE's VPN IP of 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: [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"

I tried adding this line but it didn't help.

Here's the routing table on FREEBSD

Routing tables

Destination        Gateway            Flags    Refs      Use  Netif Expire
default           UGS         0     4306    re0         link#9             U           0    61582    re0        link#9             UHS         0       41    lo0         UGS         0        0    re0         UGS         0        0   tun0         link#12            UHS         0        0    lo0         link#12            UH          0        0   tun0
localhost          link#11            UH          0   193743    lo0

I have read online about the GET INST BY VIRT: [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?

2 Answers 2


Found the problem. Turns out that FreeNAS, the NAS appliance software based on FreeBSD and which I am referring to as FREEBSD above, has the net.inet.ip.forwarding set to 0. This can be viewed by using the command sysctl -a | grep net.inet.ip.forwarding. In order to get the packets to forward, I had to do a sysctl 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.


Ok, so your VPN client has a route to get to the network, and your VPN server has a route. But the question is does your web server have a route to get to the network?

Do a tcpdump on the freebsd box. I suspect you will see traffic from your host getting forwarded, but you are not seeing any return traffic.

  • Thanks for your help! I'll look into a tcpdump tomorrow. But I would have thought those packets should have appeared in my Wireshark capture. Also, I do have a static route set up on the local subnet's default gateway (my internet router) to direct packets for to FREEBSD.
    – Shaun
    Jan 26, 2014 at 4:31

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .