PF error message looping on screen. System Locked.

[Adam McDougall]

On Sat, Jun 16, 2007 at 05:20:39PM +0200, Volker wrote:

  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).

I was thinking the same thing regarding if-bound.  I use if-bound in production
on a pf bridge and found it avoids lots of loose state match and other state
confusion.  Also, I have found using pf loud debugging tends to deadlock the
console after not too long if I have more than one cpu enabled, so I avoid
using it in production.  After much testing, I feel comfortable without it,
however interesting it is. 

  
  HTH
  
  Volker
  _______________________________________________
  freebsd-pf at freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-pf
  To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"