OpenVPN bridged to LAN stops working
-
Hello,
I have set up a Linux based OpenVPN server and two pfSense CE boxes using TAP so that the OpenVPN network (192.168.100.0/24) is bridged to a LAN port on each pfSense CE box. (See diagram below).
The two computers can ping each other as well as the three OpenVPN instances (i.e Server at 192.168.100.241, Client 1 at 192.168.100.242 and Client 2 at 192.168.100.243). This is as expected and, probably required for the application.
However, it only works before the WAN connection to a pfSense box is lost, and for a few seconds after it is restored, at which point the OpenVPN task on the box with the restored connection stops. The stopped task won’t restart until either the GUI is used to delete the bridge between OPT1 and LAN, reform the bridge, and restart the OpenVPN task, or the pfSense box is power cycled. The other pfSense box in the setup keeps running unless it also loses the WAN connection to the OpenVPN server.
Looking at the OpenVPN log for when the OpenVPN succesfully starts, I see this:
...... Jul 3 10:50:17 openvpn 30482 Using peer cipher 'AES-256-GCM' Jul 3 10:50:17 openvpn 30482 TUN/TAP device ovpnc1 exists previously, keep at program end Jul 3 10:50:17 openvpn 30482 TUN/TAP device /dev/tap1 opened Jul 3 10:50:17 openvpn 30482 /sbin/ifconfig ovpnc1 192.168.100.242/24 mtu 1500 up Jul 3 10:50:17 openvpn 30482 /usr/local/sbin/ovpn-linkup ovpnc1 1500 0 192.168.100.242 255.255.255.0 init Jul 3 10:50:17 openvpn 30482 Initialization Sequence Completed Jul 3 10:50:17 openvpn 30482 Data Channel: cipher 'AES-256-GCM', peer-id: 0 Jul 3 10:50:17 openvpn 30482 Timers: ping 10, ping-restart 120 Jul 3 10:50:17 openvpn 30482 Protocol options: explicit-exit-notify 1whereas when the OpenVPN task is shut down after the WAN reconnection, I see this:
Jul 3 10:53:59 openvpn 19576 Using peer cipher 'AES-256-GCM' Jul 3 10:53:59 openvpn 19576 TUN/TAP device ovpnc1 exists previously, keep at program end Jul 3 10:53:59 openvpn 19576 TUN/TAP device /dev/tap1 opened Jul 3 10:53:59 openvpn 19576 /sbin/ifconfig ovpnc1 192.168.100.242/24 mtu 1500 up Jul 3 10:53:59 openvpn 19576 FreeBSD ifconfig failed: external program exited with error status: 1 Jul 3 10:53:59 openvpn 19576 Exiting due to fatal errorMy main question is: Should /sbin/ifconfig ovpnc1 192.168.100.242/24 mtu 1500 up giving exit code of 1 be fatal?
My secondary question is: I want to connect two remote LANs running on the same subnet so that the equipment on both LANS believe that they are local to each other (i.e. they use the same subnet to access each other). Is there another way of configuring this using OpenVPN for security, and pfSense at each site?
Thanks,
TD -
I have the same problem, as a temporary workaround I've set cron jobs
Ive created a/etc/cron.d/ovpn file to destroy my ovpn interface and re-launch openvpn service every 30 seconds for clients and every minutes for server in case of failure :On server service restart only if every clients are unreachable, on the clients service restart if server become unreachable.
Tell me if you find a more elegant way !
Cron file on the server :
SHELL=/bin/sh PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin IP_CLIENT1="10.10.0.254" IP_CLIENT2="10.10.1.254" * * * * * root (/sbin/ping -c 1 "$IP_CLIENT1" || /sbin/ping -c 1 "IP_CLIENT2") || (/sbin/ifconfig ovpns1 | grep -q "ovpns1:" && /sbin/ifconfig ovpns1 destroy; /usr/local/sbin/pfSsh.php playback svc restart openvpn server 1)and on each client :
SHELL=/bin/sh PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin IP_SERVER="10.10.255.254" * * * * * root /sbin/ping -c 1 "$IP_SERVER" || (/sbin/ifconfig ovpnc1 | grep -q "ovpnc1:" && /sbin/ifconfig ovpnc1 destroy; /usr/local/sbin/pfSsh.php playback svc restart openvpn client 1) * * * * * root sleep 30; /sbin/ping -c 1 "$IP_SERVER" || (/sbin/ifconfig ovpnc1 | grep -q "ovpnc1:" && /sbin/ifconfig ovpnc1 destroy; /usr/local/sbin/pfSsh.php playback svc restart openvpn client 1) -
I have the same issue
This was working fine in 5.x series, I skipped 6 and upgraded to 7. All bridges on the client side seemed to be working fine until the internet was restarted and none of the OVPN bridges would reconnect.
I thought my upgrade was the reason so made a fresh 7.x install and created a very simple WAN,LAN,OPT1 where OPT1 was bridged to OPENVPN. The problem persisted. However, I noticed it seems to be related to the bridge required between the OPENVPN interface and OPT1 interface. What I found was if I removed the Bridge the OPENVPN instance would no longer fail, of course this is completely academic as the whole point is bridging OPENVPN to an interface.
In summary client side OVPN Bridge functionality appears fundamentally broken.
- Works on first boot.
- If the OVPN client is disconnected for any reason it will never reconnect, alway dies with fatal error.
- If the Bridge between the OVPN interface and target Interface is removed the OVPN client can reconnect with no problem.
Logs are pretty much identical as already posted. First shows no problem on boot, 2nd shows failure on trying to reconnect:
On Boot
Time Process PID Message Jul 31 16:50:54 openvpn 65132 Initialization Sequence Completed Jul 31 16:50:54 openvpn 65132 /usr/local/sbin/ovpn-linkup ovpnc1 1500 0 172.18.202.90 255.255.255.0 init Jul 31 16:50:54 openvpn 65132 /sbin/ifconfig ovpnc1 172.18.202.90/24 mtu 1500 up Jul 31 16:50:54 openvpn 65132 TUN/TAP device /dev/tap1 opened Jul 31 16:50:54 openvpn 65132 TUN/TAP device ovpnc1 exists previously, keep at program endOn Reconnect
Jul 31 16:53:08 openvpn 5250 Exiting due to fatal error Jul 31 16:53:08 openvpn 5250 FreeBSD ifconfig failed: external program exited with error status: 1 Jul 31 16:53:08 openvpn 5250 /sbin/ifconfig ovpnc1 172.18.202.90/24 mtu 1500 up Jul 31 16:53:08 openvpn 5250 TUN/TAP device /dev/tap1 opened Jul 31 16:53:08 openvpn 5250 TUN/TAP device ovpnc1 exists previously, keep at program endSo for now I've just rolled back to 5.x series, with no more burned bridges. :-)
-
@theotech said in OpenVPN bridged to LAN stops working:
-
-
-
-
- root (/sbin/ping -c 1 "$IP_CLIENT1" || /sbin/ping -c 1 "IP_CLIENT2") || (/sbin/ifconfig ovpns1 | grep -q "ovpns1:" && /sbin/ifconfig ovpns1 destroy; /usr/local/sbin/pfSsh.php playback svc restart openvpn server 1)
-
-
-
There is a missing "$" for the second variable in this line, corrected version :
* * * * * root (/sbin/ping -c 1 "$IP_CLIENT1" || /sbin/ping -c 1 "$IP_CLIENT2") || (/sbin/ifconfig ovpns1 | grep -q "ovpns1:" && /sbin/ifconfig ovpns1 destroy; /usr/local/sbin/pfSsh.php playback svc restart openvpn server 1) -
-
I needed something similar recently with same LAN Subnet in two locations. In my case one PfSense was the server and the other the client. I used the Opt1 interfaces for the OVPN bridge, to allow me separate LAN access to the PF GUI. Tunnel should normally be a separate subnet that is not seen by the LAN.
The OpenVPN server was always listening on WAN (immediately after reboot), and the remote client simply connected automatically after it booted up (mostly before I had logged into the PF GUI).
The same kit was tested with the Remote PF connected to three different ISP connections, and worked correctly in all cases.
-
I can see that your fix is elegant and circumvents the problem. For my application's clients are being assigned an IP address from a pool as and when they connect (which is whenever they need to access the system, which may only be for a few minutes at a time, or 24/7). So, not seeing any clients does not definitely mean there is a problem.
@theotech @m5ip25 @pwood999
I am glad I am not the only one seeing this bug. Anyways, I have found a solution that got me out of this issue but it may not suit everyone. Before seeing the reply from @m5ip25 saying that it worked on 5.x, I tried the exact same configuration on OPNsense to see if I was crazy in expecting it to work with pfSense. It worked perfectly, so after 6 years of only using pfSense, I am now using trying OPNsense on the units that need the bridge.All the best, TD
-
Thanks for confirming OPNSense worked. I've been putting off migrating from PF for ages. Sad day. Anyway, for anyone interested I also gave the 8.x dev build from 1 August a try and the same bug persists. I wonder if this is also a problem in the "plus" version.
-
@m5ip25
Just wanted to say that this seems similar to the issue I'm experiencing after updating to 2.7.0. In my case it's a simple point to point tap bridged to physical interfaces on each end. Tap needed because the whole purpose of the tunnel is to pass multicast video traffic.
https://forum.netgate.com/topic/183115/openvpn-client-process-fails-after-upgrade-to-2-7-0