We got a Cisco Secure PIX Firewall 535 release 6.0 (1) witha a failover configuration. We configured ssh but sometimes it appens that we're no more able to get access to it, seemly without any explanation. With the Pix Device Manager we can access it and see that the access list is right and that there are not ssh session pendings. We experienced that after a reboot, the standby device becomes active and the ssh access is newly available.
Any help is appreciating.
$ ssh -l pix -c des 10.0.0.1
ssh: connect to address 10.0.0.1 port 22: Connection refused
SSH to a PIX failover pair will not really work. The trouble is that after failover, the standby PIX assumes the IP and MAC addresses of the primary. The PIX however, are going to have a different set of public/private key pairs that are used for the SSH session. Your SSH client tries to use the public key of the primary PIX cause that's the IP address it knows about, but it doesn't work because it's actually connecting to the secondary PIX (because of the reboot and the IP address changeover).
Thank you for yor reply, but maybe I need to explain more precisely what I mean. I'm not just rebooting the pix and trying to get ssh access to the standby device which is become active; after a first reboot tha makes the standby as active, a new reboot will make active the original device, and in this way ssh works just fine. This is not a solution to a real problem: by the PDM there's no ssh pending session, but if I 'ssh' to the pix from a unix shell and then take a look to the PDM logging, I receive a message of 'ssh sessions exceided' while there're no ssh sessions. The only way to bypass this, is to do what I mentioned above.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
[toc:faq]Introduction:This document describes details on how NAT-T
works.Background:ESP encrypts all critical information, encapsulating
the entire inner TCP/UDP datagram within an ESP header. ESP is an IP
protocol in the same sense that TCP and UDP are I...