about this procedures: ip rule add dev eth0 fwmark 1 lookup 100 ip rule add dev eth1 fwmark 1 lookup 100 ip rule add dev br0 fwmark 1 lookup 100 It doesnt works Thank you Krisztian 2010/1/11 <tproxy-request@lists.balabit.hu>:

Send tproxy mailing list submissions to        tproxy@lists.balabit.hu

To subscribe or unsubscribe via the World Wide Web, visit        https://lists.balabit.hu/mailman/listinfo/tproxy or, via email, send a message with subject or body 'help' to        tproxy-request@lists.balabit.hu

You can reach the person managing the list at        tproxy-owner@lists.balabit.hu

When replying, please edit your Subject line so it is more specific than "Re: Contents of tproxy digest..."

Today's Topics:

  1. EADDRNOTAVAIL from connect, but only sometimes (Ron Parker)   2. Re: Correct kernel version with tproxy (KOVACS Krisztian)

----------------------------------------------------------------------

Message: 1 Date: Sun, 10 Jan 2010 19:46:58 -0500 From: Ron Parker <rparker@movik.net> Subject: [tproxy] EADDRNOTAVAIL from connect, but only sometimes To: "tproxy@lists.balabit.hu" <tproxy@lists.balabit.hu> Message-ID:        <5D6AFCAC2AD9424D816711D1AF4FE8441BDE791924@MAILR014.mail.lan> Content-Type: text/plain; charset="us-ascii"

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