For RPS, we maybe can adapt https://github.com/bhuanand/rps-rfs-configuration to VyOS?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jun 27 2021
Jun 26 2021
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.
Jun 25 2021
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.
Jun 24 2021
@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).
Jun 23 2021
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.
@Harliff Try 1.2.7/1.3 it was fixed with commit https://github.com/vyos/vyos-build/pull/138/files#diff-c7d29a506307d9cf8d86c3cd3f65ca4e4058ea442cacdf9a89d2485b56c7417aR67
T2061
@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.
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.
I've not checked later versions. Maybe it was already fixed on 1.2.7 or 1.3/1.4 ?
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
In T3638#96831, @Viacheslav wrote:Try to set single quotes.
Jun 22 2021
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
@SrividyaA Fixed in PR https://github.com/vyos/vyos-1x/pull/894
Jun 21 2021
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 :