08-30-2019 11:54 AM
Hello,
I was hoping to get some input or any ideas/thoughts regarding a strange issue we are experiencing when trying to access a standby unit via ssh or asdm.
I've configured two ASAs on FPR2110 in a FO and the FO is working as expected.
I only configured a standby IP address on the management interface, so the configuration on the management 1/1 looks like this:
interface Management1/1
management-only
nameif MGMT
security-level 100
ip address 10.1.153.116 255.255.255.0 standby 10.1.153.117
Here's the issue we are experiencing:
- When connecting the primary unit (10.1.153.116) via SSH and ASDM, the connections are successful
- When trying to SSH to the standby unit (10.1.153.117), SSH fails when using a TACACS+ user account but is successful when using a local user account but with no authorization to perform and admin functions
- When trying to access the standby unit (10.1.152.117) through ASDM, it fails(I suspect that the asdm software code on the secondary unit isn't the same as the one on the primary)
Any thoughts as to why ssh is failing when trying to connect to standby unit using a TACACS+ account?
Thanks in advance,
~zK
Solved! Go to Solution.
09-05-2019 09:49 AM
Thanks for the input, Marvin!
I was able to confirm that the secondary device was defined as a network access device in ISE.
I was able to resolve the issue. Here's what I had to do in order to resolve both issues:
Issue 1: Not able to access(no authorization) the secondary device via SSH using the standby ip address (10.1.153.117) using the local account.
Resolution: It turned out that I was missing the fallback method under the aaa configuration "aaa authorization command ISE", so I had to remove this statement and add this one " aaa authorization command ISE LOCAL" --- Issue resolved
Issue 2: Not able to access the secondary device via SSH using the standby IP address (10.1.153.117) using the AD/tacacs+ account.
Resolution: I found out that the primary management interface (10.1.153.116) was communicating with aaa-server/ISE servers aaa-server ISE (inside) host 10.1.53.25
aaa-server ISE (inside) host 10.1.53.26)
through the inside interface and that's why the AD/admin accounts were able to SSH to the primary unit but not the standby unit. Since the management standby IP address (10.1.153.117) had no path (active interface on the standby unit) to communicate with the aaa-servers/ISE, then ssh access was failing. So, the solution was to either use the local admin account to ssh to the standby unit, which was successful; or to replace the secondary aaa-server to use the MGMT interface, which was also successful.
aaa-server ISE (inside) host 10.1.53.25
aaa-server ISE (management host 10.1.53.26
Issue 3: Not being able to access the standby unit using ASDM
Resolution: After correcting the access use described above, I issued the dir disk0: on the standby unit and the output showed that the correct asdm.bin was missing, so I simply copied the file using TFTP from the primary unit. Here's the command I used: "failover exec mate copy /noconfirm tftp://10.1.22.87/asdm-7101.bin disk0:/"
Thanks again for your input.
Best, ~zK
08-30-2019 07:58 PM
Is the secondary unit's 10.1.153.117 address defined as a network access device in your T+ server? When you try to authenticate there should be accounting events on the server that show you the attempt and any reason for failure.
The ASDM issue may be for the reason you describe. It is easy to check - just run the following from the primary-active unit:
show run asdm failover exec-standby dir
You should see the ASDM image defined in the first command's output as present on the secondary-standby unit's disk0 (output from the second command):
09-05-2019 09:49 AM
Thanks for the input, Marvin!
I was able to confirm that the secondary device was defined as a network access device in ISE.
I was able to resolve the issue. Here's what I had to do in order to resolve both issues:
Issue 1: Not able to access(no authorization) the secondary device via SSH using the standby ip address (10.1.153.117) using the local account.
Resolution: It turned out that I was missing the fallback method under the aaa configuration "aaa authorization command ISE", so I had to remove this statement and add this one " aaa authorization command ISE LOCAL" --- Issue resolved
Issue 2: Not able to access the secondary device via SSH using the standby IP address (10.1.153.117) using the AD/tacacs+ account.
Resolution: I found out that the primary management interface (10.1.153.116) was communicating with aaa-server/ISE servers aaa-server ISE (inside) host 10.1.53.25
aaa-server ISE (inside) host 10.1.53.26)
through the inside interface and that's why the AD/admin accounts were able to SSH to the primary unit but not the standby unit. Since the management standby IP address (10.1.153.117) had no path (active interface on the standby unit) to communicate with the aaa-servers/ISE, then ssh access was failing. So, the solution was to either use the local admin account to ssh to the standby unit, which was successful; or to replace the secondary aaa-server to use the MGMT interface, which was also successful.
aaa-server ISE (inside) host 10.1.53.25
aaa-server ISE (management host 10.1.53.26
Issue 3: Not being able to access the standby unit using ASDM
Resolution: After correcting the access use described above, I issued the dir disk0: on the standby unit and the output showed that the correct asdm.bin was missing, so I simply copied the file using TFTP from the primary unit. Here's the command I used: "failover exec mate copy /noconfirm tftp://10.1.22.87/asdm-7101.bin disk0:/"
Thanks again for your input.
Best, ~zK
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