I've checked the same scenario on the cisco router.

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

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

Failover is handled by my firewall which is upstream of VyOS which I am using more as a router than anything. The commit you listed I believe is actually the fix for T4206, not for this, but I can certainly try that to see if I'm up and running and to see if the issue I'm reporting here is resolved, since I have only tried this setup in 1.3.0 RC6. I'm not sure why you'd think I'd need " failover with custom hook-scripts" for this issue. All I'm trying to do is have a PBR for traffic with the destination IP of local VyOS interfaces to use the main table rather than the vrf table. I also have an issue where if I ping the IP on the FIOS WAN interface from upstream, the reply traffic from the VyOS is sent downstream to the FiOS gateway, so this fails. However, the VyOS isn't doing that for the WOW! WAN interface, and I get the replies as expected. So it seems there are strange things happening. Either things not being cleaned up and/or not being set up right.

Good question. I missed this moment.
So, if you want to reload in some minutes, VYOS offered you two variants:

1. To choose between 1 and 99
2. To set time when you want to reload VYOS if 99 minutes too short for you (for example 10:00, 12:45, 23:59, and so on)

But descriptions of thees command doesn't have enough information about it.

I've actually found a way to define this properly, resulting rule now looks like below:

tcp dport { 22 } add @FOO_30 { ip saddr limit rate over 4/minute burst 4 packets } counter packets 3 bytes 156 reject comment "FOO-30"
ct state { new } tcp dport { 22 } counter packets 5 bytes 260 return comment "FOO-40"

@adestis https://github.com/vyos/vyatta-config-mgmt/tree/equuleus

I could commit a merge request but I have not figured out in which repo the file is located.

@Viacheslav steps to reproduce:

I'm not completely sure that behavior in 1.4 is the correct one.
If I add these two routes:

vyos@vyos# set protocols static route 8.8.8.8/32 dhcp-interface eth0
vyos@vyos# set protocols static route 8.8.8.8/32 dhcp-interface eth1

I would expect to see both in main routing table, as it is in 1.3 version. I would expect that latest command doesn't overwrite previous command, as user may want/need redundancy for that particular route.
So I think that adding routes to main routing table and not overwriting previous entry is the correct behavior.
IMO in 1.3:

• Second route is added and not overwriten in main routing table -- OK
• But in vyos cli, second route overwrites the first one, when both routes should remain present in config --- Not OK

I agree with @johannrichard, having recent "change" behavior is probably going to cause some confusion.

I‘m no expert here nor extremely strong opiniated. My thoughts though: if theres no exact equivalent, why try to re-implement the recent functionality with nftables at „all“ cost?

Why is it 1-99?
If I want to reboot the router in 1500 min?

Hi again, I found another bug, if I have two policy routes with the same table it tries to create the table twice, and it doesn't work because the table is already created:

It's good to know that it works as expected on 1.4-rolling. Is it possible to get a fix for 1.3?

We didn't receive the customer's request.
The timers work without problems.
I'll open a design request to see the range 1-99.

I have emulated the same scenario in to vyos VyOS 1.4-rolling-202201041316
And it works well.
{

vyos@vyos:~$ show dhcp client leases
interface  : eth0
ip address : 172.168.32.146     [Active]
subnet mask: 255.255.255.0
domain name: localdomain        [overridden by domain-name set using CLI]
router     : 172.168.32.2
name server: 172.168.32.2
dhcp server: 172.168.32.254
lease time : 1800
last update: Fri Jan 28 01:09:31 UTC 2022
expiry     : Fri Jan 28 01:39:30 UTC 2022
reason     : RENEW

Good to hear, going to mark this as resolved.

Hi,
I applied your new policy-route.py manually, and now my ipv6 pbr works again!! Thanks a lot!

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

In T4209#117579, @thomasjsn wrote:

In T4209#117429, @sdev wrote:

Would changing the guide to use limit rate 4/minute achieve the same target functionality?

What is the practical difference between limit rate and recent? Is it just two different ways of accomplishing the same?

In T4209#117429, @sdev wrote:

Would changing the guide to use limit rate 4/minute achieve the same target functionality?

I've come up with a working idea how to implement but would like feedback before submitting a PR.

Thanks for the report, I believe I know what's caused it to break. Hopefully will have a fix in for the build tomorrow.

I'm looking into it. I'm going to add a test with multiple commits. Good catch, I didn't test this. :)

@johannrichard Hey sorry I didn't see your comment, I suggest we move the discussion to the dedicated task: https://phabricator.vyos.net/T4209

This was included with the new firewall, going to mark as resolved.

The new firewall niw has no such restrictions on port definitions, going to close this as resolved.

This is now implemented in 1.4

Should be fixed now with https://github.com/vyos/vyos-1x/pull/1193

Above fixed in PR: https://github.com/vyos/vyos-1x/pull/1193

With nftables, this should in principle be possible with nested variables, and the firewall groups are based on these now.

We confirmed the problem - some serial consoles continue to work well, some are not initialized properly with the --keep-baud option. For example, this can be reproduced in the SOS console in Equinix Metal.
Originally, the problem comes from a systemd service template.
Since it is not completely clear if the option is necessary in one case or another, it seems that the best solution would be to provide the ability to set/remove it from the CLI, so everyone may configure what works best for his hardware.

Incorrect behavior with multiple commits
Configuration:

set policy local-route rule 10 set table '101'
set policy local-route rule 10 source '192.0.2.1'
set policy local-route rule 10 source '192.0.2.2'
commit
set policy local-route rule 10 destination '203.0.113.25'
commit

Expected rules:

10:	from 192.0.2.1 to 203.0.113.25 lookup 101
10:	from 192.0.2.2 to 203.0.113.25 lookup 101

Getting rules:

10:	from 192.0.2.2 lookup 101
10:	from 192.0.2.1 to 203.0.113.25 lookup 101
10:	from 192.0.2.2 to 203.0.113.25 lookup 101

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

As reproducing the exact issue seems to be difficult, I'm going to instead change the install function so it catches errors and outputs the set pki ... syntax so it behaves like generate pki ... install <name> is run from op-mode anyway.

Actually.. re-testing now I'm also unable to reproduce this. I would guess it was some sort of environmental bug. This time I have ensured that I am using the exact input parameters I was using before and am also in conf mode but it just works. I would say let's close this issue for now and if I run into this again I'll double check the reproducability and ask to reopen this issue.

@sdev You are spot on. I did run it with "run" in conf mode (sorry for editing that out :). But it does bungle it in conf mode on VyOS 1.4-rolling-202201240317 with a non 'vyos' user. Maybe that (the non-vyos user) is what is tripping it up.

This issue is due to negated source/destination port not being handled properly in code, not validation.

It looks like it’s trying to directly install the certificate into the config from op-mode, that is only supposed to happen while you're in configure mode calling the command using run generate pki ... install <name>.

Important to note that simply running the failing set command (pki certificate v.my.domain certificate <base64-cert-here>) in config mode works fine.