[heroes] vpn keeps disconnecting?
For the last week or so, the opensuse vpn keeps disconnecting. In the past, it would be up for weeks and weeks. Has anything changed? -- Per Jessen, Zürich (15.4°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Hi Per, I looked on logs on the server. for UDP I do not see there any problem... See log file in attachment. I checked the TCP logs and I did not found there data about your user name and did not found any. So I have two suggestion for you. one you can try lover MTU... "If your UDP connection is unstable, you have trouble with for example transfer big data via the tunell (e.g git repos) you might have a trouble with MTU. Some switches or routers of your ISP do not accept packets with MTU 1500. Try to lover MTU, mssfix or fragment in your client config file. Default MTU is 1500, try to change it to 1350 or 1300. Adding the following option to the configuration file might help: msfix 1300 The second option is test TCP in stand of UDP. Just add line just add line proto tcp and change port to 443 Try is and let me know. Martin On 02.10.19 08:37, Per Jessen wrote:
For the last week or so, the opensuse vpn keeps disconnecting. In the past, it would be up for weeks and weeks. Has anything changed?
--
Martin Caj
I am using TCP and it is working fine On 2019-10-02 12:57, Martin Caj wrote:
Hi Per,
I looked on logs on the server. for UDP I do not see there any problem... See log file in attachment.
I checked the TCP logs and I did not found there data about your user name and did not found any.
So I have two suggestion for you. one you can try lover MTU...
"If your UDP connection is unstable, you have trouble with for example transfer big data via the tunell (e.g git repos) you might have a trouble with MTU. Some switches or routers of your ISP do not accept packets with MTU 1500. Try to lover MTU, mssfix or fragment in your client config file.
Default MTU is 1500, try to change it to 1350 or 1300. Adding the following option to the configuration file might help: msfix 1300
The second option is test TCP in stand of UDP. Just add line just add line proto tcp and change port to 443
Try is and let me know. Martin
On 02.10.19 08:37, Per Jessen wrote:
For the last week or so, the opensuse vpn keeps disconnecting. In the past, it would be up for weeks and weeks. Has anything changed?
N�����r��y隊X^�����칻 �&ޢ���� ����'��-���w�zf�����>� ޮ�^�ˬz��
Ricardo Klein wrote:
I am using TCP and it is working fine
I'll try tcp and see if it makes a difference. From the log, it looks it has trouble restarting after a time-out. -- Per Jessen, Zürich (15.7°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Martin Caj wrote:
Hi Per,
I looked on logs on the server. for UDP I do not see there any problem...
Hi Martin thanks for your suggestions. last night the vpn terminated like this, after not even an hour: (sorry about the lines folding) Oct 1 21:52:27 io64 openvpn[1678]: Initialization Sequence Completed Oct 1 22:44:28 io64 openvpn[1678]: [scar.opensuse.org] Inactivity timeout (--ping-restart), restarting Oct 1 22:44:28 io64 openvpn[1678]: SIGUSR1[soft,ping-restart] received, process restarting Oct 1 22:44:30 io64 openvpn[1678]: WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info. Oct 1 22:44:30 io64 openvpn[1678]: UDPv4 link local: [undef] Oct 1 22:44:30 io64 openvpn[1678]: UDPv4 link remote: [AF_INET]195.135.221.151:1194 Oct 1 22:44:41 io64 openvpn[1678]: [scar.opensuse.org] Peer Connection Initiated with [AF_INET]195.135.221.151:1194 Oct 1 22:44:43 io64 openvpn[1678]: Preserving previous TUN/TAP instance: tun0 Oct 1 22:44:43 io64 openvpn[1678]: NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device. Oct 1 22:44:43 io64 openvpn[1678]: ERROR: Linux route delete command failed: external program exited with error status: 2 Oct 1 22:44:43 io64 openvpn[1678]: /bin/ip addr del dev tun0 local 192.168.252.207 peer 192.168.252.1 Oct 1 22:44:43 io64 openvpn[1678]: Linux ip addr del failed: external program exited with error status: 2 Oct 1 22:44:45 io64 openvpn[1678]: ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1) Oct 1 22:44:45 io64 openvpn[1678]: Exiting due to fatal error
See log file in attachment.
I checked the TCP logs and I did not found there data about your user name and did not found any.
So I have two suggestion for you. one you can try lover MTU...
I might try some of that - it is just odd that it has started doing this since August 29 (exactly). Otherwise, it was running since 1 January :-) From the log - Aug 29 09:40:01 io64 openvpn[23955]: Exiting due to fatal error Sep 9 21:32:23 io64 openvpn[16960]: Exiting due to fatal error Sep 15 15:43:09 io64 openvpn[13355]: Exiting due to fatal error Sep 20 20:33:16 io64 openvpn[20348]: Exiting due to fatal error Sep 21 16:49:00 io64 openvpn[14054]: Exiting due to fatal error Sep 27 23:16:06 io64 openvpn[31637]: Exiting due to fatal error Sep 29 17:49:52 io64 openvpn[2511]: Exiting due to fatal error Oct 1 21:41:36 io64 openvpn[30244]: Exiting due to fatal error Oct 1 22:44:45 io64 openvpn[1678]: Exiting due to fatal error -- Per Jessen, Zürich (16.1°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Hello Per, On Wed, 2 Oct 2019, Per Jessen wrote:
Oct 1 22:44:43 io64 openvpn[1678]: Preserving previous TUN/TAP instance: tun0 Oct 1 22:44:43 io64 openvpn[1678]: NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
So the normal reconnect happing every hour or so isn't working. Here because option changes (which seem strange, but let's assume that is okay) made openvpn tear down the interface ...
Oct 1 22:44:43 io64 openvpn[1678]: ERROR: Linux route delete command failed: external program exited with error status: 2
... which already runs into troubles when trying to delete the route ...
Oct 1 22:44:43 io64 openvpn[1678]: /bin/ip addr del dev tun0 local 192.168.252.207 peer 192.168.252.1 Oct 1 22:44:43 io64 openvpn[1678]: Linux ip addr del failed: external program exited with error status: 2
... and the address ...
Oct 1 22:44:45 io64 openvpn[1678]: ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)
... and then fatally errors when trying to do some changes on the tun interface itself via an ioctl. This doesn't sound like any problem on the remote side, but rather a change local to you, e.g. a kernel update with broken permission checks? Ciao, Michael. -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Michael Matz wrote:
Hello Per,
On Wed, 2 Oct 2019, Per Jessen wrote:
Oct 1 22:44:43 io64 openvpn[1678]: Preserving previous TUN/TAP instance: tun0 Oct 1 22:44:43 io64 openvpn[1678]: NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device.
So the normal reconnect happing every hour or so isn't working.
Yep. and it worked fine up until August 29.
Here because option changes (which seem strange, but let's assume that is okay) made openvpn tear down the interface ...
The message "Pulled options changed on restart ..." also appeared for the first time on August 29.
Oct 1 22:44:43 io64 openvpn[1678]: ERROR: Linux route delete command failed: external program exited with error status: 2
... which already runs into troubles when trying to delete the route ...
I wonder if that might be some timing issue? I see it has happened 4 times since January 1, but then 8-10 times since August 29.
Oct 1 22:44:43 io64 openvpn[1678]: /bin/ip addr del dev tun0 local 192.168.252.207 peer 192.168.252.1 Oct 1 22:44:43 io64 openvpn[1678]: Linux ip addr del failed: external program exited with error status: 2
... and the address ...
Maybe this suggests the tunnel is already gone and has taken the route with it, so route and address cannot be deleted.
Oct 1 22:44:45 io64 openvpn[1678]: ERROR: Cannot ioctl TUNSETIFF tun: Operation not permitted (errno=1)
... and then fatally errors when trying to do some changes on the tun interface itself via an ioctl. This doesn't sound like any problem on the remote side, but rather a change local to you, e.g. a kernel update with broken permission checks?
This machine hasn't been updated since 10.3 .... :-) Still, let me reboot and see what happens. -- Per Jessen, Zürich (16.2°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Per Jessen wrote:
The message "Pulled options changed on restart ..." also appeared for the first time on August 29.
The above seems to be the real issue. Looking the options pushed, I see "peer-id" changing every time. From 0 to 4 to 0 to 3 to 0. -- Per Jessen, Zürich (13.9°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Per Jessen wrote:
Per Jessen wrote:
The message "Pulled options changed on restart ..." also appeared for the first time on August 29.
The above seems to be the real issue. Looking the options pushed, I see "peer-id" changing every time. From 0 to 4 to 0 to 3 to 0.
https://community.openvpn.net/openvpn/ticket/649
When running 2.3.8 against a git HEAD server, a client restart (caused by, e.g., ping-restart or SIGUSR1) will often get a different peer-id in its post-restart PUSH_REPLY message than it did at initial bringup. This triggers the "Pulled options changed on restart, will need to close and reopen TUN/TAP device." behavior; if privileges have been dropped, the interface configuration commands will fail, causing the OpenVPN process to exit.
I am in fact running 2.3.8. Guess I'll need an upgrade. I'd still like to know what prompted this, on 29 August. -- Per Jessen, Zürich (11.4°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Hi Per, Am 05.10.19 um 10:10 schrieb Per Jessen:
I am in fact running 2.3.8. Guess I'll need an upgrade. I'd still like to know what prompted this, on 29 August.
I guess we upgraded the machine running OpenVPN on the server side to Leap 15.1 on Aug 29, which also included an update to OpenVPN itself: Before the version we ran (and apparently didn't update for quite a while):
2017-10-27 19:30:07|install|openvpn|2.3.8-14.1|x86_64||repo-update-oss|271268eb074aa7199d88c957958c37a85f1aa03b3e28620aa09d2500673ae450|
Since August 29 we are now running:
2019-08-29 06:29:42|install|openvpn|2.4.3-lp151.4.3|x86_64||repo-oss|69ab2871d4175728a2e0eb581ebaa46c7c274aa23babd3156b7c0596614ab9b4|
Additionally a whole bunch of other packages have been touched (due to
the distribution upgrade). I didn't notice anything wrong on my end,
though, but on the other hand I'm not running the tunnel constantly and
I'm running 2.4.7 locally.
Best regards,
--
Karol Babioch
Karol Babioch wrote:
Hi Per,
Am 05.10.19 um 10:10 schrieb Per Jessen:
I am in fact running 2.3.8. Guess I'll need an upgrade. I'd still like to know what prompted this, on 29 August.
I guess we upgraded the machine running OpenVPN on the server side to Leap 15.1 on Aug 29, which also included an update to OpenVPN itself:
Before the version we ran (and apparently didn't update for quite a while):
2017-10-27 19:30:07|install|openvpn|2.3.8-14.1|x86_64||repo-update-oss|271268eb074aa7199d88c957958c37a85f1aa03b3e28620aa09d2500673ae450|
Since August 29 we are now running:
2019-08-29 06:29:42|install|openvpn|2.4.3-lp151.4.3|x86_64||repo-oss|69ab2871d4175728a2e0eb581ebaa46c7c274aa23babd3156b7c0596614ab9b4|
Additionally a whole bunch of other packages have been touched (due to the distribution upgrade). I didn't notice anything wrong on my end, though, but on the other hand I'm not running the tunnel constantly and I'm running 2.4.7 locally.
Thanks Karol, that explains it. I just don't like such changes, without knowing what happened :-) I was unable to build the latest openvpn, so instead I patched my 2.3.8, to ignore the peer-id. Sofar it seems to have worked. /Per -- Per Jessen, Zürich (13.0°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
Per Jessen wrote:
Thanks Karol, that explains it. I just don't like such changes, without knowing what happened :-) I was unable to build the latest openvpn, so instead I patched my 2.3.8, to ignore the peer-id. Sofar it seems to have worked.
Yep, it works, problem solved. -- Per Jessen, Zürich (10.3°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: heroes+unsubscribe@opensuse.org To contact the owner, e-mail: heroes+owner@opensuse.org
participants (5)
-
Karol Babioch -
Martin Caj -
Michael Matz -
Per Jessen -
Ricardo Klein