PF error message looping on screen. System Locked.

[Volker]

On 06/16/07 15:26, Roger Miranda wrote:
> On Thursday 14 June 2007 10:19, Volker wrote:
>> [re-added cc:pf to have a wider audience, please keep this]
>>
>> On 06/14/07 16:21, Roger Miranda wrote:
>>>> I remember a discussion about your machine in stable@ some time ago.
>>> Yes.  I have come a bit further.  Generally I would get nothing on the
>>> screen. I just started getting this.
>>>
>>>>> We have transfered 150GB (+/-)
>>>> Using sftp, ftp, http or ...?
>>> http / NFS / SMB
>>>
>>>> Are you by any chance being able to get a photopicture (with fast
>>>> shutter time) of the debug messages? Do you have anything in
>>>> /var/log/debug.log /var/log/messages which might be useful?
>>> I do not have nothing with that fast of a shutter.  I looked in the logs
>>> the message the loops is not there.  But I did find the follwoing:
>>>
>>> Jun 13 10:22:32  kernel: pf: dropping packet with ip options
>>> Jun 13 10:22:33  last message repeated 5 times
>> Roger,
>>
>> I don't think this message is related to your trouble. I think you can
>> also avoid these messages by adding 'no scrub' to your pf.conf (I'm
>> currently not aware of any side effects by adding this).
>>
>> Probably Max has some more suggestions on not scrubbing packets.
>>
>> You should get a debugger into your kernel (like Max suggested) and
>> probably also use `pfctl -x loud' or `pfctl -x misc' to get more
>> messages out of pf. If these messages are popping up again, break the
>> system into the debugger and look for the messages (using 'scroll
>> lock' to scroll back some pages), ps and a backtrace.
>>
>> HTH
>>
>> Volker
> Alright, I have encoutered the loop messages again today.
> I have debug set to loud and "no scrub" is in pf.conf.
> 
> I managed to get a 5 sec. video of the loop. Get it at: 
> http://64.201.181.165:82/pfloop.avi
> 
> Any help would be appreciated.
> 
> Roger
> 


Roger,

watched your video (the next time, please mix some nice music in...
just kidding).

I've seen tons of 'pf: loose state match' messages. After seen this, I
took again a look at your rules and am wondering about this one:

rdr on $int_if inet proto tcp from any to any port www -> \
 127.0.0.1 port 3128
pass in log on $int_if route-to lo0 inet proto tcp from any to \
 any port 3128 keep state

I've never tried a combination like that but I think it might be
dangerous. When a packet arrives your $int_if with a destination port
80, the rdr rule will replace the destination address to 127.0.0.1
port 3128. The pass rule will route that packet to lo0. I think you
can safely avoid that extra step.

Try it just like:

rdr on $int_if inet proto tcp from any to any port www -> \
 127.0.0.1 port 3128
pass in log quick on $int_if inet proto tcp from any to \
 any port 3128 flats S/SA keep state

and see if you still see error messages. (Please note the missing
'route-to' statement, an added quick statement and the added 'flags
S/SA' option)

If that doesn't help, I recommend rewriting your rules a bit and use
'set state-policy if-bound' (which I'm using most as I find it better
to administer). Unfortunately I don't have experience with
state-policy if-bound in a bridged environment (just a little warning).

HTH

Volker