Your message dated Fri, 12 Aug 2022 10:58:53 +0200
with message-id <yvywtaqtr49yd...@fliwatuet.svr02.mucip.net>
and subject line Re: Bug#923998: openvpn: Openvpn tun0 loses IP and route
has caused the Debian Bug report #923998,
regarding openvpn: Openvpn tun0 loses IP and route
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
923998: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923998
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: openvpn
Version: 2.4.7-1
Severity: normal

Dear Maintainer,

My OpenVPN client setup just stopped working, maybe/likely linked to a recent
update of Debian (testing).

The end result is that the openvpn daemon looks happy and gives me the right
syslog messages, yet the interface gets no IP address (and no routes either, of
course):

    # ifconfig tun0
    tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
            inet6 fe80::e580:a6b8:6f2:dd5  prefixlen 64  scopeid 0x20<link>
            unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen
100  (UNSPEC)
            RX packets 0  bytes 0 (0.0 B)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 7  bytes 336 (336.0 B)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

The syslog includes the expected lines such as:

    Jan 25 11:12:41 ceviche ovpn-foo[9570]: /sbin/ip addr add dev tun0
NN.MM.OO.PP/24 broadcast NN.MM.OO.255
    Jan 25 11:12:41 ceviche ovpn-foo[9570]: /sbin/ip route add HOSTIP1/32 via
NN.MM.OO.1

and if I run these lines by hand, then things go back to working (until the VPN
is restarted, obviously).

So my impression is that the interface is setup correctly but is later "undone"
by some external thing.  This impression comes from some suspicious extra
messages mentioning `tun0` that appear a bit further in the log:

    Jan 25 11:12:41 ceviche systemd[1]: Unnecessary job for
/sys/subsystem/net/devices/tun0 was removed.
    Jan 25 11:12:41 ceviche systemd[1]: Started Netscript ifup for tun0.
    [...]
    Jan 25 11:12:41 ceviche sh[9617]: Configuring interface: tun0.

Any idea what might be going on, how to track it down, or how to fix it?

This is a Debian testing system that's been following Debian testing for many
years.



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.19.0-1-686-pae (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CH.UTF-8, LC_CTYPE=fr_CH.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CH.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  iproute2               4.20.0-2
ii  libc6                  2.28-7
ii  liblz4-1               1.8.3-1
ii  liblzo2-2              2.10-0.1
ii  libpam0g               1.3.1-5
ii  libpkcs11-helper1      1.25.1-1
ii  libssl1.1              1.1.1a-1
ii  libsystemd0            241-1
ii  lsb-base               10.2018112800

Versions of packages openvpn recommends:
pn  easy-rsa  <none>

Versions of packages openvpn suggests:
ii  openssl                   1.1.1a-1
pn  openvpn-systemd-resolved  <none>
ii  resolvconf                1.79

-- Configuration Files:
/etc/default/openvpn changed [not included]

-- debconf information:
  openvpn/vulnerable_prng:
  openvpn/create_tun: false

--- End Message ---
--- Begin Message ---
On 02/03/21 10:13 AM, Stefan Monnier wrote:

> > One of our VPN users encountered the same issue on Ubuntu 20.04, which lead
> > us to investigate this. The cause of this issue is netscript-2.4[1], a 
> > rather
> > old and obscure alternative ifup/ifdown implementation. In its default 
> > configuration a netscript systemd service instance is automatically started
> > shortly after the OpenVPN tunnel interface is created:
> 
> Indeed, I also discovered that the problem disappeared when I removed
> the `netscript` package (not sure why it was installed).
> Thanks,

Thanks, closing the bug.

Bernhard

--- End Message ---

Reply via email to