I'm not a regular poster to this forum, but felt this report might save someone the week I spent figuring it out. I have a raspberry pi 4b with a newly installed version of bookworm (using the raspberry installer). I have made very few changes to the OS, very vanilla. After the install, I set networking using nmtui, with a static IP (not a reserved dhcp IP, but an old-fashioned static IP.) ipv4 network only. I then set up my VPN service, one I have used for at least 2 years, with my pi a client for an openvpn server (commercial service). This config was very stable on buster. I used the default bookworm openvpn package, (2.6.3-1-deb12u2), installed from the bookworm repository with apt. With buster, I also had a static IP, same commercial service, and the buster default openvpn version, 2.4.7.1-deb10u1_arm64.deb. I used the same openvpn configuration file, other than a minor change (deleted ncp-disable, deprecated in the new version of openvpn). I ran openvpn from the command line, as I did on buster. Result: the VPN connected successfully, I got assigned an IP, and could connect via the VPN to external servers as usual. BUT... the connection restarted after 2-5 minutes of operation, continually.
The restart is always the same, and appears server initiated:
The first critical message when the restart occurs is always like this:
[server] inactivity timeout (--ping-restart), restarting
my client then responds with
SIGUSR1[soft,ping-restart] received, process restarting
I tried many configuration file changes. I uninstalled the bookwork 2.6.3 openvpn and replaced it with the same 2.4.7.1 openvpn that worked previously on buster (got the old version from the debian source repository). The old version, running on my current bookworm, behaved identically to the 2.6.3 version: I could establish a VPN, get an address, use the VPN.... and after a few minutes I'd get a VPN restart with the message above.
To cut this short, I changed from a static network address to dhcp... and the problem is gone. The VPN stays up indefinitely, whether I use the new 2.6.3 or the old 2.4.7.1. It appears a static IP on bookworm gives openvpn restart errors, apparently some incompatability with server keepalive expectations. Somehow the timing for static networking on bookworm is different from dhcp. This is not the case with older versions of raspbian (at least buster), where static IP works fine with openvpn.
Not going to speculate on root cause, but thought this behavior was worth reporting. Its unfortunate IMO if debian network evolution is leading to differences between static and dynamic IP timing. (Or whatever the root cause here is, I'm not pretending to be the expert). In any event, apparently some network applications may work differently depending on your choice of static or dynamic IPv4 addressing.
The restart is always the same, and appears server initiated:
The first critical message when the restart occurs is always like this:
[server] inactivity timeout (--ping-restart), restarting
my client then responds with
SIGUSR1[soft,ping-restart] received, process restarting
I tried many configuration file changes. I uninstalled the bookwork 2.6.3 openvpn and replaced it with the same 2.4.7.1 openvpn that worked previously on buster (got the old version from the debian source repository). The old version, running on my current bookworm, behaved identically to the 2.6.3 version: I could establish a VPN, get an address, use the VPN.... and after a few minutes I'd get a VPN restart with the message above.
To cut this short, I changed from a static network address to dhcp... and the problem is gone. The VPN stays up indefinitely, whether I use the new 2.6.3 or the old 2.4.7.1. It appears a static IP on bookworm gives openvpn restart errors, apparently some incompatability with server keepalive expectations. Somehow the timing for static networking on bookworm is different from dhcp. This is not the case with older versions of raspbian (at least buster), where static IP works fine with openvpn.
Not going to speculate on root cause, but thought this behavior was worth reporting. Its unfortunate IMO if debian network evolution is leading to differences between static and dynamic IP timing. (Or whatever the root cause here is, I'm not pretending to be the expert). In any event, apparently some network applications may work differently depending on your choice of static or dynamic IPv4 addressing.
Statistics: Posted by fern-jim — Tue Jan 30, 2024 5:44 am — Replies 0 — Views 77