-
Notifications
You must be signed in to change notification settings - Fork 265
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
Integration tests for traffic filtering #4792
Comments
github-merge-queue bot
pushed a commit
that referenced
this issue
May 7, 2024
This implements traffic filtering on the gateway. Filters are set on the portal, per-resource, in an allow-list manner. If no filters exist for a given resource all packets are allowed, otherwise only packets that matches port/protocol for the filters are allowed, otherwise they are dropped. Filters can be either TCP, UDP or ICMP. For the first 2 multiple ports can be given. Furthermore, multiple filters can exists for the same resource. To be able to add and remove filters with the same IP/CIDR we keep around the whole list of filters for any given peer using an ID map and recalculate the IP each time something is added is removed. This allows us to remove filters and simply recalculate the allowlist for each IP. Furthermore, for any IP, all rules apply, meaning if there are multiple IPs that apply for a resource all port/protocol combinations for that IP will apply. This works well right now for DNS resources, since access is requested by DNS name, then the resource for that DNS name will arrive at the gateway, and the port filtering will apply given that resource(and any other resource with the same IP). However, since the client has no idea of the filters, it can't request the resource access based on the port/protocol combination and we are still using the most specific("longest match") IP. This will mean that for overlapping CIDR resources, only the rules for the most specific will be used, even if the gateway supports applying them all, since it will not have the other resources. This will be solved in #4789. It can also lead to some weirdness, let's say that you have 10.0.0.0/24 -> TCP/80 and 10.0.0.0/16 -> TCP/443 for your user. The user tries to access 10.0.0.1, and will then only be allowed port 80. At some point the user might access 10.1.0.1 and it will be allowed port 443. But from that point on, the user will be allowed to access 80 and 443 in 10.0.0.1 because the rules correctly work on the gateway, the problem is the client side. Again, #4789 will fix this. Left for next PRs (in tentative order!): - #4792 - #4789 Depends on: #4773. Resolves #2030. Resolves #4791. --------- Co-authored-by: Jamil Bou Kheir <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To build on top of #4779
The text was updated successfully, but these errors were encountered: