Above fixed in PR: https://github.com/vyos/vyos-1x/pull/1193
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jan 27 2022
With nftables, this should in principle be possible with nested variables, and the firewall groups are based on these now.
Jan 26 2022
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
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.
Jan 25 2022
Is it the same task T4138 ?
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?
@sdev Thanks
Jan 24 2022
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.
Jan 23 2022
@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
Jan 22 2022
Error still present on VyOS 1.4-rolling-202201180317
Wildcard + should be replaces with *, according to nft man page:
@hensur See PR, I implemented a merge script and provided three solutions.
Jan 21 2022
Confirmed, I just built a new image using 1.4-rolling-202201212148 and I can no longer reproduce the issue.
PR + migration: https://github.com/vyos/vyos-1x/pull/1184
In T4199#117215, @n.fort wrote:
Loading address group described in task and then printing, works OK.
Tested on VyOS 1.4-rolling-202201180317 and working as expected.
Seems solved, Not reproducible on VyOS 1.4-rolling-202201180317
Did did work as expeced
vyos@vyos# run show config comm | grep fire set firewall ipv6-name FOO rule 10 action 'accept' set firewall ipv6-name FOO rule 10 icmpv6 type 'echo-request' set firewall ipv6-name FOO rule 10 protocol 'ipv6-icmp'
Also, while matching parameters valid in nftables, such as echo-reply, commit fails too:
Should be fixed with https://github.com/vyos/vyos-1x/pull/1183
Bug related: https://phabricator.vyos.net/T4186
I can't reproduce this issue on latest rolling
I'm looking into it. From the logs it seems like for src in (pbr[rule_rm][rule]['source'] or ['']) doesn't work if 'source' doesn't exist.
@hensur Smoketest failed.
(VyOS 1.4-rolling-202201200814) - The same.
I ve testet it on (Version:VyOS 1.4-rolling-202201200814). It seems well.
I ve tested this scenario on VyOS 1.4-rolling-202201200814, as said Srividya you can choose minutes betwen 1-99.
If this is critical, you can expand the range by opening a "feature request".
Jan 20 2022
Seems to have fixed it