Connection refused on already accepted connections
Hi again, when using tproxy, all outgoing connections are redirected to the proxy application. This proxy accepts the connection. After the connection is established, the proxy get get the real target with getsockopt. Now it connects to the real target by itself. What happends, if the target rejects the connection, is unreachable or has other problems? The 3way connection handshake between client and proxy is already established and the client must think, that the connection is established with the real target, as tproxy is transparent. The only way I see is to close the connection so the client will get a "connection closed by foreign host". They cannot distinct between different connection problems. Not very nice!? Maybe some applications will have problems with this behaviour? Nice day, Jan Tegtmeier
On Thu, Jul 03, 2003 at 02:22:28PM +0000, jan@tegtmeier.de wrote:
The only way I see is to close the connection so the client will get a "connection closed by foreign host". They cannot distinct between different connection problems. Not very nice!? Maybe some applications will have problems with this behaviour?
This is definitely the case, and in our experience we had only one problem with this approach: SMTP. The SMTP sender assumes that if a connection is established and no SMTP hello appears that the server is alive, and thus it does not fall back to sending to the secondary MX. This can however be solved by an SMTP proxy (which returns error code 554 when the destination server is not reachable) Once upon a time a patch for the kernel existed which allowed an application to peek SYN_RECVD connections prior to answering with SYN-ACK. I think it was written by Lennard (the same guy who wrote the netfilter-bridging patches) This is not yet integrated with Zorp and I don't even know whether the two patches would interoperate (though I don't see any problems there) That way one could check the SYN, connect to the server and either continue the three-way handshake or return an RST. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1
participants (2)
-
Balazs Scheidler
-
jan＠tegtmeier.de