SSH Server behind PIX 515
Bookmark this page:
 Yahoo!
 Google
 Windows Live
 del.icio.us
 digg
 Netscape
|
|
|||||||||||||||||||||||||||||||
|
Posted by yanks2112 on July 25, 2008, 9:50 am
Please log in for more thread options V7.04 Hi, We have an SSH server running on Linux that sites behind our PIX firewall. Last week it stopped working, no changes to the PIX but a hardware failure on the SSH server. The disks were moved to new hardware and the server is up and running again. The problem we are having is we can connect to the ssh server from behind the firewall, but outside the firewall we get a "Connection Reset by Peer". The PIX logs show this: <166>Jul 24 2008 15:25:21: %PIX-6-302013: Built inbound TCP connection
36169350 for outside:192.168.100.100/39398 (208.120.61.139/39398) to
inside:10.10.10.10/22 (192.168.1.1/22) <166>Jul 24 2008 15:25:21: %PIX-6-302014: Teardown TCP connection
36169350 for outside:192.168.100.100/39398 to inside:10.10.10.10/22
duration 0:00:00 bytes 25 TCP Reset-I I captured packets from behind the firewall between the inside interface and the ssh server and saw the three way handshake, then the ssh server sending its version information and immdiately RST-ing the packet. No. Time Source Destination Protocol Info 6445 19.599017 10.10.10.10 192.168.100.100 SSH Server Protocol: SSH-1.99-OpenSSH_3.7.1p2 No. Time Source Destination Protocol Info 6446 19.601211 10.10.10.10 192.168.100.100 TCP 22 > 54783 [RST] Seq=26 Ack=4047764188 Win=0 Len=0
It appears that the ssh server is rst-ing the connection but I am not sure why, The ssh admin thinks that this is a firewall issue. The firewall admin (me) thinks that its an ssh (or server) issue since the ssh server is rst-ing the packet. Has anyone seen something like this just stop working? Is it the PIX and I'm just missing something? Any help would be appreciated | |||||||||||||||||||||||||||||||
|
Posted by Artie Lange on July 25, 2008, 10:17 am
Please log in for more thread options > PIX 514
> V7.04 > > Hi, > We have an SSH server running on Linux that sites behind our PIX > firewall. Last week it stopped working, no changes to the PIX but a > hardware failure on the SSH server. The disks were moved to new > hardware and the server is up and running again. The problem we are > having is we can connect to the ssh server from behind the firewall, > but outside the firewall we get a "Connection Reset by Peer". The PIX > logs show this: > > <166>Jul 24 2008 15:25:21: %PIX-6-302013: Built inbound TCP connection > 36169350 for outside:192.168.100.100/39398 (208.120.61.139/39398) to > inside:10.10.10.10/22 (192.168.1.1/22) > <166>Jul 24 2008 15:25:21: %PIX-6-302014: Teardown TCP connection > 36169350 for outside:192.168.100.100/39398 to inside:10.10.10.10/22 > duration 0:00:00 bytes 25 TCP Reset-I > > I captured packets from behind the firewall between the inside > interface and the ssh server and saw the three way handshake, then the > ssh server sending its version information and immdiately RST-ing the > packet. > > No. Time Source Destination > Protocol Info > 6445 19.599017 10.10.10.10 192.168.100.100 > SSH Server Protocol: SSH-1.99-OpenSSH_3.7.1p2 > No. Time Source Destination > Protocol Info > 6446 19.601211 10.10.10.10 192.168.100.100 > TCP 22 > 54783 [RST] Seq=26 Ack=4047764188 Win=0 Len=0 > > It appears that the ssh server is rst-ing the connection but I am not > sure why, The ssh admin thinks that this is a firewall issue. The > firewall admin (me) thinks that its an ssh (or server) issue since the > ssh server is rst-ing the packet. > > Has anyone seen something like this just stop working? Is it the PIX > and I'm just missing something? Any help would be appreciated > > > Does it work inside the firewall? Do you have any inspect rules for SSH traffic? Not sure what OS you are running, but could you post some inspect rules for your config? | |||||||||||||||||||||||||||||||
|
Posted by yanks2112 on July 25, 2008, 10:55 am
Please log in for more thread options Hi Artie
Thanks for the quick reply. Yes we can get to it from behind the firewall We dont have any inspection rules for ssh (this works for other ssh servers behind the firewall) The OS is Suse linux (not sure what version, I'll chekc that out) the PIX OS is 7.0(4) The inspection rules fro the config: inspect dns maximum-length 1024 inspect ftp inspect h323 h225 inspect h323 ras inspect http inspect ils inspect netbios inspect rsh inspect rtsp inspect skinny inspect esmtp inspect sqlnet inspect sunrpc inspect tftp inspect sip inspect xdmcp Thansk again | |||||||||||||||||||||||||||||||
|
Posted by Artie Lange on July 25, 2008, 11:36 am
Please log in for more thread options yanks2112 wrote:
> Hi Artie
> > Thanks for the quick reply. > > Yes we can get to it from behind the firewall > We dont have any inspection rules for ssh (this works for other ssh > servers behind the firewall) > The OS is Suse linux (not sure what version, I'll chekc that out) the So you have other SSH servers that work behind the firewall? If so, I would start by double checking to make sure that the NAT translation and ACL's are constructed the same. If they are, I would suggest debugging the errors from the SUSE box, tail -f /var/log/messages and you should see some output of the error from there. | |||||||||||||||||||||||||||||||
|
Posted by yanks2112 on July 25, 2008, 12:17 pm
Please log in for more thread options > yanks2112 wrote:
> > Hi Artie
>
> > Thanks for the quick reply.
>
> > Yes we can get to it from behind the firewall
> > We dont have any inspection rules for ssh (this works for other ssh > > servers behind the firewall) > > The OS is Suse linux (not sure what version, I'll chekc that out) the >
> So you have other SSH servers that work behind the firewall? If so, I > would start by double checking to make sure that the NAT translation and > ACL's are constructed the same. If they are, I would suggest debugging > the errors from the SUSE box, tail -f /var/log/messages and you should > see some output of the error from there. Thanks. I checked the NAT and ACLs and they look ok. The ssh logs show: 11:39:24 10.10.10.10. sshd[6904]: Did not receive identification string from ::ffff:192.168.100.100 Thanks again for your help | |||||||||||||||||||||||||||||||
