Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?20170203164311.L33334>