Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 28 Jul 2006 23:50:08 +0200
From:      Stefan Bethke <stb@lassitu.de>
To:        Garance A Drosihn <drosih@rpi.edu>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: Weird problems with 'pf' (on both 5.x and 6.x)
Message-ID:  <CFD9FFBF-6F44-4C3D-8CA4-F0672E08804F@lassitu.de>
In-Reply-To: <p06230932c0f01d26027d@[128.113.24.47]>
References:  <p06230928c0ef06a3bafe@[128.113.24.47]> <p06230929c0ef1457f11c@[128.113.24.47]> <p0623092ac0ef1e9c5970@[128.113.24.47]> <E2B3FC55-4FD7-406C-A245-837B23DC7408@lassitu.de> <p06230932c0f01d26027d@[128.113.24.47]>

next in thread | previous in thread | raw e-mail | index | archive | help
Am 28.07.2006 um 22:20 schrieb Garance A Drosihn:

> At 9:30 PM +0200 7/28/06, Stefan Bethke wrote:
>> What I do find curious is that the client keeps using
>> port 1023 consistently.  I was under the impression that
>> reusing the same port number (thus having the same
>> src-ip/port+dst-ip/port tuple) shouldn't work, because
>> "old" packets could arrive after the original connection
>> was closed; that's what the CLOSE_WAIT state in netstat is.
>
> Hmm.  Well, I did wait a few seconds between the two lpq's,
> just so it would be easier tell them apart in the packet dumps.
>
> Perhaps solaris is quicker to reuse ports, while 'pf'
> remembers that  src-ip/port+dst-ip/port  tuple for a
> longer stretch of time?

Thinking about it, it must be pf's notion of when to forget about a  
closed TCP connection.  lpq (in FreeBSD) is intent on using port  
1023, tells the kernel it's OK to reuse it, and will try until it  
gets it, with an exponential backoff and an upper limit on the number  
of tries.  I'd think the Solaris lpq does the same.  Since the client  
and server "know" it's OK, they can deal with the not-yet-expired  
TIME_WAIT (by ignoring it).  But pf obviously cannot know about it,  
and will drop packets that are received during TIME_WAIT, including a  
new SYN.

For this case in particular, you should be able to use a pair of  
static rules (instead of keep state), since both source and  
destination ports will always be the same. Something like
     pass out quick proto tcp from $client 1023 to $server 515
     pass in quick proto tcp from $server 515 to $client 1023

I'm not certain this is a bug in pf, maybe someone more knowledgeable  
can explain how the TCP state machine in pf works.


Stefan

-- 
Stefan Bethke <stb@lassitu.de>   Fon +49 170 346 0140





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CFD9FFBF-6F44-4C3D-8CA4-F0672E08804F>