EADDRNOTAVAIL from connect, but only sometimes
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? Thanks. Ron
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. -- Bazsi
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@balabit.hu] Sent: Thursday, April 15, 2010 4:13 AM To: Ron Parker Cc: tproxy@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. -- Bazsi
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@balabit.hu] Sent: Thursday, April 15, 2010 4:13 AM To: Ron Parker Cc: tproxy@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.
On Thu, 2010-04-15 at 08:58 -0400, 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?
TIME_WAIT shouldn't be an issue. It is ignored if SO_REUSEADDR is specified. But REUSEADDR must be specified for both sockets, but I guess that's the case. -- Bazsi
participants (3)
-
Balazs Scheidler
-
KOVACS Krisztian
-
Ron Parker