Can you please include the VyOS config?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Mon, Sep 2
Jun 27 2024
Apr 26 2024
Apr 25 2024
Possibly would make sense for CLI to fall under firewall global-options?
Apr 15 2024
Apr 7 2024
Mar 28 2024
Updated PR to use multi nodes: https://github.com/vyos/vyos-1x/pull/3202
Mar 20 2024
This likely because the global state policy being reintroduced was not accounted for in the firewall check in conf script. I'll check this week.
Mar 12 2024
Interfaces aren't added on boot because mac address is locally administered: https://github.com/vyos/vyos-1x/blob/current/src/helpers/vyos-interface-rescan.py#L60
Mar 11 2024
Pretty sure this is the offending migrator. I briefly discussed this with @c-po
Mar 7 2024
Mar 6 2024
Feb 28 2024
Firewall failed migration due to incorrect subnet, 1.3 firewall did not correctly validate those fields. Correcting source address on rule 30 on TO-ROUTER chain should migrate the firewall properly.
Feb 27 2024
Not a regression as far as this task is concerned. Will update T6073
Feb 26 2024
Feb 25 2024
Feb 24 2024
Feb 23 2024
Glad to hear it @svd135 @swanduron
@svd135 can you try on latest rolling?
Feb 21 2024
Feb 20 2024
Feb 14 2024
Feb 13 2024
Not an issue on 1.5 with Kea.
Feb 12 2024
This does seem to be new behaviour introduced with Kea. ISC dhcpd did previously assume local distribution of a subnet based on the interface having an address within the subnet, Kea has changed to require this being explicitly defined.
Jan 27 2024
Jan 23 2024
Jan 21 2024
In T5835#172989, @dylanneild wrote:@sdev Quick question on this issue.
In order to make miniupnpd work with the VyOS firewall as it is presently configured (dedicated ip and ip6 tables), I've had to make a fork of miniupnpd. This is due to the miniupnpd folks effectively declaring that inet tables are "the way it's all going" and effectively removing any ip and ip6 table use in the daemon.
I've tested with the stock miniupnpd to try to implement all rules in a single inet chain, but this creates a problem where, per my comment above, the default-action drop steps on the miniupnpd table, and I'm back to square one.
Using my fork of miniupnpd, I've tested extensively and can see everything working with VyOS IPv4. Rules can be added, checked, and removed without issue. Secure mode works, etc. The fork itself is a fairly small patch; it just reverts some calls in the nftables code to use NFTPROTO_IPV4 rather than NFPROTO_INET for filter and NAT rule changes so as to target the correct table variants.
I can test IPv6 pinhole, which I think can still work using the ip6 tables as-is (my patch doesn't change this at all), but I'd have to setup some tunnelling to validate it as I don't have native IPv6 at my house.
So, my question is: how open is VyOS to using forks of packages as opposed to just pulling them in from Debian?
If not at all, this patch may be at a dead-end unless someone has a clean way to avoid the default-action drop using only priorities (the nftables documentation maintains this can't work)? I considered using meta marking but that would also involve patching miniupnpd to apply the marks to rules matched by it's firewall additions and then modifying VyOS to not apply the default drop when the mark is matched; but that seems a lot less clean.
Jan 17 2024
Sounds like a great solution to me, happy to review your PR.
Jan 12 2024
During a boot that raises the migration error, can you alter the grub boot command to add vyos-config-debug? See https://docs.vyos.io/en/latest/contributing/debugging.html#kernel
Jan 11 2024
Jan 10 2024
Closing this as resolved, please re-open if any further issues found.