06-23-2023 12:17 AM
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.
06-23-2023 03:05 AM
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.
06-23-2023 08:02 AM
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.
06-23-2023 08:04 AM
first check is standby not active, if it active use the IP of active FW not IP of standby FW
06-23-2023 08:16 AM
You don't need "terminal monitor" on the ASA. Debug goes to the terminal session where you enabled it by default.
06-23-2023 08:41 AM - edited 06-23-2023 08:43 AM
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.
06-30-2023 04:16 AM
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.
06-30-2023 05:21 AM
you have cluster or HA active/standby ?
07-03-2023 12:27 AM
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.
06-30-2023 07:49 AM
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?
07-03-2023 12:24 AM
07-03-2023 12:52 AM
@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
07-03-2023 04:56 PM
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?
07-02-2023 03:52 PM
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?
07-04-2023 10:50 PM
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide