Date: Sat, 10 Mar 2001 10:33:41 -0500 From: "Patrick Bihan-Faou" <patrick@netzuno.com> To: <cjclark@alum.mit.edu> Cc: <freebsd-ipfw@freebsd.org> Subject: RE: interface specification extension for ipfw Message-ID: <HJEEKLMFLKEOKHOKNPBMIENCCLAA.patrick@netzuno.com> In-Reply-To: <20010309233505.B50418@rfx-216-196-73-168.users.reflex>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, > Well, you said you want to group traffic by recv interface. I don't > see what is tough about that. If you have three intefaces, if[012], > > 01000 skipto 20000 ip from any to any recv if0 > 01100 skipto 30000 ip from any to any recv if1 > 01200 skipto 40000 ip from any to any recv if2 > 10000 [start of rules for traffic generated by this host] > > Anything that is not passed by these three is traffic that was not > received by any interface, i.e. traffic generated by the machine. This is the type of scheme I use currently. However it forces me to look at the traffic on all the other interfaces first. I my specific application, it is not really practical to have an exhaustive list of interfaces when the rules are generated. Some of them may be "logically" out of service and thus completely ignored. My goal was to implement something like: [ host with ed0 ed1 xl0 xl1 ] 10 skipto 1000 ip from any to any in recv ed0 20 skipto 2000 ip from any to any in recv xl0 30 skipto 3000 ip from any to any in recv local 40 deny ip from any to any Where the last rule of that block rejects traffic on interfaces I don't want to use for now (in this case ed1 and xl1). > Now, the second problem, separating traffic _too_ the host. Trying to > use interface information to figure out which traffic is destined for > this host is kind of awkward. How does the machine figure out which > interface the packet would (or would not) go to? It checks the IP > address of the datagram and then looks at the routing table. Why don't > you take the more direct approach and just check the destination IP of > the datagram to determine what is meant for this host? Well the ipfw man page clearly indicates that on the second pass, the xmit interface contains information on where the packet is going. In case of pakets destined TO the host, there is no xmit interface. Again, I find that this is quite a nice feature, if it can be exploited in the firewall rule set in an non awkward way. I am not ignoring your argument about testing the IP address, but again this is not always the practical solution: you either need to specify all known ip addresses for that host, or you can use the new "me" keyword. However this is more expensive that testing an interface specification. The interface information is already resolved by the IP stack, an pretty much represents a more or less equivalent information to the "me" keyword for IP addresses. One thing I am still not clear about is does the "me" keyword also matches broadcast packets ? say if my IP is 192.168.1.1/24, does me match 192.168.1.255 ? What about 255.255.255.255 ? My feeling is NO, but I may be wrong. Patrick. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?HJEEKLMFLKEOKHOKNPBMIENCCLAA.patrick>