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
<174505.84770.qm@web81801.mail.mud.yahoo.com>, David Hough running
ipfilt
<fireman2006@sbcglobal.net> 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.
|