http://bugzilla.opensuse.org/show_bug.cgi?id=914166 Geoff Kuenning changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #1 from Geoff Kuenning --- I dd a zypper patch/zypper update a few days ago, and since then I haven't seen the problem. So I'm going to close this as WORKSFORME. I'll reopen it if the problem reappears. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=914166 Cornelius Mahlo changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |c.mahlo@gmx.net --- Comment #3 from Cornelius Mahlo --- Hello – I can confirm the issue. This is a pure openvpn problem. Based on a standard configuration, openvpn downgrades privileges (to user nobody and group nobody) after initialization. The commands to close/ reopen the tunnel device fail, due to a lack of permissions. Root cause: 2015-01-21T11:09:37.001976-08:00 bow openvpn[3997]: Preserving previous TUN/TAP instance: tun0 2015-01-21T11:09:37.002355-08:00 bow openvpn[3997]: NOTE: Pulled options changed on restart, will need to close and reopen TUN/TAP device. Openvpn thinks it needs to reopen the tunnel device, because pulled options have changed – after every SIGUSR1 (soft restart) signal (we assume they have not)! Changes are determined by a checksum calculation and comparison. Code debugging shows that function sha1_digest_equal() in "init.c" fails. The problem is caused by openvpn-fips140-2.3.2.patch – unfortunately it is incomplete. Checksum calculation is changed from MD5 to SHA1, but now we try to compare SHA_DIGEST_LENGTH (20) bytes on two MD5_DIGEST_LENGTH (16) bytes fields. I would doubt it has ever worked (or by padding/ memory accident). For maintenance team - Please change/ patch file “src/openvpn/crypto.h”: - uint8_t digest [MD5_DIGEST_LENGTH]; + uint8_t digest [SHA_DIGEST_LENGTH]; Based on the openvpn-2.3.4 source and applied patches, I created and tested a new openvpn build locally. The function sha1_digest_equal() works now as expected and the previous tunnel instance is preserved (assuming unchanged pulled options). Can someone confirm this? I would be happy to get an online update for this bug. As a first workaround, you could keep root privileges for openvpn after initialization (comment out/ remove “user nobody” and “group nobody” from client configuration). Please note that openvpn now keeps running, but the tunnel device will continue to close/ reopen. Processes which depend on a persistent tunnel will still fail. -- You are receiving this mail because: You are on the CC list for the bug.