Date: Fri, 30 Aug 2019 02:01:40 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: freebsd-net@freebsd.org, Victor Gamov <vit@otcnet.ru> Subject: Re: finding optimal ipfw strategy Message-ID: <46399afc-89d9-ceea-5144-a6d2f5f102ab@grosbein.net> In-Reply-To: <201908291839.x7TIdlmh091176@gndrsh.dnsmgr.net> References: <201908291839.x7TIdlmh091176@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
30.08.2019 1:39, Rodney W. Grimes wrote:
> One of the things I do when writting a firewall is very early break
> up the traffic based on which interface(s) it is coming in/out of
> and do a skipto based on that, then further classify based on layers
> so that I am usually only doing 1 compare as it traverse down what
> is in effect a trie.
>
> dispatch on interface(s)
> dispatch on protocol (IP, ESP, OSPF, IGMP, ICMP, etc)
> IP: dispatch on transport (TCP, UDP, SCTP...)
> IPTCP: dispatch on setup, established..
> IPTCPsetup: dispatch on ports
> IPUDP: ...
>
> I try to write my sets so that I never do the same comparison on
> a packet at any point in the firewall. Ie, once your in the IPTCP
> set of rules I no longer check for tcp, only check port numbers
> and flags (setup, established, etc)
>
> Does this seem like a reasonable and efficient approach?
Correct but that's important for high-load scenario only and
when firewall processing constitutes most or significant part of work performed by the box.
If userland work's much heavier, this could be unimportant complication :-)
>>> I hope I can place such rule at top of ruleset and only allowed multicast packets outgoing via VLANs interfaces will hit this rule.
>>> and second:
>>> allow udp from $src1 to { 239.1.2.55 or 239.1.2.56 }
>>> or
>>> allow udp from src1 to 239.1.2.0/24{55,56}
>> Last one should me much more efficient as it just needs to perform a couple of 32-bit masking operations
>> and previous one is more general (IP addresses may belong to different networks) and requires slower search.
> I disagree, the first one should be 2 simple 32 bit compares,
> the second one is a 32 bit AND (mask), and then 2 8 bit compares,
> and actually probably actually 32 bit compares due to data type promotion.
That's an example only and I've answered considering scaled picture where there are many more IPs to check for.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46399afc-89d9-ceea-5144-a6d2f5f102ab>