cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2638
Views
9
Helpful
18
Replies

Unable to access the standby-ASA using SSH and ASDM

swscco001
Level 3
Level 3

Hello everybody,

our customer has a ASA5516 Active/Standby failover cluster running rel. 9.16(3)23
that is working normaly.

Unfortunately it is not possible to access the inside interface (172.26.34.2)
of the standby node using SSH and ASDM. This interface can be pinged from the
management PC.

The access to the inside interface (172.26.34.1) on the active node is no problem.

3Fgw01# show failover
Failover On
Failover unit Primary
Failover LAN Interface: failover GigabitEthernet1/8 (up)
Reconnect timeout 0:00:00
Unit Poll frequency 500 milliseconds, holdtime 2 seconds
Interface Poll frequency 1 seconds, holdtime 5 seconds
Interface Policy 1
Monitored Interfaces 2 of 410 maximum
MAC Address Move Notification Interval not set
Version: Ours 9.16(3)23, Mate 9.16(3)23
Serial Number: Ours JAD20470B0Q, Mate JAD203602LZ
Last Failover at: 09:31:45 GMT Jan 17 2023
        This host: Primary - Active
                Active time: 13554508 (sec)
                slot 1: ASA5516 hw/sw rev (3.0/9.16(3)23) status (Up Sys)
                  Interface 3F-WLAN (172.26.15.254): Normal (Not-Monitored)
                  Interface inside (172.26.34.1): Normal (Monitored)                    <<<=== no problem
                  Interface outside (193.28.163.18): Normal (Monitored)
                  Interface ITCS (192.168.201.11): Normal (Not-Monitored)
                  Interface Funk (172.26.129.253): Normal (Not-Monitored)
                  Interface 3F-Festnetz (172.26.128.254): Normal (Not-Monitored)
                  Interface BK_Office (172.22.103.250): Link Down (Not-Monitored)
                  Interface BK-Transfer (192.168.2.45): Normal (Not-Monitored)
                  Interface management (192.168.1.1): No Link (Not-Monitored)
                slot 2: SFR5516 hw/sw rev (N/A/5.4.1-211) status (Up/Up)
                  ASA FirePOWER, 5.4.1-211, Up, (Monitored)
                slot 2: SFR5516 hw/sw rev (N/A/5.4.1-211) status (Up/Up)
                  ASA FirePOWER, 5.4.1-211, Up, (Monitored)
        Other host: Secondary - Standby Ready
                Active time: 0 (sec)
                slot 1: ASA5516 hw/sw rev (2.0/9.16(3)23) status (Up Sys)
                  Interface 3F-WLAN (0.0.0.0): Normal (Not-Monitored)
                  Interface inside (172.26.34.2): Normal (Monitored)			<<<=== problem
                  Interface outside (193.28.163.19): Normal (Monitored)
                  Interface ITCS (0.0.0.0): Normal (Not-Monitored)
                  Interface Funk (0.0.0.0): Normal (Not-Monitored)
                  Interface 3F-Festnetz (0.0.0.0): Normal (Not-Monitored)
                  Interface BK_Office (0.0.0.0): Normal (Not-Monitored)
                  Interface BK-Transfer (0.0.0.0): Normal (Not-Monitored)
                  Interface management (192.168.1.2): Normal (Not-Monitored)
                slot 2: SFR5516 hw/sw rev (N/A/5.4.1-211) status (Up/Up)
                  ASA FirePOWER, 5.4.1-211, Up, (Monitored)
                slot 2: SFR5516 hw/sw rev (N/A/5.4.1-211) status (Up/Up)
                  ASA FirePOWER, 5.4.1-211, Up, (Monitored)

I have already rebootet the standby node and the SSH and ASDM configuration
does not show a mistake in my eyes.

A configuration change on the active node will be synced to the mate
immediately.

The output of the command:

show crypto key mypubkey rsa

is exactly the same on both nodes.

I have ser. console access to both nodes.

Attached you find the configuration of the standby unit.

What can I try to get SSH & ASDM access to the standby unit too?

