Date: Fri, 3 Feb 2017 17:58:42 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Rakor <freebsd@rakor-net.de> Cc: =?utf-8?Q?Thom=C3=A1s?= <thoms3rd@gmail.com>, freebsd-ipfw@freebsd.org Subject: Re: How to use IPFW to filter routing Message-ID: <20170203164311.L33334@sola.nimnet.asn.au> In-Reply-To: <6B3C8792-2FEE-4FCE-952E-F13AF59E0927@rakor-net.de> References: <3C00AFCB-E2EF-4F89-8FBD-181C99DAC1FF@rakor-net.de> <20170129164035.GB10963@host> <6B3C8792-2FEE-4FCE-952E-F13AF59E0927@rakor-net.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 29 Jan 2017 18:52:58 +0100, Rakor wrote: > Hi and thanks for your reply! Just a couple of points in addition to Thomás' recent reply, which well covers most aspects .. quoting here went totally weird, so excuse any strangeness there; I'm just plucking out and reformatting a few bits. > Am 29.01.2017 um 17:40 schrieb Thomás <thoms3rd@gmail.com>: > > Have you tried something like this? > > > > ipfw add deny tcp 10.10.30.0/24 to 10.10.10.0/24 setup keep-state > > ipfw add deny tcp 10.10.30.0/24 to 10.10.20.0/24 setup keep-state > > ipfw add allow tcp 10.10.30.0/24 to any 80 setup keep-state > This will work. But for any new subnet I˙˙ll have to remember to deny > it for any other subnets. I think this can become unhandy very soon. Thomás mentioned in passing, but I'll emphasise: this is a classic job for tables. Then you can add or delete entries, on the fly if needed, and table lookups are faster than traversing multiple rules. ipfw deny tcp 10.10.30.0/24 to "table($deniednets)" setup (keep-state doesn't make sense on deny rules) > If I try the follwing the packets are all rejected. I think the > inspection is done before the routing, so IPFW does not know it > should be forwarded using igb2. > ipfw add allow tcp 10.10.30.0/24 to any 80 out via igb2 setup keep-state It's essential to get a picture in your head from ipfw(8) /PACKET FLOW On the 'in' pass, as you later guessed, it is not known which interface might be chosen by routing, which occurs only AFTER the inbound packet has been accepted and is determined to be non-local .. so you have to then do this sort of discrimination on the 'out' pass. As Thomás suggested, add 'log' to any rule you're not sure about how or whether they're doing the right thing, setting logamount to default 100. Once things are working right you can lose the extra logging, but it often makes obvious some possibly mysterious problems. > I also tried it using recv and xmit rules. > First I tried: > ipfw add allow tcp from 10.10.30.0/24 to any out recv igb0.30 xmit igb2 setup keep-state > it does not work. > and later I tried this > ipfw add allow tcp from 10.10.30.0/24 to any out xmit igb2 setup keep-state > also not working > Anytime it was caught by my default rule at the end: > 00150 deny log logamount 5 ip from any to any Yes, that's because you have not accepted these packets on their inbound pass, so they fell through to the deny all rule. The above rules cannot work inbound, but should on the outbound pass, the form of the first one being particularly useful. It may be helpful showing the whole ruleset, or at least a section in context, if you're still having issues? > /var/log/security said: > > 150 Deny TCP 10.10.30.5:51145 82.193.243.115:80 in via igb0.30 > > So to me it looks like he does not know that the packet will be > transmitted via igb2 at the moment it is inspected. Exactly so; it CANNOT know what routing will do with it, as routing only occurs after it has been accepted, just prior to ipfw's outbound pass. Thomás' advice re not being shy about using more deny rules is sound; even on slow processors the time cost per rule is miniscule compared to transmission time, unless you're pushing mega PPS over high Mbps links, in which case you'd be using tables for the utmost advantage anyway. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170203164311.L33334>