Re: TCP delay, solved

[Antony Stone <Antony@Soft-Solutions.co.uk>]

On Friday 14 June 2002 9:17 am, David Luyer wrote:

> Ah.  I missed the start of the discussion.  You're blocking ident
> lookups on your customers, and it's causing them to have problems
> accessing some sites and services?
>
> Easy solution:
>
>   deny (connection reset) rather than drop the connections

Yes, that's the "hole in my firewall" I referred to.   By sending back RST to 
packets coming in on TCP port 113, I'm telling people there's a firewall 
there.   All other ports send back nothing, and I don't want this one to 
stand out as being different....

> Hard solution:
>
>   transproxy ident

Explain please ?

>   and return a cryptographic hash representing
>   the actual client online on the IP which the ident request is
>   for

Sounds more than most situations would need.   Why bother to send back 
something actually related to the user (yes, I know this is what Ident's 
expecting, but it's not necessary) ?   So long as Ident responds with 
*something* (such as 'no-user') then the remote server will be happy and talk 
to you without a timeout.

The problem is making sure this only happens in response to an outgoing 
packet (ie the Ident request gets treated as RELATED to the initial 
connection), rather than providing an Ident daemon which answers any request 
which comes in (eg port scan).

 

Antony.