cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1500
Views
0
Helpful
2
Replies

ASA FO Standby IP address

zekebashi
Level 4
Level 4

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

1 Accepted Solution

Accepted Solutions

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

View solution in original post

2 Replies 2

Marvin Rhoads
Hall of Fame
Hall of Fame

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):

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

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card