Re: ipfilter vs nintendo DS

#1 (**permalink**) 01-29-2007

--0-1349544151-1170078339=:84770
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

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

--0-1349544151-1170078339=:84770
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

> > 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       &nbsp ;   quick proto tcp from
10.0.2.0/24 to any port = 80 flags S keep state group 150 pass out       &nbsp ;   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. 
--0-1349544151-1170078339=:84770--

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode