vpn interfaces loose IPv4 addresses

[archimede]

Hi.

I run a Linux router with 2 interfaces, one towards the WAN, connected to an ISP modem, and one towards the LAN (192.168.69.1/24)

On the machine I have three VPN instances running, one is a server and two are clients, all of them are TUN devices.

It all works well, except that every now and then, the VPN interfaces loose the inet address and stop working. It can happen after a few hours or several days, but when it happens, all 3 instance simultaneously are affected.

When everything is working, in addition to the regular WAN and LAN interfaces, the command ip a reports:

Code: Select all

15: vpn-crypto: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none
    inet 10.33.111.138/16 brd 10.33.255.255 scope global vpn-crypto
       valid_lft forever preferred_lft forever
    inet6 fe80::8108:2a89:6c0e:d279/64 scope link flags 800
       valid_lft forever preferred_lft forever
16: vpn-octane: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none
    inet 10.10.2.6 peer 10.10.2.5/32 scope global vpn-octane
       valid_lft forever preferred_lft forever
    inet6 fe80::267a:29c1:9742:6d3b/64 scope link flags 800
       valid_lft forever preferred_lft forever
17: vpn-bpir1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none
    inet 192.168.68.1 peer 192.168.68.2/32 scope global vpn-bpir1
       valid_lft forever preferred_lft forever
    inet6 fe80::7f14:b82a:5a20:d644/64 scope link flags 800
       valid_lft forever preferred_lft forever

When things stop working, the command ip a reports that there are no more inet addresses:

Code: Select all

11: vpn-bpir1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none
    inet6 fe80::1af0:d1c:7398:2dd4/64 scope link flags 800
       valid_lft forever preferred_lft forever
12: vpn-octane: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none
    inet6 fe80::f295:3173:cf41:b4fc/64 scope link flags 800
       valid_lft forever preferred_lft forever
14: vpn-crypto: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 100
    link/none
    inet6 fe80::2e45:fd07:abf9:85d2/64 scope link flags 800
       valid_lft forever preferred_lft forever

All routes related to the VPN have also disappeared from the routing tables.

The logs do not show any anomalous or related message.

- Any idea what could be causing this?

- Any idea of any workaround I can put in place to fix it?

Thanks!

[TinCanTech]

Sounds like a DHCP refresh from your ISP ..

[archimede]

Thanks TinCanTech,

I am monitoring my external IP, which is unchanged. It only changes every 40 days. Is it possible however that there is a renew all, which then confirms the same address?

Recently the problem it is happening more frequently, even every hour.

Any suggested workaround or diagnostic technique?

Recently I enabled --up-restart, but the up and down script arte not triggered when this problem happens.

Thanks

[archimede]

I found a connection between this problem and systemd-networkd. Using openvpn tun interfaces cause systemd-networkd to crash, which then remove the IPV4 addresses from the interfaces.
Details are here:
https://github.com/systemd/systemd/issues/3565

[TinCanTech]

Thanks for the update .. hopefully openvpn devs are looking into this.

[cron2]

This is not an openvpn issue. If systemd-networkd crashes, systemd-networkd needs to be fixed - a system process MUST NOT crash, ever (except under exceptional circumstances, like, "hardware broken" or "machine seriously out of RAM").