Unable to log into standby Firewall from outside, but can log into it from within LAN

[ramesh.8901]

Hi All,

I have a query here and wanted to know if it is normal functionality for the ASA to do this.

I have an failover pair of Cisco 5545 ASAs running on version 9.5 and i'm trying to reach it from an instance in AWS Cloud.

The Primary ASA is reachable from the instance; however the standby ASA can't be reached from the instance. Also, i am able to reach the standby firewall from LAN. The local gateway is a Layer three switch, which then routes my traffic to the firewall.

When i take a look at the standby ASA, i get a no adjacency error with both packet-tracer and an asp-drop packet-capture. 

Currently any traffic coming in from cloud, comes to the Primary firewall (through a VPN tunnel) and then traffic is forwarded to the standby firewall through the inside interface (since both ASA's are on the network). The IP address of the Primary ASA's inside interface is: 10.1.111.4/24 and the IP address of the standby ASA's inside interface is: 10.1.111.5/24 - And it's this IP that i am trying to access from the cloud instance(it's on the same interface that i do a packet-tracer and the asp-drop packet capture).

So, the question is, is this normal behavior for the Standby ASA? Does it not allow traffic coming into it from the outside and through the inside interface (from the Primary ASA)? Obviously i'm able to reach it from the Layer three switch since it's routing the traffic to the firewall, but i'm wondering if this is how the ASA is expected to react for traffic coming to it's inside interface from the primary firewall which is directly connected to the standby' inside interface

Here's the output for the Packet tracer:

*********************

Phase: 8
Type: SUBOPTIMAL-LOOKUP
Subtype: suboptimal next-hop
Result: ALLOW
Config:
Additional Information:
ifc selected is not same as preferred ifc
Doing route lookup again on ifc inside

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: NP Identity Ifc
output-status: up
output-line-status: up
Action: drop
Drop-reason: (no-adjacency) No valid adjacency

*****************

Thanks in advance!

[Marvin Rhoads]

Do you have "management-access inside" enabled?

Also double check your NAT rules for the VPN and make sure your have the "route-lookup" keyword in the rule associated with this traffic.

[ramesh.8901]

Hi Marvin,

The thing is, this is only for the standby device. The primary is working just fine, but it 's the standby that's facing this issue.

But to answer your question, the management-access inside is enabled.

I am unable to add a specific double NAT to the standby box because the standby box disallows it.

Furthermore, i am unable to add a double NAT this way:

nat (inside,inside) source static hst-10.50.10.50 hst-10.1.111.5 destination static hst-10.50.10.50 hst-10.1.111.5

Here 10.1.111.5 is the IP address of the inside interface. The standby unit disallows this stating that the destination is in the inside interface and "NAT not installed" or something along those lines.

[Rahul Govindan]

I believe this will only work if your VPN subnet is the same as LAN (or another inside subnet for which you have a route via inside). Here is my reasoning: Traffic from the VPN comes in through Primary inside and reaches the Secondary inside. The Secondary will then route it through the outside interface as the route for the VPN subnet (or default route) is pointing to the outside interface. This is then fail as the secondary has no vpn tunnel.

If you have the VPN subnet route pointing to inside interface, this should back to the core switch (or arp if it part of inside LAN) which then sends it to primary ASA to go back out via VPN.

I know that it works (ssh and ASDM) when I have the pool on the same subnet as the LAN interface - tested with ASA 9.8. Would be interesting to test other conditions.