All,
Running into an issue, on a machine with ipfilter
4.1.27, and a customer version of OpenSSH 4.5p1 (modified to change key
locations). I'm not convinced this is an IPFilter issue, but wanted to
put it out to see if anyone else has experienced anything similar.
We've recently installed this onto 2 different Solaris 10u3 machines,
both of which have a primary global zone, and two sparse root zones.
Ipfilter is running in the global zone, and we are passing application
traffic without issue. However, when users ssh into the machines, and
leave their terminals idle for a matter of 1-2 minutes, they just 'lock'
up. If the sessions stay active, we never see them reach the 'lock up'
state. We've validated that both SSH and the KSH shell are not
configured to shut down idle sessions, and even then, it doesn't appear
to behave the same. The ssh client will eventually time out and close
the non-responsive connection. If you start another session, and look
at the 'locked' session, you can see the sockets are still established,
and the shell process is in 'sleep' state when you truss it. If you
trace down the ports on the 'locked' session, and search for them on
netstat, it appears netstat is showing pending data trying to be sent by
both sides (below #1). I've added our ssh rules from IPFilter (below
#2), but these rules appear to be working on earlier versions of
IPFilter.
We've engaged Sun, who recommended we revert to the Sun version of SSH.
We are running this customer version of ssh on many other machines
without issues, but are looking into the change. We've also ran the
Jumpstart JASS on these two machines, but have been unable to find any
settings that it would have changed to cause this problem. Any ideas,
investigation of IPFilter stats I can perform to help isolate the
problem, or additional data I can collect to help rule out IPFilter in
this scenario? Again, thanks in advance.
Scott Hopkins
#1
Note: 10.18.2.81 is NAT'ed behind 10.99.99.50, when
speaking with the 10.99.99.23 machine. The NAT device is also being
investigated.
Server side netstat
10.99.99.23.22 10.99.99.50.25549 24840 47 49680 0
ESTABLISHED
Client side netstat
10.18.2.81.60568 10.99.99.23.22 49680 431 24840 0
ESTABLISHED
#2
pass in quick on $global_iface proto tcp from 10.99.99.50/32 to
$global_ip/32 port = 22 flags S keep state
pass in quick on $pzone_iface proto tcp from 10.99.99.50/32 to
$pzone_ip/32 port = 22 flags S keep state
pass in quick on $tzone_iface proto tcp from 10.99.99.50/32 to
$tzone_ip/32 port = 22 flags S keep state