Every hint is appreciated!

Thanks a lot!

 


Bye
R.

18 Replies 18

tvotna
Spotlight
Spotlight

Does standby have 3DES license enabled? Also, since you have console access, you can collect "debug ssh 255" and "capture" simultaneously when connecting via SSH. This may shed some light on the issue.

 

Hi tvotna,

the 3DES license is enabled on the standby-ASA.

The debug on the ser. console did not work because this error message:

3Fgw01# terminal monitor
Monitor option not supported for the console.

Is there any other I could try?

Thanks a lot!




Bye
R.

first check is standby not active, if it active use the IP of active FW not IP of standby FW

You don't need "terminal monitor" on the ASA. Debug goes to the terminal session where you enabled it by default.

 

Try to issue the command "show asp table socket" on the secondary device please and see if it is listening on port 22 and 443. If so, I would think this might be a software bug. Another thing I would check is the routing, ping does not suffer from asymmetric routing as each packet is independent of the other, however, SSH does, so if presumably there is asymmetric routing to reach the secondary inside interface, SSH won't work. Also, I wouldn't try to run debugs from the console line, especially at the maximum level of 255 because that might lock you session out.

Hi Aref;

the standby-ASA is listening for port 22 and 443:

3Fgw01# show asp table socket

Protocol   Socket    State      Local Address                                Foreign Address
SSL        010020f8  LISTEN     172.26.34.2:443                              0.0.0.0:*                        
TCP        01005b68  LISTEN     172.26.34.2:22  			                 0.0.0.0:*

In the capture I see the SSH and ASDM traffic:

3Fgw01# cap ssh int inside match ip ho 172.25.32.100 ho 172.26.34.2

3Fgw01# sh cap ssh

15 packets captured

   1: 12:22:11.436333       802.1Q vlan#410 P0 172.25.32.100.53197 > 172.26.34.2.22: S 2844752465:2844752465(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
   2: 12:22:11.436409       802.1Q vlan#410 P0 172.26.34.2.22 > 172.25.32.100.53197: S 3080472440:3080472440(0) ack 2844752466 win 8192 <mss 1380>
   3: 12:22:11.436516       802.1Q vlan#410 P0 172.25.32.100.53197 > 172.26.34.2.22: R 3561646829:3561646829(0) win 0
   4: 12:22:12.507252       802.1Q vlan#410 P0 172.25.32.100.53197 > 172.26.34.2.22: S 2369941358:2369941358(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
   5: 12:22:12.507328       802.1Q vlan#410 P0 172.26.34.2.22 > 172.25.32.100.53197: S 2605661333:2605661333(0) ack 2369941359 win 8192 <mss 1380>
   6: 12:22:12.507465       802.1Q vlan#410 P0 172.25.32.100.53197 > 172.26.34.2.22: R 2612024615:2612024615(0) win 0
   7: 12:22:14.504017       802.1Q vlan#410 P0 172.25.32.100.53197 > 172.26.34.2.22: S 3045531867:3045531867(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
   8: 12:22:14.504109       802.1Q vlan#410 P0 172.26.34.2.22 > 172.25.32.100.53197: S 3281251842:3281251842(0) ack 3045531868 win 8192 <mss 1380>
   9: 12:22:14.504246       802.1Q vlan#410 P0 172.25.32.100.53197 > 172.26.34.2.22: R 3963205633:3963205633(0) win 0
  10: 12:22:18.704400       802.1Q vlan#410 P0 172.25.32.100.53197 > 172.26.34.2.22: S 2369525484:2369525484(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
  11: 12:22:18.704477       802.1Q vlan#410 P0 172.26.34.2.22 > 172.25.32.100.53197: S 2605245459:2605245459(0) ack 2369525485 win 8192 <mss 1380>
  12: 12:22:18.704644       802.1Q vlan#410 P0 172.25.32.100.53197 > 172.26.34.2.22: R 2611192867:2611192867(0) win 0
  13: 12:22:26.900130       802.1Q vlan#410 P0 172.25.32.100.53197 > 172.26.34.2.22: S 4192759584:4192759584(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
  14: 12:22:26.900222       802.1Q vlan#410 P0 172.26.34.2.22 > 172.25.32.100.53197: S 133512263:133512263(0) ack 4192759585 win 8192 <mss 1380>
  15: 12:22:26.900389       802.1Q vlan#410 P0 172.25.32.100.53197 > 172.26.34.2.22: R 1962693771:1962693771(0) win 0
