-
Notifications
You must be signed in to change notification settings - Fork 2
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
Allow both ingress and egress filtering on single interface #55
Comments
Hi. v0.8.3 should release sometime this week with both IPv4/IPv6 single interface ingress/egress filtering support. I will be testing over the next couple of days. This is the link to the candidate release branch if you are interested in previewing. https://github.com/netfoundry/zfw/tree/v0.8.3-release-candidate. The README describes basic setup and config. |
Awesome, thanks! I did try to preview, but seem to be getting errors that I didn't get with the last release I tried:
In the original release I tried, this worked (and still works with that version):
In the new version, I get errors if I try the same thing:
Don't know if maybe I messed something up copying the files over since the old version I used prebuilt files from the deb package while this time I built from source (also on a different system than where I deployed). |
Hi. It's probably due to the compiling and moving to another system. We are close to completing our tests and will likely release v0.8.3 sometime tomorrow. After installing the new version and before running make sure you issue the |
v0.8.3 is now released! |
Thanks, the official release worked much better! Did a few tests and seems to be working nicely. I was wondering, is there any way to specify a block rule on the egress side for when you don't want to allow a connection somewhere? Right now, it seems to allow everything outbound, but maybe I missed something in the config/docs? |
Hi @pkolano just want to make sure I understand the question. If you set similar to the following, do you not see traffic blocked outbound on ens61f0?
If you enter You should see:
The above should result in all outbound traffic except for arp and icmp to be dropped on ens61f0 (icmp echo-reply will also be dropped unless If you wanted to allow dns outbound to 8.8.8.8 you would add:
In order to survive reboot you would need to have
or equivalent InternalInterfaces config:
You would also need in /opt/openziti/bin/user/user_rules.sh
|
Hi @pkolano did the above guidance help or are you still unable to achieve the filtering you were expecting? |
I have released a new version v0.8.5 which will not allow entering |
@pkolano v0.8.6 adds the ability to enter explicit deny rules by appending ```-d, --disable to the -I, --insert rule`` to both ingress and egress rules. Rule precedence is based on longest match prefix. If the prefix is the same then the precedence follows the order entry of the rules, which when listed will go from top to bottom for ports with in the same prefixe.g. If you wanted to allow all tcp 443 traffic outbound except to 10.1.0.0/16 you would enter the following egress rules:
Listing the above with
The following illustrates the precedence with rules matching the same prefix: Assume you want to block port 22 to address 172.16.240.137 and enter rules the following rules:
The rule listing shows the accept port range 1-65535 listed first and then the deny port 22 after. This would result in port 22 being allowed outbound because traffic would match the accept rule and never reach the deny rule. The correct rule order entry would be:
This will result in traffic to port 22 matching the first rule and being dropped. |
Hi @pkolano did the above feature additions meet your expectations? |
sorry, been busy this week. I will test it out next week. Thanks |
Ok thanks @pkolano, no rush . Before testing please update to latest release which is v0.8.9 I added a bug fix for the -F, --flush operation. |
sorry, finally got back to this. Was trying to measure any performance degradation with randomly generated ip/port combos. When I was adding the rules, however, I am getting the error below (shown for one random ip/port that wasn't applied). I had added 2500 rules, which is shown in the tuple count, but doesn't seem to be applying them after a certain point. Any suggestions?
|
Hi @pkolano I see what the issue is. Its actually a missing compilation argument issue. Thanks for catching this. When the package was compiled there should have been an argument -D MAX_BPF_ENTRIES=100000 which is missing right now in the workflow and Makefile specifically for building zfw_tc_outbound_track.o. Without this it defaults to only 100 egress map entries. I will be releasing v0.8.13 shortly which I will fix this. Sorry for this oversight. |
@pkolano v0.8.13 is now released and should fix the |
Looking really good now. No degradation of bandwidth or increase of latency/CPU utilization. Thanks so much for these additions. Is a very useful general purpose tool now and love the ease of installation/use compared to the other eBPF solutions I've looked at!
|
Hi @pkolano thanks for taking the time to test out this project and for the great feedback and suggestions. |
Per our email discussion, please add the ability to simultaneously filter both ingress and egress on a single interface rather than requiring two interfaces. Since many systems only have one interface, this would allow zfw to be a more general-purpose firewall solution. It already seems like one of the most feature complete and production-ready eBPF firewalls out there so this would make it viable as a high-speed ip/nftables replacement for most purposes. Thanks for the hard work on this!
The text was updated successfully, but these errors were encountered: