Hi David, I'm a little confused, so I'll throw in a few random thoughts: Shouldn't the "from" and "to" be switched in one/some of these? ie. who's the 10.0.2.0 (/24) and who's the "any", which is internal vs external? (&the "head" rules starting these groups might help?)
If the DS is 10.0.2.0/24 (ie .90) your incoming packet would be "to" that address, not "from" it? Normally there's a Syn ; Syn-Ack; Ack handshake per TCP connection, but sometimes another flag like Push (and/or Urg?) may be set too; perhaps try using "flags S/SAFR" to exclude only Fin and Reset combined with the Syn/Syn-Ack/Ack exchange? ?pass in quick proto tcp from any to 10.0.2.0/24 port = 80 flags S/SAFR keep state group 101 ?pass in quick proto tcp from 10.0.2.0/24 to any port = 80 flags S/SAFR keep state group 101 pass out quick proto tcp from 10.0.2.0/24 to any port = 80 flags S/SAFR keep state group 150 pass out quick proto tcp from 10.0.2.0/24 to any port = 80 flags S/SAFR keep state group 151 Rgds, Stuart. >>> On 30-Jan-07 at 12:45 am, in message <[EMAIL PROTECTED]>, David Hough running ipfilt <[EMAIL PROTECTED]> wrote: > ... > That sufficed for all normal http connections. The nintendo connection > failed because the website it was contacting responded with flags AS e.g.: > > #27/01/2007 22:52:42.230327 dmfe1 @100:19 b 209.67.106.140,80 -> > 10.0.2.90,4854 PR tcp len 20 44 -AS IN > > So I infer that nintendo's external websites act a little oddly too. > Putting on a keep state rule for that connection didn't work, because then > I would get something like > > #27/01/2007 23:07:49.089695 dmfe0 @101:32 b 10.0.2.90,4646 -> > 209.67.106.140,80 PR tcp len 20 110 -AP IN > > So I came to the conclusion that nintendo didn't have the same ideas about > TCP state as ipfilter. It's probably not worth debugging much further > since several colleges seem to have already tried and given up - but I > thought I would check with the list to see if anybody else had tried > to get it to work with ipfilter.