15 packets shown


3Fgw01# cap asdm int inside match ip ho 172.25.32.100 ho 172.26.34.2
3Fgw01# sh cap asdm

33 packets captured

   1: 12:26:38.544558       802.1Q vlan#410 P0 172.25.32.100.53236 > 172.26.34.2.443: S 3703133768:3703133768(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
   2: 12:26:38.544786       802.1Q vlan#410 P0 172.26.34.2.443 > 172.25.32.100.53236: S 416001582:416001582(0) ack 3703133769 win 32768 <mss 1380>
   3: 12:26:38.544939       802.1Q vlan#410 P0 172.25.32.100.53236 > 172.26.34.2.443: R 673693643:673693643(0) win 0
   4: 12:26:39.723931       802.1Q vlan#410 P0 172.25.32.100.53236 > 172.26.34.2.443: S 3056002181:3056002181(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
   5: 12:26:40.561051       802.1Q vlan#410 P0 172.26.34.2.443 > 172.25.32.100.53236: S 416001582:416001582(0) ack 3703133769 win 32768 <mss 1380>
   6: 12:26:40.561235       802.1Q vlan#410 P0 172.25.32.100.53236 > 172.26.34.2.443: R 26562056:26562056(0) win 0
   7: 12:26:41.727913       802.1Q vlan#410 P0 172.25.32.100.53236 > 172.26.34.2.443: S 281780120:281780120(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
   8: 12:26:44.584686       802.1Q vlan#410 P0 172.26.34.2.443 > 172.25.32.100.53236: S 416001582:416001582(0) ack 3703133769 win 32768 <mss 1380>
   9: 12:26:44.584839       802.1Q vlan#410 P0 172.25.32.100.53236 > 172.26.34.2.443: R 1547307291:1547307291(0) win 0
  10: 12:26:45.926313       802.1Q vlan#410 P0 172.25.32.100.53236 > 172.26.34.2.443: S 2720531318:2720531318(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
  11: 12:26:52.598388       802.1Q vlan#410 P0 172.26.34.2.443 > 172.25.32.100.53236: S 416001582:416001582(0) ack 3703133769 win 32768 <mss 1380>
  12: 12:26:52.598556       802.1Q vlan#410 P0 172.25.32.100.53236 > 172.26.34.2.443: R 3986058489:3986058489(0) win 0
  13: 12:26:54.026121       802.1Q vlan#410 P0 172.25.32.100.53236 > 172.26.34.2.443: S 4162978361:4162978361(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
  14: 12:27:00.141167       802.1Q vlan#410 P0 172.25.32.100.53242 > 172.26.34.2.443: S 4245043923:4245043923(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
  15: 12:27:00.141350       802.1Q vlan#410 P0 172.26.34.2.443 > 172.25.32.100.53242: S 1764061103:1764061103(0) ack 4245043924 win 32768 <mss 1380>
  16: 12:27:00.141502       802.1Q vlan#410 P0 172.25.32.100.53242 > 172.26.34.2.443: R 822257187:822257187(0) win 0
  17: 12:27:01.226764       802.1Q vlan#410 P0 172.25.32.100.53242 > 172.26.34.2.443: S 1018568950:1018568950(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
  18: 12:27:02.171286       802.1Q vlan#410 P0 172.26.34.2.443 > 172.25.32.100.53242: S 1764061103:1764061103(0) ack 4245043924 win 32768 <mss 1380>
  19: 12:27:02.171423       802.1Q vlan#410 P0 172.25.32.100.53242 > 172.26.34.2.443: R 1890749510:1890749510(0) win 0
  20: 12:27:03.228931       802.1Q vlan#410 P0 172.25.32.100.53242 > 172.26.34.2.443: S 643153553:643153553(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
  21: 12:27:06.194905       802.1Q vlan#410 P0 172.26.34.2.443 > 172.25.32.100.53242: S 1764061103:1764061103(0) ack 4245043924 win 32768 <mss 1380>
  22: 12:27:06.195104       802.1Q vlan#410 P0 172.25.32.100.53242 > 172.26.34.2.443: R 1515334113:1515334113(0) win 0
  23: 12:27:07.230288       802.1Q vlan#410 P0 172.25.32.100.53242 > 172.26.34.2.443: S 136855136:136855136(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
  24: 12:27:14.208622       802.1Q vlan#410 P0 172.26.34.2.443 > 172.25.32.100.53242: S 1764061103:1764061103(0) ack 4245043924 win 32768 <mss 1380>
  25: 12:27:14.208820       802.1Q vlan#410 P0 172.25.32.100.53242 > 172.26.34.2.443: R 1009035696:1009035696(0) win 0
  26: 12:27:15.431496       802.1Q vlan#410 P0 172.25.32.100.53242 > 172.26.34.2.443: S 1068251769:1068251769(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
  27: 12:27:21.672328       802.1Q vlan#410 P0 172.25.32.100.53245 > 172.26.34.2.443: S 2174060482:2174060482(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
  28: 12:27:21.672511       802.1Q vlan#410 P0 172.26.34.2.443 > 172.25.32.100.53245: S 2240152926:2240152926(0) ack 2174060483 win 32768 <mss 1380>
  29: 12:27:21.672694       802.1Q vlan#410 P0 172.25.32.100.53245 > 172.26.34.2.443: R 2177940184:2177940184(0) win 0
  30: 12:27:22.831713       802.1Q vlan#410 P0 172.25.32.100.53245 > 172.26.34.2.443: S 2936641112:2936641112(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
  31: 12:27:23.697641       802.1Q vlan#410 P0 172.26.34.2.443 > 172.25.32.100.53245: S 2240152926:2240152926(0) ack 2174060483 win 32768 <mss 1380>
  32: 12:27:23.697824       802.1Q vlan#410 P0 172.25.32.100.53245 > 172.26.34.2.443: R 2940520814:2940520814(0) win 0
  33: 12:27:25.026976       802.1Q vlan#410 P0 172.25.32.100.53245 > 172.26.34.2.443: S 3256838045:3256838045(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
