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'

Try to dump traffic from the required interface

For first do these changes as in commit
Try policy local route, for example:

set policy local-route rule 10 set table 111
set policy local-route rule 10 source 192.0.2.0/24

The main reason:

@Rhongomiant Am I understanding correctly that you don't see the default route in table 111?

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

@sdev Thanks

Task already implemented:

PR current - https://github.com/vyos/vyos-build/pull/214
PR equuleus - https://github.com/vyos/vyos-build/pull/215

PR for 1.3:
https://github.com/vyos/vyos-1x/pull/1187

@artooro It still accepts type-name.

@n.fort I just built a fresh image and tested. The first thing I noticed is that icmpv6 now only accepts integers while previously it accepted names. I'm assuming this is a purposeful design change where users now have to set type-name instead.
The any option has been removed, which I suspect is OK as you'd simply leave it unset if you want to accept all icmp types.
Overall this should eliminate the user confusion so I think it's a good change.

Tested on VyOS 1.4-rolling-202201230317

@artooro , please try again using latest version -> vyos-1.4-rolling-202201230317-amd64.iso
Just tested, and for me, it's working as expected.
PR that solves this issue: https://github.com/vyos/vyos-1x/pull/1184

On VyOS 1.4-rolling-202201230317.
Commands:

Tested on latest VyOS 1.4-rolling-202201230317

Error still present on VyOS 1.4-rolling-202201180317

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

Wildcard + should be replaces with *, according to nft man page: