[tproxy] EADDRNOTAVAIL from connect, but only sometimes

[KOVACS Krisztian]

Hi,

Yes, those sysctls could help, but those depend on TCP PAWS support on 
both ends AFAIK.

(Decreasing the TCP TIME_WAIT timeout interval to something around 20s 
is another option -- definitely less standard conformant, though.)

Cheers,
Krisztian

On 04/15/2010 02:58 PM, Ron Parker wrote:
> Yes, the exact port numbers are used in an attempt to maximize transparency.   The SO_REUSEADDR only allows the bind to proceed, but the connect still fails due to the socket with the matching 4-tuple being in the time_wait state.   Would tcp_tw_recycle/tcp_tw_reuse help in this case?
>
>     Ron
>
>
> -----Original Message-----
> From: Balazs Scheidler [mailto:bazsi at balabit.hu]
> Sent: Thursday, April 15, 2010 4:13 AM
> To: Ron Parker
> Cc: tproxy at lists.balabit.hu
> Subject: Re: [tproxy] EADDRNOTAVAIL from connect, but only sometimes
>
> On Sun, 2010-01-10 at 19:46 -0500, Ron Parker wrote:
>> Hi,
>>
>>
>>
>> We are using the tproxy patch for Linux 2.6.24 (Ubuntu 8.0.4).   When
>> placing outgoing connections, we use the original socket address
>> (4-tuple)  in the bind and set SO_REUSEADDR on the socket.   The
>> sequence we are having difficulty with is:
>>
>>
>>
>> ·        Client connects to transparent proxy
>>
>> ·        Transparent proxy connects to remote server
>>
>> ·        Normal data transfer…
>>
>> ·        Remote server closes the connection (but client connection is
>> maintained)
>>
>> ·        Transparent proxy attempts to connect again to remote server
>> using the original 4-tuple (again)
>>
>> o  Bind succeeds
>>
>> o  Connect fails with EADDRNOTAVAIL
>>
>>
>>
>> The original socket is probably in TIME_WAIT at this point.   I
>> thought the SO_REUSEADDR would take care of the problem.  What am I
>> missing here?
>>
>
> Well, SO_REUSEADDR behaviour is not changed, so if you get EADDRNOTAVAIL
> it either means that IP_TRANSPARENT is not enabled, or there's a
> conflicting socket still in the socket table.
>
> Are you using using exact port numbers when you bind? It might help to
> automatically allocate that.
>
>