Bug confirmed and fixed,

I should soon have a PR ready for this, including an update to IPSec config to show how to port existing configs to use PKI.

I like the design!

In T3657#97243, @c-po wrote:

I wonder why you use ebgp multihop wirh link local addresses?

I used it only for testing (but this command increment ttl in two).

even if FRR manual states the deprecation notice, we have our own layer of abstraction and will deal with it once it is required.
For the time beeing, I just checked the commands (using tab completion).

In T3657#97243, @c-po wrote:

Also FRR manual states:

When you connect to a BGP peer over an IPv6 link-local address, you have to specify the IFNAME of the interface used for the connection. T

Please try set protocols bgp neighbor <addr> interface eth1

I wonder why you use ebgp multihop wirh link local addresses?

Verified working in GNS3 on 1.3.0-rc4. Note that /var/lib/dhcpv6/dhcp6c_duid is not used if send client-id is configured.

Parent Task: https://phabricator.vyos.net/T2816

I add an extra commentary , it is config on FRR:

I have tried one more scenario:

Doesn't work, VyOS 1.4-rolling-202106271939

What would be the "full set" up supported characters? If I remember correctly this regex is inherited from VyOS 1.1

For RPS, we maybe can adapt https://github.com/bhuanand/rps-rfs-configuration to VyOS?

When using show pki ... commands you would be able to see the relation between certificates and CAs.

THis is infact only relevant when IPv6 addressing is used.

PR: https://github.com/vyos/vyos-1x/pull/899

I ver much like this idea. Certificates can then easily be migrated from device to device, and very easy be referenced in a service.

Sorry, this may be my fault. It seems that I only pay attention to modifying the identifier below and forget the top definition. Sorry.

PR https://github.com/vyos/vyos-1x/pull/898

There is a link to the existing code for configuration mode, not pr.
So we can to add the op-mode function to re-add/reset with a similar logic. Only thoughts

Not working for me as expected in 1.3.0-rc4
In my current working configuration, the duid is in the /var/lib/dhcpv6/dhcp6c_duid file (29 bytes).

In T3640#96973, @Viacheslav wrote:

I think it will be enough to remove the peer and add again.
@hagbard what do you think?
https://github.com/vyos/vyos-1x/blob/d48dddab0509e562209adfb115b0e691b8e47f54/python/vyos/ifconfig/wireguard.py#L197

I think it will be enough to remove the peer and add again.
@hagbard what do you think?
https://github.com/vyos/vyos-1x/blob/d48dddab0509e562209adfb115b0e691b8e47f54/python/vyos/ifconfig/wireguard.py#L197

PR https://github.com/vyos/vyos-1x/pull/897
Fix path for swanctl.conf file

In T3640#96937, @hagbard wrote:

Wireguard has no link states on the interface, the ip command just does an 'administrative' up down, which won't start a renegotiation. The policy description (remove peer) needs to be removed from the wg interface and re-added, otherwise you need to wait until wg tries to rekey which will then eventually renegotiate the entire connection.
The removal was as far as I recall part of the original vyos code, so it may have been removed at one point, I haven't looked into the code yet.

For NAT, try setting persistent-keepalive, that is supposed to keep the NAT entry active, even if you have no traffic for the tunnel.

Wireguard has no link states on the interface, the ip command just does an 'administrative' up down, which won't start a renegotiation. The policy description (remove peer) needs to be removed from the wg interface and re-added, otherwise you need to wait until wg tries to rekey which will then eventually renegotiate the entire connection.
The removal was as far as I recall part of the original vyos code, so it may have been removed at one point, I haven't looked into the code yet.

Actually scratch that. I run a HA pair of VyOS routers via VRRP with a transition script on master/backup, and it looks like when it transitions from backup to master, the commit (at the end of the script) still locks in an endless cycle, combined with some sort of memory leak in keepalived-fifo.py (that doesn't occur if commit-archive via scp is not set up).

Looks fine on boot now.

Now that the Paramiko and Cryptography versions have been updated, does this problem persist with the newer nightlies? @SrividyaA @FileGo

Done with generate public-key-command. loadkey is deprecated and will be removed in a future version.

In T3640#96876, @c-po wrote:

If your host is behind NAT, could it possibly be that the NAT translation entry expired?

Does the following work:

ip link set dev wg0 down; ip link set dev wg0 up

If your host is behind NAT, could it possibly be that the NAT translation entry expired?

In T3640#96771, @Viacheslav wrote:

We don't use any configuration file for it, so I think we can't use wg-quick
We use "wg set"

$ sudo wg set --help
Usage: wg set <interface> [listen-port <port>] [fwmark <mark>] [private-key <file path>] [peer <base64 public key> [remove] [preshared-key <file path>] [endpoint <ip>:<port>] [persistent-keepalive <interval seconds>] [allowed-ips <ip1>/<cidr1>[,<ip2>/<cidr2>]...] ]...

I don't see the reason to delete the "disable" option, as it uses for adjust-mss and adjust-mss6.
And you need temporarily disable it.

PR https://github.com/vyos/vyos-1x/pull/895

Different format

vyos@r1-roll:~$ show vpn ipsec sa
Connection                State    Uptime    Bytes In/Out    Packets In/Out    Remote address    Remote ID    Proposal
------------------------  -------  --------  --------------  ----------------  ----------------  -----------  ----------
peer_192-0-2-2_tunnel_1   down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_10  down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_11  down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_12  down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_13  down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_14  down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_15  down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_16  down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_17  down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_18  down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_19  down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_2   down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_20  down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_3   down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_4   down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_5   down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_6   down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_7   down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_8   down     N/A       N/A             N/A               N/A               N/A          N/A
peer_192-0-2-2_tunnel_9   down     N/A       N/A             N/A               N/A               N/A          N/A
vyos@r1-roll:~$

@SrividyaA Fixed in PR https://github.com/vyos/vyos-1x/pull/894