From owner-freebsd-questions@freebsd.org Thu Aug 20 14:00:03 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2E5323BF2AA for ; Thu, 20 Aug 2020 14:00:03 +0000 (UTC) (envelope-from mike@sentex.net) Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [IPv6:2607:f3e0:0:3::19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "pyroxene.sentex.ca", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BXR9Y6gGZz4TYD; Thu, 20 Aug 2020 14:00:01 +0000 (UTC) (envelope-from mike@sentex.net) Received: from [IPv6:2607:f3e0:0:4:d1a4:ae4c:4983:32c5] ([IPv6:2607:f3e0:0:4:d1a4:ae4c:4983:32c5]) by pyroxene2a.sentex.ca (8.15.2/8.15.2) with ESMTPS id 07KE00n5070322 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 20 Aug 2020 10:00:00 -0400 (EDT) (envelope-from mike@sentex.net) Subject: Re: packet filtering via Chelsio NICs To: Navdeep Parhar , FreeBSD Questions References: <6628bb23-c263-0cd7-4861-642977dfe467@sentex.net> From: mike tancsa Autocrypt: addr=mike@sentex.net; keydata= mQENBFywzOMBCACoNFpwi5MeyEREiCeHtbm6pZJI/HnO+wXdCAWtZkS49weOoVyUj5BEXRZP xflV2ib2hflX4nXqhenaNiia4iaZ9ft3I1ebd7GEbGnsWCvAnob5MvDZyStDAuRxPJK1ya/s +6rOvr+eQiXYNVvfBhrCfrtR/esSkitBGxhUkBjOti8QwzD71JVF5YaOjBAs7jZUKyLGj0kW yDg4jUndudWU7G2yc9GwpHJ9aRSUN8e/mWdIogK0v+QBHfv/dsI6zVB7YuxCC9Fx8WPwfhDH VZC4kdYCQWKXrm7yb4TiVdBh5kgvlO9q3js1yYdfR1x8mjK2bH2RSv4bV3zkNmsDCIxjABEB AAG0HW1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ+iQFUBBMBCAA+FiEEmuvCXT0aY6hs 4SbWeVOEFl5WrMgFAlywzOYCGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ eVOEFl5WrMhnPAf7Bf+ola0V9t4i8rwCMGvzkssGaxY/5zNSZO9BgSgfN0WzgmBEOy/3R4km Yn5KH94NltJYAAE5hqkFmAwK6psOqAR9cxHrRfU+gV2KO8pCDc6K/htkQcd/mclJYpCHp6Eq EVJOiAxcNaYuHZkeMdXDuvvI5Rk82VHk84BGgxIqIrhLlkguoPbXOOa+8c/Mpb1sRAGZEOuX EzKNC49+GS9gKW6ISbanyPsGEcFyP7GKMzcHBPf3cPrewZQZ6gBoNscasL6IJeAQDqzQAxbU GjO0qBSMRgnLXK7+DJlxrYdHGXqNbV6AYsmHJ6c2WWWiuRviFBqXinlgJ2FnYebZPAfWiQ== Message-ID: <380724d9-69f3-8726-aa73-48f9aec17e34@sentex.net> Date: Thu, 20 Aug 2020 10:00:01 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 4BXR9Y6gGZz4TYD X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@sentex.net designates 2607:f3e0:0:3::19 as permitted sender) smtp.mailfrom=mike@sentex.net X-Spamd-Result: default: False [1.25 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f3e0::/32]; MIME_GOOD(-0.10)[text/plain]; HFILTER_HELO_IP_A(1.00)[pyroxene2a.sentex.ca]; HFILTER_HELO_NORES_A_OR_MX(0.30)[pyroxene2a.sentex.ca]; DMARC_NA(0.00)[sentex.net]; NEURAL_HAM_MEDIUM(-0.21)[-0.213]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_SHORT(0.46)[0.463]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-questions]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Aug 2020 14:00:03 -0000 Hi Navdeep,     Thanks for the followup and thanks for the awesome tools and features in the drivers!  So far so good dropping the traffic. I havent yet had to deal with dropping L3/L4 checksums, but in a DDOS that might be handy.  I see the standard mix of stuff from straight up UDP & ICMP blasts both spoofed and not, back scatter attacks (SYN-ACKS) etc.  At my borders I like to drop all RFC 1918 addrs. With ipfw thats easy enough with one line deny ip from 192.168.0.0/16,10.0.0.0/8,172.16.0.0/12 to any via cxl0 // stop bogons from leaking and entering However, I dont think thats possible with the TCAM filters ? I can drop those RFC 1918 addrs inbound on cxl0 with the filter cxgbetool t5nex0 filter 3 iport 0 sip 172.16.0.0/12 action drop but I cant do the equiv of "via" no ? I would have to add an addition rule cxgbetool t5nex0 filter 4 iport 1 sip 172.16.0.0/12 action drop assuming port 0 is outside facing and 1 is inside facing. Another nice feature would be to somehow expose the stats via sysctl ? Or is that needlessly expensive to keep track of ?  It would be nice to hook this into our monitoring system (cacti etc) to detect when an actual DDoS is happening or even just track attacks over time. Other quick thing, would be to render the filter IPs in dotted quad rather than as a hex int ? cxgbetool t5nex0 filter list  Idx     Hits FCoE Port      vld:VLAN  Prot MPS Frag                  DIP                  SIP     DPORT     SPORT Action    1   119961  0/0  0/7 0:0000/0:0000 00/00 0/0  0/0    00000000/00000000    0a000000/ff000000 0000/0000 0000/0000 Drop    2    54832  0/0  0/7 0:0000/0:0000 00/00 0/0  0/0    00000000/00000000    c0a80000/ffff0000 0000/0000 0000/0000 Drop    3    19478  0/0  0/7 0:0000/0:0000 00/00 0/0  0/0    00000000/00000000    ac100000/fff00000 0000/0000 0000/0000 Drop     ---Mike On 8/19/2020 6:48 PM, Navdeep Parhar wrote: > Hi Mike, > > Your followup on -questions indicates that you got the information that > you were looking for. > > In addition to that, it is also possible to drop entire categories of > bad packets in the hardware automatically --- stuff like incorrect L3/L4 > checksums, bad header lengths, etc. This is not done by default because > then you can't use tcpdump to see what was wrong with the frame and the > sw drop counters won't increment either. In case you see a lot of bad > traffic of this sort and do not want to spend any CPU cycles on it let > me know and I'll add a tunable to enable this behavior. > > Regards, > Navdeep > > On 8/17/20 6:13 AM, mike tancsa wrote: >> Has anyone used the packet filtering features of the T520 and T540 cards >> on FreeBSD ? Rather than use ipfw or pf, I am hoping to offload some of >> the packet filtering to the features on the card. Does it save CPU >> processing power in the end ? Is there a sweet spot to using it, or am I >> better off using ipfw ? I am looking at dropping traffic in the 2-5Gb/s >> range filtering out bogons and other bad packets. >> >> Would appreciate any examples / caveats / tip on how to use it as the >> docs are kind of sparse. Using it on RELENG_12 >> >>     ---Mike >> > >