Hi ruben

PR https://github.com/vyos/vyos-1x/pull/902
PR https://github.com/vyos/vyos-documentation/pull/561

It seems that what I thought is true:

could this help https://patchwork.ozlabs.org/project/netfilter-devel/patch/776b8819c85c83088478b933a35691133055347a.1430733932.git.daniel@iogearbox.net ?

as I wrote on slack, from my point of view it is a kernel problem. It seems that the conntrack in the kernel detects the packets eben if they come in on an input interface in default and so
the nat code won'T match cause for conntrack the outgoing interface is still eth0 which is in vrf OOBM instead pppoe0.

Hi ruben,

Should I hold out any hope for this to be implemented? Still willing to help test and do whatever I can to get this in.

For 1.2.7 it adds unexpected multicast group per "save"
Configs for reproduce:

To reproduce (VyOS 1.3-beta-202106271614):

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.

Hi, any updates on this?

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?

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

@Dmitry Is it an actual task? Code was rewritten.

Already fixed with "no_tag_node_value_mangle=True"
https://github.com/vyos/vyos-1x/blob/705eddbc7a2caf09c37ecafb27418a764217975a/python/vyos/config.py#L218

Eigrp in the FRR doesn't work correctly.
The routes still live even if neighbors in a shutdown state.

@Cheeze_It can you re-check it?

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

Not sure about double quotes, but for example for cloud-init configs, it is necessary to use single quotes.
Ideally, the configuration should look like in show configuration commands

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.

@MaxiM In which exact version was a different behavior?

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.

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

In T3638#96831, @Viacheslav wrote:

Try to set single quotes.

yes, I am using the following version :

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

@SquirePug Can you check 1.2.7 release?

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.

Try to set single quotes.

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:~$

Confirmed that's what is happening:

vyos@cr01a-vyos# TEST='variable'
[edit]
vyos@cr01a-vyos# set system login user vyos authentication plaintext-password HqNzXaK27k19$TEST
[edit]
vyos@cr01a-vyos# comp
[edit system login user vyos authentication]
+plaintext-password HqNzXaK27k19variable

@fernando Are you sure you're testing this on 1.3?

vyos@cr01a-vyos# run show ver

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

I 've been checking this behavior with a different password , also I used the same password as you . But I couldn't reproduce the issue , both cases i add $ in the word and change the hash, let me show :

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>]...] ]...

In T3640#96759, @Viacheslav wrote:

Is it helps in your case?

set interfaces wireguard wg0 disable 
commit
del interfaces wireguard wg0 disable 
commit

There is no any native command for reset wireguard interface in Linux (as I know). Also, we don't use any daemons which we can restart to "re-establish" session.
Is one host behind nat?

Is it helps in your case?

set interfaces wireguard wg0 disable 
commit
del interfaces wireguard wg0 disable 
commit

There is no any native command for reset wireguard interface in Linux (as I know). Also, we don't use any daemons which we can restart to "re-establish" session.
Is one host behind nat?