Date: Fri, 10 Feb 2017 01:46:22 +0800 From: Julian Elischer <julian@freebsd.org> To: freebsd-ipfw@freebsd.org Subject: Re: How to use IPFW to filter routing Message-ID: <9bdc58a2-1915-ffd7-ce83-8bfeaa91b60f@freebsd.org> In-Reply-To: <20170203164311.L33334@sola.nimnet.asn.au> References: <3C00AFCB-E2EF-4F89-8FBD-181C99DAC1FF@rakor-net.de> <20170129164035.GB10963@host> <6B3C8792-2FEE-4FCE-952E-F13AF59E0927@rakor-net.de> <20170203164311.L33334@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/2/17 2:58 pm, Ian Smith wrote: > 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. I will add that I find the following scheme works for me to help understand what is going on: on a system with two interfaces $INSIDE and $OUTSIDE I always start my rule sets with somethign like: 100 skipto 1000 ip from any to any in recv $OUTSIDE 110 skipto 2000 ip from any to any out xmit $OUTSIDE 120 skipto 3000 ip from any to any in $INSIDE 130 skipto 4000 ip from any to any out xmit $INSIDE 140 rules for localhost etc. this gives you clear idea of what packet are hitting which rules. you will notice for example that an outgoing packet that is routed form an inside machine first does the rules at 3000 and then the rules at 2000 > 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 > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9bdc58a2-1915-ffd7-ce83-8bfeaa91b60f>