Thanks - works again

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

Adding this issue to this task: https://forum.vyos.io/t/firewall-configuration-issue-after-upgrade/8414

PR https://github.com/vyos/vyos-1x/pull/1200
Fix for telegraf template/scripts for services.

I've used for these tests (VyOS 1.4-rolling-202202010836)
The same situation in general when you want to use "!".
Bad exampels.

set nat source rule 10 destination port !1-5
set nat source rule 10 destination port !22
set nat source rule 10 destination port !http
set nat source rule 10 destination port telnet,!http,!123,1001-1005
set nat source rule 10 destination port telnet,http,!123,1001-1005

( VyOS 1.4-rolling-202202010836)- Rule name which starts with a number work well.

docs: https://github.com/vyos/vyos-documentation/pull/707

I have found the following links:

tested my previous code in latest rolling, looking good so far.
no errors on commiting.

Is there any Linux implementation?

reverted broken commit

reverted commit

Confirm
VyOS 1.4-rolling-202201291849

My hunch would be that this is the breaking commit, given the context:

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

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

The same situation if you set the number or special symbol.

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

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

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"

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:

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.

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.

Is it the same task T4138 ?

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

I had forgotten about the recent syntax and it was merged in a broken state (https://github.com/vyos/vyos-1x/blob/current/python/vyos/firewall.py#L164). We should try and find a remedy, or remove it from CLI.

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

set policy prefix-list TST_PRF_LST rule 10 action 'permit'
set policy prefix-list TST_PRF_LST rule 10 prefix '10.5.5.0/24'
set policy prefix-list TST_PRF_LST rule 20 action 'permit'
set policy prefix-list TST_PRF_LST rule 20 prefix '10.6.6.0/24'
set policy prefix-list TST_PRF_LST rule 30 action 'permit'
set policy prefix-list TST_PRF_LST rule 30 prefix '10.6.6.0/24'