On 2010/09/21 01:42, Joel Sing wrote: > On Tuesday 21 September 2010, Stuart Henderson wrote: > > On 2010/09/20 12:02, Einar Lvnn wrote: > > > Hi again, > > > > > > Sorry for asking this, but; > > > > > > Did you really test the no-df option in the case where *all* > > > UDP-fragments have DF set? It seems to work fine when "some" have the > > > flag. > > > > I couldn't get it to work with your example command line either.. > > When you are using a match rule with scrub (no-df), the no-df is not > processed > until the rule is actually applied to a packet. With fragments this does not > happen - they are reassembled first. Since the current code does not allow > fragments to enter the fragment cache with the DF flag set, they get dropped. > If you change your PF log level to notice - (`pfctl -x notice` or 'set log > notice') then you will see messages like the following when this happens: > > Sep 21 01:25:40 router /bsd: pf: IP_DF > Sep 21 01:25:40 router /bsd: pf: dropping bad fragment > Sep 21 01:25:40 router /bsd: pf: IP_DF > Sep 21 01:25:40 router /bsd: pf: dropping bad fragment > > If you want to clear the DF flag so that these fragments can be reassembled > then you need to enable no-df for reassembly with the following: > > set reassemble yes no-df > > This will then clear the DF flag, place the fragments in the fragment cache > and reassemble the IP datagram, before applying your PF ruleset.
I should probably have mentioned that I tried that :) But oh bleh, of course I am testing from behind pppoe which is not conducive to getting responses from broken servers.
