-
Notifications
You must be signed in to change notification settings - Fork 571
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
firewall ruleset with sequential port list results in blocked port #9009
Comments
Zempashi
changed the title
firewall ruleset with sequential port list result in blocked port
firewall ruleset with sequential port list results in blocked port
Jul 12, 2024
Thank you for reporting this. |
I believe the key problem here is the adjacent ports not being merged correctly when building an interval set, which leads to the match failure. |
smira
added a commit
to smira/talos
that referenced
this issue
Aug 5, 2024
Fixes siderolabs#9009 When building a port interval set, sort the ports and merge adjacent ranges to prevent mismatch on the nftables side. With address sets, this was already the case due to the way IPRange builder works, but ports need a manual implementation. Signed-off-by: Andrey Smirnov <andrey.smirnov@siderolabs.com> (cherry picked from commit f14c479)
smira
added a commit
to smira/talos
that referenced
this issue
Aug 6, 2024
Fixes siderolabs#9009 When building a port interval set, sort the ports and merge adjacent ranges to prevent mismatch on the nftables side. With address sets, this was already the case due to the way IPRange builder works, but ports need a manual implementation. Signed-off-by: Andrey Smirnov <andrey.smirnov@siderolabs.com> (cherry picked from commit f14c479)
smira
added a commit
to smira/talos
that referenced
this issue
Aug 6, 2024
Fixes siderolabs#9009 When building a port interval set, sort the ports and merge adjacent ranges to prevent mismatch on the nftables side. With address sets, this was already the case due to the way IPRange builder works, but ports need a manual implementation. Signed-off-by: Andrey Smirnov <andrey.smirnov@siderolabs.com> (cherry picked from commit f14c479)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Bug Report
Compilation of ruleset is not happening strictly identical as nft tools does it, resulting in broken programmed rules in the kernel.
Description
In our evaluation setup we use a bastion to carry all talosctl command which is in the subnet of the controle-plane nodes. We end up with a firewall rule like this:
Applying this ruleset results in blocking the port 50001 (but port 50000, 4240 and 10250 and other firewall rules are applied correctly and working correctly)
Logs
There nothing suspicious looking at the generated ruleset :
After calling for help the nftables community (thanks to them btw), looks like the problem comes from rule compilation
if we apply ruleset via nft tools
Now the port 50001 is opened correctly, we can diff the compiled set of ports
So nft create a config that look like one generated by a range
50000-50001
(and this is the workaround)even with a port list ruleset
This looks like a similar reproduction of:
You may find interesting the discussion linked at the end of the issue:
Environment
talosctl version --nodes <problematic nodes>
]kubectl version --short
]AMD64 baremetal (metal iso)
The text was updated successfully, but these errors were encountered: