As stated on IRC I'm fine with the support removal as one can always upgrade through VyOS 1.1.x.

Is there still time for a small CLI change?

Simply fixing the node.def for remote-port and local-port will break existing configuration as also the Perl script requires changes for this to work.

Working perfectly with VyOS acting as DMVPN HUB.

Nope, It was an offer to test a pre-build image ;).

This is part of T792

If there is an official unofficial port, ad wg distinguishes if its running in server or client mode, why not use something like:

I agree with syncer and runar.

When cisco_unity plugin is disabled globally, can Cisco DMVPN clients still connect?

• set service dhcp-server shared-network-name <xyz> authoritative enable should be changed to be only set service dhcp-server shared-network-name <xyz> authoritative
• set service dhcp-server dynamic-dns-update enable true|false should be changed to be only set service dhcp-server dynamic-dns-update
• set service dhcp-server hostfile-update enable|disable should be changed to be only set service dhcp-server hostfile-update

@Lochnair see branches at:

• https://github.com/vyos/vyatta-iproute/tree/iproute2-vyos-4.18.y
• https://github.com/vyos/vyos-kernel/tree/linux-vyos-4.18.y

It stops here, too. Why? I have no idea, yet

Upgrading to 4.18 should not take more then two hours incl. Iproute2 for me. Should we give it a try? Then I prepare an ISO

Thx for the info. Yeah it's a per person choice if in-tree is preferred over out-of-tree.

Is this stuff upstream? If so, we could also upgrade to 4.18, the save the backporting trouble?

If we'd use

range {
    start 172.16.0.1
    stop 172.16.0.250
}

this would be transparent for IPv4 and IPv6

Now using the following config, unfortunately my routers don't have that much traffic:

Could you please provide e.g. links to SRX docu/whitepapers?

Required packages should be added to this file: https://github.com/vyos/vyos-1x/blob/current/debian/control

Please put key generation as usual under run generate vpn (openvpn key generation uses the same subtree)

@begetan could you please retest?

Duplicate of T495

+1 for Constellations