Thanks Mike, I will try with the sysctl settings on my next reboot (hopefully in the next month or so). About the shaping I will post another mail, just to keep the topics separate. Thanks once again.
Regards, Lyubomir On Tue, 9 Mar 2021 at 15:24, mike tancsa <m...@sentex.net> wrote: > Hi, > > I havent tried shaping. If you are getting both blocks on the NIC > firewall and ipfw its possible the packets ipfw are stopping are > fragments or packets with bad checksums. You can have the NIC drop the > bad checksum traffic too with that sysctl setting in loader.conf > > ---Mike > > On 3/9/2021 8:12 AM, Lyubomir Yotov wrote: > > Hi Mike, > > I tried with the VLAN option but it appears to be valid only for the > > switch action: > > #cxgbetool t5nex0 filter 10 iport 0 action pass dip 192.168.1.122 > > dport 80 vlan "=100" > > cxgbetool: port, dmac, smac, vlan, and nat only make sense with > > "action switch" > > Anyway I have implemented this and it works fine. I noticed that there > > are some hits on ipfw rule that used to take care of it. Do you have > > any idea why? > > Have tried to do some sort of shaping in the card? > > > > Regards, > > > > Lyubo > > > > On Mon, 8 Mar 2021 at 13:52, Lyubomir Yotov <l.yo...@gmail.com > > <mailto:l.yo...@gmail.com>> wrote: > > > > Hi Mike, > > Thanks a lot! > > > > Regards, > > > > Lyubomir > > > > On Mon, 8 Mar 2021 at 12:26, mike tancsa <m...@sentex.net > > <mailto:m...@sentex.net>> wrote: > > > > On 3/8/2021 3:17 AM, Lyubomir Yotov wrote: > > > Hi Mike, > > > Thanks for the quick response and provided information. I > > currently > > > have only one interface (in and out). I will try to use the > > vlan > > > option as well to be more precise. My rule might look like: > > > #cxgbetool t5nex0 filter 10 iport 0 action drop dip > > 192.168.1.122 > > > dport 23 vlan 100 > > > Just to be on the safe side, if I add only the above drop > > rule in the > > > firewall I won't need explicit "allow all" in the end? > > > > Hi Lyubomir, > > > > Correct, its *not* like pf where its default block. You > > can then > > use cxgbetool t5nex0 filter list to see what hits. Actually, > > maybe to > > be on the safe side at first, instead of action drop add in > > action pass > > and then hit the rule to see if its being hit or not the way > > you expect. > > You will see the counter go up. then delete it and add it back > > as action > > drop when you are confident its going to do just what you want > > it to do. > > > > > > > > I don't have "hw.cxgbe.attack_filter" and > > > "hw.cxgbe.drop_pkts_with_l3_errors". These will either > > appear after I > > > add a rule or if a change the firmware. I will check after > > adding a rule. > > > > These are /boot/loader.conf values. See man cxl to see what > > they do. > > > > ---Mike > > > > > > > > > > Regards, > > > Lyubomir > > > > > > > > > On Sun, 7 Mar 2021 at 19:15, mike tancsa <m...@sentex.net > > <mailto:m...@sentex.net> > > > <mailto:m...@sentex.net <mailto:m...@sentex.net>>> wrote: > > > > > > Hi, > > > I am using the T5 firewall features on FreeBSD 11 > > and 12 in > > > production and it works great! > > > > > > On 3/7/2021 10:41 AM, Lyubomir Yotov wrote: > > > > - is it safe to add rules on the fly in BSDRP? > > > I add and remove rules on the fly all the time. > > > > - is it safe to implement drop only rules on a > > production server > > > > without breaking the other traffic (should I have an > > allow-all > > > in the > > > > end)? > > > > I would like to test dropping all packets incoming on > > cxl0 from any > > > > host to host 192.168.1.122 with destination port 23. I > > suppose a > > > rule > > > > like the following will do the job: > > > > > > > > #cxgbetool t5nex0 filter 10 iport 0 action drop dip > > 192.168.1.122 > > > > dport 23 > > > > > > > Careful of the orientation. If you have 2 ports, the > > iport makes a > > > difference as to whether the rule gets hit or not. > > > > > > > > > > If I want this persistent I should create a script > > probably and > > > start > > > > it with the system boot? > > > Yes. I have yet to come up with a nice interface to do > > this. For some > > > strange reason, cxgbetool displays IP addresses in HEX ?!? > > > > How many rules can I plug in? > > > > > > I am not sure, but I think > > > > > > dev.t5nex.0.nfilters: number of filters > > > > > > shows the limit ? I have 20 on one box that handles > > about 1Gb/s of > > > packet forwarding. Under DDoS it sees 5-8 and nicely > > drops those > > > packets > > > and normal traffic flows unhindered. > > > > > > I also have > > > > > > hw.cxgbe.attack_filter="1" > > > hw.cxgbe.drop_pkts_with_l3_errors="1" > > > > > > as I often see corrupted packets as part of the DDoS, so > > I just drop > > > those anyways. The packets do show up in the NIC > > counters, so if you > > > are using graphana/cacti to monitor bandwidth, you will > > see them > > > as part > > > of the traffic counts. > > > > > > I run this every 5min and then graph it on cacti to keep > > track of how > > > much is dropped on the box. Its kinda depressing how > > much RFC1918 and > > > Bogon traffic gets dropped :( > > > > > > /usr/sbin/cxgbetool t5nex0 filter list | /usr/bin/grep > > -v Hits | > > > /usr/bin/awk '{ sum+=$2;} END{print sum;}' > > > /var/run/filter-stats.log > > > > > > > > > ---Mike > > > > > > > > > > > > > > Regards, > > > > Lyubomir > > > > > > > > > > > > _______________________________________________ > > > > Bsdrp-users mailing list > > > > Bsdrp-users@lists.sourceforge.net > > <mailto:Bsdrp-users@lists.sourceforge.net> > > > <mailto:Bsdrp-users@lists.sourceforge.net > > <mailto:Bsdrp-users@lists.sourceforge.net>> > > > > > > https://lists.sourceforge.net/lists/listinfo/bsdrp-users > > <https://lists.sourceforge.net/lists/listinfo/bsdrp-users> > > > > > <https://lists.sourceforge.net/lists/listinfo/bsdrp-users > > <https://lists.sourceforge.net/lists/listinfo/bsdrp-users>> > > > > > >
_______________________________________________ Bsdrp-users mailing list Bsdrp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bsdrp-users