33 packets shown


But no acces by SSH or ASDM is possible.

I have the suspicion that this is not a bug but the access to the inside interface by SSH or ASDM
is just possibble to the active node of the cluster ???

Can you make a clear statement ho this suspicion?

Thanks a  lot!


Bye
R.

you have cluster or HA active/standby ?

Hello,

the 'show failover' output let me think that there is a active/standby HA:

3Fgw01# sh fa
Failover On
Failover unit Secondary
Failover LAN Interface: failover GigabitEthernet1/8 (up)
Reconnect timeout 0:00:00
Unit Poll frequency 500 milliseconds, holdtime 2 seconds
Interface Poll frequency 1 seconds, holdtime 5 seconds
Interface Policy 1
Monitored Interfaces 2 of 410 maximum
MAC Address Move Notification Interval not set
Version: Ours 9.16(3)23, Mate 9.16(3)23
Serial Number: Ours JAD203602LZ, Mate JAD20470B0Q
Last Failover at: 16:04:18 GMT Jun 22 2023
        This host: Secondary - Standby Ready
                Active time: 0 (sec)
                slot 1: ASA5516 hw/sw rev (2.0/9.16(3)23) status (Up Sys)
                  Interface 3F-WLAN (0.0.0.0): Normal (Not-Monitored)
                  Interface inside (172.26.34.2): Normal (Monitored)
                  Interface outside (193.28.163.19): Normal (Monitored)
                  Interface ITCS (0.0.0.0): Normal (Not-Monitored)
                  Interface Funk (0.0.0.0): Normal (Not-Monitored)
                  Interface 3F-Festnetz (0.0.0.0): Normal (Not-Monitored)
                  Interface BK_Office (0.0.0.0): Link Down (Not-Monitored)
                  Interface BK-Transfer (0.0.0.0): Normal (Not-Monitored)
                  Interface management (192.168.1.2): No Link (Not-Monitored)
                slot 2: SFR5516 hw/sw rev (N/A/5.4.1-211) status (Up/Up)
                  ASA FirePOWER, 5.4.1-211, Up, (Monitored)
                slot 2: SFR5516 hw/sw rev (N/A/5.4.1-211) status (Up/Up)
                  ASA FirePOWER, 5.4.1-211, Up, (Monitored)
        Other host: Primary - Active
                Active time: 14006527 (sec)
                slot 1: ASA5516 hw/sw rev (3.0/9.16(3)23) status (Up Sys)
                  Interface 3F-WLAN (172.26.15.254): Normal (Not-Monitored)
                  Interface inside (172.26.34.1): Normal (Monitored)
                  Interface outside (193.28.163.18): Normal (Monitored)
                  Interface ITCS (192.168.201.11): Normal (Not-Monitored)
                  Interface Funk (172.26.129.253): Normal (Not-Monitored)
                  Interface 3F-Festnetz (172.26.128.254): Normal (Not-Monitored)
                  Interface BK_Office (172.22.103.250): Normal (Not-Monitored)
                  Interface BK-Transfer (192.168.2.45): Normal (Not-Monitored)
                  Interface management (192.168.1.1): No Link (Not-Monitored)
                slot 2: SFR5516 hw/sw rev (N/A/5.4.1-211) status (Up/Up)
                  ASA FirePOWER, 5.4.1-211, Up, (Monitored)
                slot 2: SFR5516 hw/sw rev (N/A/5.4.1-211) status (Up/Up)
                  ASA FirePOWER, 5.4.1-211, Up, (Monitored)

