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.
