Hi Gabriele,
Re your "keep state" and "flags S" question, with or without
"keep state" should work, so I don't know why your specific
trouble with Vista. However:
"keep state" lines are generally a good idea - IP Filter will check
the
state table before scanning the ruleset, so subsequent packets in
the same connection are checked and passed much more efficiently.
The "flags S" for TCP works with "keep state" so that only a genuine
initial packet causes the state to be kept - helping prevent attempts
to scan (or break in) by sending packets which should only appear
once a connection has been set up.
(If "flags S" is set without "keep state" I presume the first packet
gets through, but the connection state is not recorded. So later
SYN-ACK and data packets don't match "S", and are blocked).
Typically use something like:
pass ... flags S/SAFR keep state
the above would only pass the packet and enter the corresponding
connection parameters into the state table for the *first* packet in
the conversation, which must have only the S flag out of SAFR set
(in this example U and P would not be checked).
Just "flags S" or "flags S/SA" would also work, that would allow
any packet with only SYN set (or SYN but not ACK, ignoring others).
That is, the first packet of a TCP connection setup 3-way SYN/ACK
exchange.
Since the first SYN packet should also never have RST or FIN set,
you could just exclude any initial packets with these, to minimise
any funny business. I suppose one could argue either way for
URG and PSH - there's no data yet(IIRC?) so Urgent Data Pointer
makes no sense; some stacks might send Push, it's not something
I've ever looked into. S/SA is the least restrictive, S/SAFR
moderately
restrictive, S alone (identical to S/SAFURP) is the most restrictive.
(would be interested in others comments on recommended "flags")
(also does "keep state" automatically allow e.g. required ICMP
packet types/codes for that connection, eg. unreach/needfrag
so Path MTU Discovery works?)
(along the same lines: any clear, authoritative references for which
ICMP types/codes should always be forbidden, which are required
to allow a TCP or UDP connection to work correctly, and which
could be argued either way -- including what those issues are?
I've found a few around but none I'm really happy with, nor
necessarily trust)
Rgds, Stuart.
p.s. Beware "keep state" with redundant interfaces (IPMP):
It's possible to use multiple network interfaces to the same subnet,
for resilience and/or bandwidth. In that case "keep state" might
experience a problem, in that the interface the connection was
established on is also noted, and packets for that connection
are only marked as allowed through that interface.
However packets might flow through any interface to that subnet
(either normally, with load balancing, or in the event of a fail-over
in an active/standby configuration). In that case you might find
packets flowing through one interface okay, but connections hang
or reset when the O/S tries to send via the other interface.
There's an ndd command on /dev/pfil which can be used to notify
pfil of which interfaces are in common groups (qif_ipmp_set and
qif_ipmp_status). I don't think it's documented and we've had
some trouble getting pfil to recognise the ipmp interface settings,
but there are a few examples in the ipfilter alias archives.
On a multi-homed host (eg. central DB or file server) this might
also occur between different internal subnets, if there's routes
between these subnets and some other destination subnet.
--
Stuart Remphrey
RMIT ITS Infrastructure Services - Unix Systems
Phone (03) 992 55 070 (or extension 55070)
>>> On 26-Apr-07 at 5:06 pm, in message
<[EMAIL PROTECTED]>,
Gabriele Bulfon <[EMAIL PROTECTED]> wrote:
> I have found something that makes it work again, but also makes me
think I
> need some clarification about my ipf configuration file.
> For years I had my customers ipf.conf with a region defining the
public
> ports to be available for public services like this:
> pass in quick on [public-if] proto tcp from any to [public-ip]/32
port = 22
> and it worked until I got to Windows Vista. Now, it works if I change
it to:
> pass in quick on [public-if] proto tcp from any to [public-ip]/32
port = 22
> keep state
> Why?
> And also: why this doesn't seem to happen on port 25? Running a
telnet on
> port 25 the manual smtp session seems to work.
> How do I have to use this "keep state" actually ?
> Finally, how and when should I add the "flags S" ?
> I think that this is something that is causing also another issue I
got with
> some "timeout sending data" on Postfix when trying to comunicate with
> specific destinations.
> I'm a bit confused....
> Thanx for any help.
> Gabriele.
> Gabriele Bulfon - Sonicle S.r.l.
> Tel +39 028246016 Int. 30 - Fax +39 028243880
> Via Felice Cavallotti 16 - 20089, Rozzano - Milano - ITALY
> http://www.sonicle.com
>
----------------------------------------------------------------------------------
> Da: Jefferson Ogata <[EMAIL PROTECTED]>
> A: [email protected]
> Data: 23 aprile 2007 18.14.32 CEST
> Oggetto: Re: Windows Vista and ipfilter servers
> On 2007-04-23 10:26, Gabriele Bulfon wrote:
>> I have more data:
>> - Some servers run fine, and there I have the original IPFilter
that
>> comes with Solaris 10
>> - The ones that fail, are those that I upgraded to IPFilter 4.1.9
or
>> 4.1.10 by rebuilding from sources (something was not correctly
working
>> on AMD installations, so I had to upgrade).
>>
>> What I don't understand, is why this problem comes up only if I
connect
>> through Vista, and only on some ports.
> Maybe you have TCP window issues, or maybe Vista uses ECN in a way
your
> ipfilter config doesn't allow for.
> I recommend you examine TCP flags and options in your packet traces
to
> see if there's a difference there between XP and Vista.
> --
> Jefferson Ogata <[EMAIL PROTECTED]>
> NOAA Computer Incident Response Team (N-CIRT) <[EMAIL PROTECTED]>
> "Never try to retrieve anything from a bear."--National Park Service
