> > pass in log quick proto tcp from any port =3D 80 to 10.0.2.0/24 port > > > 1023 group > > 100 > > pass out log quick proto tcp from any port =3D 80 to 10.0.2.0/24 port >= > > > 1023 group 151 > > pass in log quick proto tcp from 10.0.2.0/24 port > 1023 to any port =3D= > > > 80 group > > 101 > > pass out log quick proto tcp from 10.0.2.0/24 port > 1023 to any port = > =3D > > 80 group 150 > > This is normal HTTP traffic. I suspect if you add keep state to the last = > two > rules you shouldn't need the first two. There were already normal rules in place: pass in quick proto tcp from 10.0.2.0/24 to any port = 80 flags S keep state group 101 pass out quick proto tcp from 10.0.2.0/24 to any port = 80 flags S keep state group 150 pass out quick proto tcp from 10.0.2.0/24 to any port = 80 flags S keep state group 151
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.
