On Mon, Feb 2, 2009 at 15:15, Steve Spencer <sspen...@kdsi.net> wrote: > The only problem I had was that the ssh to the proprietary accounting > box returned the login immediately, followed by the password, and then > it sat for 2 minutes or more before it returned screens. I noticed on > the Astaro box, that there was a DNS proxy in place for this machine, I > assume because it had the same issue. > > I do have identd being rejected to that server, but have tried dropping > it and also allowing it through with no change. I believe the issue is > DNS related, as when I finally am able to get ssh'ed into the > proprietary accounting box, I'm not able to nslookup the ip of the > firewall (I can do this and return the reverse when the old firewall is > in place).
It definitely is a DNS issue - the most basic fix would be to edit the SSH configuration on the accounting box and set (or add) 'UseDNS No', assuming it uses OpenSSH. This prevents the SSH server from performing a reverse-lookup on every authenticated client to perform logging and ACL checks by DNS instead of by IP. I tend to prefer doing so myself, as DNS information is transient by nature and adds another point of failure. If you don't want to disable that, you need to ensure that whatever DNS resolver the accounting server uses is able to return reverse-lookups for the IP range from which you will be SSHing to it. To use pfSense as a resolver, make sure that the accounting server can reach it on UDP/53, and make sure pfSense's resolver is set to something that will answer PTR queries for the SSH source range (presumably your LAN). RB --------------------------------------------------------------------- To unsubscribe, e-mail: support-unsubscr...@pfsense.com For additional commands, e-mail: support-h...@pfsense.com Commercial support available - https://portal.pfsense.org