Any further idea?

Thanks a lot!




Bye
R.

No, it should work with the standby as well. From the shared packet capture above I see nor the SSH nor the ASDM traffic has completed the TCP three way handshake. I have some doubts that this could be caused by some asymmetric routing, would it be possible?

Hi Aref,

thanks fo your reply!

When I traceroute the primary and the standby ASA from the managment PC
I get the same hops (see attched). So I assume that we don't have asymmetric
routing. Would you agree?

I currently don't have any further ideas.

Thnks a lot!


Bye
R.

@swscco001, the TCP RST packet was sent from the client side of the connection and has weird TCP SEQ#. Is it possible that it was sent by some intermediate device and not the ssh client itself? You can collect sniffer trace on the client to verify and need to also check intermediate devices.

   1: 12:22:11.436333       802.1Q vlan#410 P0 172.25.32.100.53197 > 172.26.34.2.22: S 2844752465:2844752465(0) win 64240 <mss 1380,nop,wscale 8,nop,nop,sackOK>
   2: 12:22:11.436409       802.1Q vlan#410 P0 172.26.34.2.22 > 172.25.32.100.53197: S 3080472440:3080472440(0) ack 2844752466 win 8192 <mss 1380>
   3: 12:22:11.436516       802.1Q vlan#410 P0 172.25.32.100.53197 > 172.26.34.2.22: R 3561646829:3561646829(0) win 0

 

hi,

can you remove this line and try again?

management-access inside

if above didn't work, can you force a failover making standby active and try to SSH and use ASDM?

Could you issue the command "show ssh" on both the active and standby devices and post the output here.

Also, if you connect a PC to the same network as the inside interfaces are you able to then access the standby device?

--
Please remember to select a correct answer and rate helpful posts

Hi Marius,

thanks for the hints.

Attached you find the 'sh ssh' outputs.

I have to ask the customer to connect a PC in the network where both inside interfaces reside
and test the SSH access.

Thanks a lot!



Bye
R.

Review Cisco Networking for a $25 gift card