OpenVPN configuration fails if it depends on another interface.
Needs reporter action, NormalPublic
Actions

Assigned To

None

Authored By

	mb300sd
	Mar 26 2019, 8:29 PM

Description

I have an OpenVPN L2 bridge that fails to come up on reboot because it depends on an IPSec tunnel. The configuration works if I log in and do a configure, load, commit.

Relevant config parts,

openvpn vtun1 {
    bridge-group {
        bridge "br0"
        cost "100"
    }
    description "LAN_TVBox Tunnel"
    device-type "tap"
    local-host "10.255.2.1"
    local-port "1194"
    mode "site-to-site"
    openvpn-option "fragment 1392"
    openvpn-option "mssfix"
    openvpn-option "auth none"
    openvpn-option "cipher none"
    persistent-tunnel { }
    remote-host "10.255.2.0"
    shared-secret-key-file "/config/auth/ovpn/tvbridge.key"
}

vti vti1 {
    address "10.255.2.1/31"
    description "TUN_******"
    mtu "1426"
    traffic-policy {
        out "PRIO_OUT"
    }
}

Details

Version: 1.2.0-rolling+201903200337
Is it a breaking change?: Unspecified (possibly destroys the router)

Related Objects

Mentioned Here: T4230: OpenVPN server configuration deleted after reboot when using a VRRP virtual-address

Event Timeline

mb300sd created this task.Mar 26 2019, 8:29 PM

mb300sd created this object in space S1 VyOS Public.

Probably not the most common config, but I already have IPSec tunnels between all my sites, but need the L2 bridge and ovpn's fragmentation for my TV STB to function correctly through a tunnel. Perhaps adding a depends-on-interface option to all interfaces would be the most generic way to resolve this. I will try and see how difficult this is to implement in the config scripts when I have some time in the next week or 2.

I switched to a L2TPv3 tunnel for better performance than OpenVPN, still will not come up at boot if it depends on the vti interface.

You can try playing around with the priority in the l2tpv3 node.def files. Higher priority means its executer later. DHCP for instance uses 900-something.

Check that your prio is higher then the one in the VTI interface

That worked, thanks. Had to set it to 901, the vpn node was 900. Added a sed to the preconfig script so it survives updates.

Also solved my igmp-proxy issue! Already wrote a post-config reset for that one a long time ago.

Could you tell us the exact modifications? Or even better - send a Pull Request via GutHub so we could include it into VyOS.

Not sure if the l2tp/vti modification merits inclusion - that depends on personal configuration of which tunnel is inside the other. I think the original config is correct for the more common use case of having l2tp secured by ipsec.

I can't think of any reason not to make igmp-proxy start later though, but what would the most universal value be? I set mine to 902 since the l2tp tunnel was changed to 901, but perhaps it should start even later than dhcp, to make sure all addresses are assigned to the system prior.

syncer changed the task status from Open to In progress.Mar 28 2019, 10:58 PM

syncer triaged this task as Normal priority.

syncer edited projects, added VyOS 1.3 Equuleus; removed VyOS 1.2 Crux.

pasik subscribed.Mar 30 2019, 10:59 AM

OpenVPN was migrated to a systemd service with auto restart so it's possible it could have fixed this issue. Please retest with latest rolling.

dmbaturin added a project: test.Jul 29 2021, 12:21 PM

dmbaturin set Is it a breaking change? to Unspecified (possibly destroys the router).

syncer edited projects, added VyOS 1.3 Equuleus (1.3.0); removed VyOS 1.3 Equuleus.Nov 6 2021, 11:25 AM

It can be fixed in thoses PR's:
https://github.com/vyos/vyos-1x/pull/1210
https://github.com/vyos/vyos-1x/pull/1211
T4230