Reachablity from outside to Standby ASA

[gordonderick]

I have the above setup. ASA is is Active/Standby mode. From the NMS box i am able to ping the managment interface of the primary ASA 10.52.190.1 but from the NMS i am not able to ping the standby ASA's IP 10.52.190.2. From the primary i can ping the standby and from NMS i can also ping the switch (.3).

I added a route on the ASA :-

route management 172.18.9.6 255.255.255.255 10.52.190.1

With that i could ping from NMS box to the standby ASA (.2) (and the switch) but could not ping the primary ASA (.1)

Is there a way i can get (ping) the standby without causing netowork issues?

[Marvin Rhoads]

Do you have an inside L3 switch or router that also connects the management network? If you do, the easiest way is to put a /32 route on the FW inside interface to go via that device. I believe otherwise the failover cluster gets confused about how to symmetrically route the traffic to/from the VPN to the standby management address as the inbound traffic wants to use the connected management subnet directly.

[gordonderick]

Hi, Thanks for the response. I did try your suggestion but its the same outcome as mentioned in my issue.

[julomban]

The same way you can get/ping the primary unit should be the same way to get to the secondary box. Get a capture on teh standby unit in order to verify if the ASa itself receives the packets from the NMS device, capture below:

capture test interface management match icmp host 172.18.9.6 host 10.52.190.2

Once you have the above capture you can try a ping from NMS server and issue the "show cap test" command, you can share the results wiht us.

[gordonderick]

Here you go:

cc-nd4-asa5550# sh capture test

12 packets captured

   1: 09:45:48.520786 172.18.25.65 > 10.52.190.2: icmp: echo request

   2: 09:45:49.520770 172.18.25.65 > 10.52.190.2: icmp: echo request

   3: 09:45:50.520877 172.18.25.65 > 10.52.190.2: icmp: echo request

   4: 09:47:42.283096 172.18.25.65 > 10.52.190.2: icmp: echo request

   5: 09:47:43.283432 172.18.25.65 > 10.52.190.2: icmp: echo request

   6: 09:47:44.283508 172.18.25.65 > 10.52.190.2: icmp: echo request

   7: 09:48:19.309035 172.18.25.65 > 10.52.190.2: icmp: echo request

   8: 09:48:20.308562 172.18.25.65 > 10.52.190.2: icmp: echo request

   9: 09:48:23.725884 172.18.25.65 > 10.52.190.4: icmp: echo request

  10: 09:48:23.726387 10.52.190.4 > 172.18.25.65: icmp: echo reply

  11: 09:48:24.726952 172.18.25.65 > 10.52.190.4: icmp: echo request

  12: 09:48:24.727455 10.52.190.4 > 172.18.25.65: icmp: echo reply

12 packets shown

Note: 172.18.25.65 is the IP of the NMS server and .4 is the switch (not as labeled in the diagram)

[gordonderick]

Hi julomban , can you think of anything that might help me?

[julomban · Accepted solution]

Hello,

Sorry for the late respond, is the issue still happening? If so, please collect the captures but this time with the detail option at the end so we can see the MAC addresses, example:

show cap test detail

Regards,

Juan Lombana

[gordonderick]

Hi,

Thanks for replying. I clicked on Correct answer by mistake.

See below:

cc-nd4-asa5550# sh cap test detail

7 packets captured

   1: 11:40:19.700021 001d.a2af.381f 001d.a2af.380b 0x0800 98: 172.18.25.65 > 10.52.190.2: icmp: echo request (DF) (ttl 62, id 0)

   2: 11:40:20.699823 001d.a2af.381f 001d.a2af.380b 0x0800 98: 172.18.25.65 > 10.52.190.2: icmp: echo request (DF) (ttl 62, id 0)

   3: 11:40:21.699670 001d.a2af.381f 001d.a2af.380b 0x0800 98: 172.18.25.65 > 10.52.190.2: icmp: echo request (DF) (ttl 62, id 0)

   4: 11:40:37.494435 001d.a2af.381f 30f7.0dd2.3b42 0x0800 98: 172.18.25.65 > 10.52.190.4: icmp: echo request (DF) (ttl 62, id 0)

   5: 11:40:37.495000 30f7.0dd2.3b42 001d.a2af.381f 0x0800 98: 10.52.190.4 > 172.18.25.65: icmp: echo reply (DF) (ttl 255, id 0)

   6: 11:40:38.494633 001d.a2af.381f 30f7.0dd2.3b42 0x0800 98: 172.18.25.65 > 10.52.190.4: icmp: echo request (DF) (ttl 62, id 0)

   7: 11:40:38.495442 30f7.0dd2.3b42 001d.a2af.381f 0x0800 98: 10.52.190.4 > 172.18.25.65: icmp: echo reply (DF) (ttl 255, id 0)

7 packets shown

cc-nd4-asa5550#

[julomban]

Can you confirm the following MAC address:

001d.a2af.380b

It must be from the standby ASA, I see the echo request from your server and the last packet is a echo reply, it seems like the ASA is responding your request.

Regards,

Juan Lombana

[gordonderick]

Thanks for the respnse.

Yes the MAC is 001d.a2af.380b.

The last response you are refering to is the response from the switch 10.52.190.4 and not the ASA which is .2.

The first 3 are the echo requests destined for the ASA.