Open jcea opened 7 years ago
I'm pretty sure this is caused by joyent/smartos-live#626 and is an issue in the tun/tap driver rather than the pkgsrc openvpn package. I'll leave this bug open in the meantime though so we have an extra data point and test candidate when that bug is resolved.
Any workaround in the meantime? Current situation is quite painful because it requires manual intervention involving a zone reboot.
Any workaround in the meantime? Current situation is quite painful because it requires manual intervention involving a zone reboot.
@jcea I make use of the OpenVPN client in a few places. I think I had to add persist-tun
to the configuration file to make it work correctly on reconnection.
The full configuration appears below:
client
dev tun
persist-tun
proto udp
resolv-retry infinite
nobind
ca ssl/ca.crt
cert ssl/client.crt
key ssl/client.key
comp-lzo
verb 3
remote-cert-tls server
remote X.X.X.X 1194
@jclulow I already have "persistent-tun" in my configuration. I think the problem is when the server refused the connection because, for instance, disk full. I have a connection validation script in the server and if something goes wrong with the database, for instance, connections are temporary refused. The problem is that this zone OpenVPN client will die... good, but when the OpenVPN SMF restarts the process, it will fail. This situation persists until the zone is rebooted.
Regular reconnections seems to work ok.
@jperkin This issue is not related to interference between zones, I think. I have more native zones in this machine, but no one else is using TUN at the same time.
I have a trivial way to reproduce this problem:
Hi, I believe problem is this:
Can't unlink interface(ip): Not owner (errno=1)
It can be worked around by manually unplumbing the tap interface after stop.
ifconfig tun0 unplumb
Adding it to /opt/local/lib/svc/method/openvpn (before starting the openvpn) works for me. But if you use multiple tun interfaces, you somehow should find out which tunX interface to unplumb.
Jan
There is an open bug on the OpenVPN side for this as well
https://community.openvpn.net/openvpn/ticket/1078
unfortunately I am totally lost what all these PPA and I_PUSH etc. things do on Solaris - on restart (because a server went away and came back) we do try to clean up the existing tun/tap device, and then re-init from scratch.
Unfortunately, something seems to be missing in "cleaning up", so we get these "EEXIST" errors... help from someone who understands Solaris network stuff better is certainly welcome.
I have been using OpenVPN as a client for ages. One of the recent clients is a SmartOS native zone instance (base-64 16.3.1). If the VPN connection is severed in anyway (timeout, server restart, etc) the SmartOS client can not connect again.
My OpenVPN is just stock "pkg install". Restarting the SMF service does nothing. After some trying I just restart the zone. Everything is fine after that.
Checking the logfile I see this:
The SMF service will restart the OpenVPN client that cycle of connection & crashing until I restart the zone.
I use the same configuration (ovpn file) in my iOS devices and multiple Linux machines without any issue.