Date: Wed, 11 Feb 2015 11:22:18 +0100 From: Andre Albsmeier <andre@fbsd.ata.myota.org> To: Ian Smith <smithi@nimnet.asn.au> Cc: Andre Albsmeier <andre@fbsd.ata.myota.org>, Lev Serebryakov <lev@freebsd.org>, Freddie Cash <fjwcash@gmail.com>, Matthew Seaman <m.seaman@infracaninophile.co.uk>, freebsd-net <freebsd-net@freebsd.org> Subject: Re: Problems with IP fragments Message-ID: <20150211102218.GA2570@schlappy> In-Reply-To: <20150211193348.H38620@sola.nimnet.asn.au> References: <54C918D2.7090805@FreeBSD.org> <54C91E80.7020407@infracaninophile.co.uk> <54C92222.6000201@FreeBSD.org> <CAOjFWZ4KVyYe65ggiHxy3SSw7MPMgx-0kD5ccfXOM%2BftwncP1A@mail.gmail.com> <20150209212131.GA32613@schlappy> <54D9E233.1010702@FreeBSD.org> <20150210132652.GA3398@schlappy> <20150211035919.B38620@sola.nimnet.asn.au> <20150210183420.GA12325@schlappy> <20150211193348.H38620@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 11-Feb-2015 at 20:10:26 +1100, Ian Smith wrote: > On Tue, 10 Feb 2015 19:34:20 +0100, Andre Albsmeier wrote: > > On Wed, 11-Feb-2015 at 04:33:15 +1100, Ian Smith wrote: > > > On Tue, 10 Feb 2015 14:26:52 +0100, Andre Albsmeier wrote: > > > > On Tue, 10-Feb-2015 at 13:49:23 +0300, Lev Serebryakov wrote: > > > > > On 10.02.2015 00:21, Andre Albsmeier wrote: > > > > > > ... > > > ... > > > > > > > Hmm, I tried again with ipv4 but this doesn't help (I don't use v6 > > > > anyway here). But it seems to work as soon as I switch off layer2 > > > > filtering. Normally I use net.link.ether.ipfw=1 (and, yes, I have > > > > the appropriate arp rules installed). As soon as I switch this to > > > > off, reassembly works. However, I have no idea why the reass code > > > > messes around with layer2... > > > > > > Perhaps you asked it to? :) reass is clearly only useful for ip layer3, > > > so did you have rules such as those examples in ipfw(8) /PACKET FLOW to > > > distinguish layer2 from layer3 processing paths? > > > > Well, I thought so ;-) But after reading this part again, it might be that > > I explicitly have to enable passing of ip(v4) packets in layer2 (so they > > can be processed in ip_input() later on). > > I would think so. It's been nearly 10 years since I last admin'd a > filtering bridge, on FreeBSD 4.10 IIRC. There I found it clearest to > separate layer2 processing using those example rules. However yours is > a simple ruleset, not so hard to follow through all 4 ipfw passes .. > > > Currently I have these rules (with 10.0.0.217 being my IP): > > > > # loopback > > 00100 allow ip from any to any via lo0 > > > > # arp traffic > > 00200 allow ip from any to any layer2 mac-type 0x0806 > > > > # dynamic rules for return stuff > > 00300 check-state > > > > # reassemble > > 00400 reass ip4 from any to any in > > > > # let all out and create state > > 00500 allow ip4 from 10.0.0.217 to any out keep-state > > > > # log remaining layer2 stuff > > 00600 deny log ip from any to any layer2 > > > > # log remaining ip stuff > > 00700 deny log ip from any to any > > > > # default deny rule > > 65535 deny ip from any to any > > > > These work for all of my ssh/http/... and (udp based) openvpn stuff as well > > as DNS (but not things like dig +dnssec www.freebsd.org @72.52.71.1). > > > > Now when I add a rule > > > > 00350 allow ip4 from any to any layer2 > > > > the above dig command works. But why is this needed just for the fragments > > and not for the "normal" v4 packets coming back from traffic which passwd > > through 500 (including all state processing)? > > I'm not sure, but think it may be to do with the stateful processing at > check-state passing these at either layer? Someone may know for sure, > but if you moved 600 to before the check-state or allow .. keep-state it > might provide better clues? > > > And if the fragments are really getting stopped at ether_demux(), why don't > > they get logged with rule 600? > > Again, I don't know. It may be helpful to add 'log' to some rules, If have tried several combinations with "log" on pass or deny rules in various places but did not discover a completely consistent behaviour w.r.t. logging... > including 'reass'? And 'ipfw -ted show' might reveal dynamic states? > > > OK, these questions may sound dumb but I am far from an experienced ipfw > > user as I use pf on all other machines ;-). > > Rather than your rule 350, you could just add ',ipv4' to rule 200, going Well, in fact my layer2 rules are slightly more complex, I just trimmed them down to what we see in 200 for the sake of simplicity. But I did it now in a similiar way to what is shown in ipfw(8) and let all layer2 processeing being skip(ped)to its own rule block which lets ipv4 pass and filters on the rest. Anyway, thanks for pointing me into the correct direction ;-) -Andre > only on my reading of ipfw(8) 'mac-type'. I used to just pass all of > layer2 and filter only on layer3, and then only on the inbound pass and > statelessly, wherras it looks like you're only allowing arp through > layer2 otherwise, unless the stateful rules are (double?) applying? > > cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150211102218.GA2570>