OPNsense Forum
Archive => 19.7 Legacy Series => Topic started by: whit on September 23, 2019, 09:35:55 pm
-
This is a new thread based on "OpenVPN from Linux client -- also server fails to start with tun1 error".
In summary, WireGuard starts tunnels using tun devices, renaming them to wg0, wg1 ... wgN. OpenVPN also uses tun devices. In a system with existing wg0, wg1 and wg2 devices, the OpenVPN server startup currently tries to use tun1, which is not available, as already in use as wg1. So OpenVPN simply fails.
Presumably this would not result if only a single wgN device were running based on a renamed tun0, and it's doable in WireGuard to have multiple tunnels based on a single wgN device. But the current OPNsense setup requires each remote endpoint have its own tunN (wgN) device on OPNsense, so that's not a viable workaround when multiple WireGuard tunnels are required.
It's possible that starting OpenVPN before WireGuard would avoid this. Haven't tested that. The system where this has become evident is in production, and the WireGuard tunnels are of higher value to us than OpenVPN access. In any case, the current setup is clearly a bug in the OpenVPN startup, which should be smart enough, on failing to use tun1, to increment N until tunN is found available to it.
-
Can you post a link to the other thread?
-
The problem comes in at line 546 in openvpn.inc:
if (!does_interface_exist($devname)) {
if (!file_exists("/dev/{$devnode}")) {
mwexecf('/sbin/ifconfig %s create', array($devnode));
}
The problem is that does_interface_exist looks specifically for tun devices named ovpnsN and ovpncN, so entirely misses that tunN is in use when it's been renamed wgN instead of ovpnsN or ovpncN for server or client. What's needed is a test for the interface's current use that works no matter what the device may have been renamed to after creation. When tun1 has been renamed wg1, as in my case, this code misses it as it assumes that the only consumer of tunN interfaces is OpenVPN.
-
Can you post a link to the other thread?
https://forum.opnsense.org/index.php?topic=14282.0
-
ifconfig -g tun will list all devices in the "tun" group, which looks sufficient. So the code could call that, then take the numbers from those, and go +1 from the highest number returned for the next tunN to use from OpenVPN. Or perhaps it should start with the highest returned, try that, and go up +1 only if that turns out to be already in use.
-
Maybe it's worth open a feature request in GitHub core for OpenVPN.
-
OpenVPN code has always been a little dirty in his regard not playing nice with other tun/tap consumers. GitHub issue appreciated.
Cheers,
Franco