Cisco ASA 5512 - restore configuration from backup

[Techme]

Hello.

I am quite unexperienced with ASA.

Does the system require a reboot after restoring the configuration from a backup?

Thank you for any information provided.

Kind Regards,

[Francesco Molino]

Hi

I believe you're talking about a backup took from asdm.
You can take a look on this link:
https://www.cisco.com/c/en/us/td/docs/security/firepower/60/asa-fp-services/asa-with-firepower-services-local-management-configuration-guide-v60/Backup-Restore.pdf

When you restore the appliance won't reboot automatically if i recall correctly but you need to reboot it.
However the config will be changed live while restoring the backup.

[Techme]

Hello Francesco

Thank you for the reply.

Do you know how longi t takes for the device to reboot and be fully operational?

Kind regards, 

[Francesco Molino]

Is it a standalone asa or ha cluster?

Usually 10 to 15 minutes max, the asa will be up and running.

[Techme]

Hello Francesco

It's an ha asa.

Thank you for all the info provided so far.

Kind regards 

[Francesco Molino]

When you restored the backup by mistake, have you checked if the secondary has taken the config?
If not, you do a wr mem on the secondary (not on primary), restart the primary and it should come back on in the HA. If not, don't touch the secondary which has the right config, clear the config on primary, and configure the HA only. Afterwards it should come up and running within the cluster.
Why did you say you restored by mistake? What you want to do ? Cancel the restore?

[Techme]

Hello Francesco,

What I meant is that I added a wrong ACL and the servers went down, I was in a hurry to have the servers back online so I performed a restore (which was not a good idea ! It was a simple mistake that I could have easily fixed without restoring).

I am unable to access the secondary Firewall( however I think this problem was going for a while as I took over from another engineer).

Since the restore I am getting some ARP collisions here are is an example from the syslog:

4 Oct 07 2018 10:53:41 405001 Received ARP request collision from xx.xxx.xxx.65/c08c.608b.b276 on interface Inside with existing ARP entry xx.xxx.xxx.65/a0e0.afa2.854c

No matching connection for ICMP error message: icmp src Inside2:xx.xxx.xxx.xxx dst Outside:xxx.xxx.xx.xxx (type 3, code 10) on Inside2 interface.  Original IP payload: tcp src xx.xxx.xxx.xxx/993 dst xx.xxx.xxx.xxx/58062.

I am not sure if the secondary Firewall is interfering some how with the primary, would it be enough to clear the ARP table and power cycle the primary Firewall and turn off the secondary to solve the above?

Thank you for the help so far.

Kind Regards,

[Francesco Molino]

Collision ARP means that multiple systems (2 here) are claiming the IP. I believe it's your restored ASA and your secondary ASA you can't access right now. You can start by clearing your cache but not sure it's gonna solve your problem.

I can't say for sure but what is the IP (don't give us) in collision. Is it an IP from ASA interfaces or your server? With the mac address, you can also trace them in your LAN switches and see where there're connected. It could give you some hints about these devices.

[Techme]

Hello Francesco,

I have 2 inside interfaces (inside 1 and inside 2)

Both interfaces on the ASA are showing the same problem and both IP are from the ASA interface ( gigaethernet 0/1 and 0/2).

I think this ARP collision is causing some problems with the servers, I was thinking to turn off the secondary firewall and see if this would solve the ARP collision problem.

Clearing the ARP cache I am not sure how much is gona help.

Thank you

[Francesco Molino]

Yeah that's what I thought and that's why I was talking about secondary. Normally after a restore you need to reboot your ASA. Personally I never use this backup/restore menu in ASDM. But here your HA is down. Can you maybe share output of show failover ?
If you have access to your secondary ASA, then you can shut down its interfaces (be careful to not loose access to it).
However, I would verify if the restore has been applied on him as well.

[Techme]

Hello Francesco,

Here is the output:

Failover On
Failover unit Primary
Failover LAN Interface: LAN_Fail GigabitEthernet0/5 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 4 of 114 maximum
Version: Ours 8.6(1)2, Mate Unknown
Last Failover at: 19:20:31 GMT/BDT Oct 4 2018
This host: Primary - Active
Active time: 269266 (sec)
slot 0: ASA5512 hw/sw rev (3.0/8.6(1)2) status (Up Sys)
Interface Outside (xx.xxx.xxx.26): Unknown (Waiting)
Interface Inside (xx.xx.xxx.65): Unknown (Waiting)
Interface Inside2 (xx.xxx.xxx.129): Unknown (Waiting)
Interface Inside3 (xxx.xx.xxx.241): Unknown (Waiting)
slot 1: IPS5512 hw/sw rev (N/A/) status (Unresponsive/Up)
Other host: Secondary - Failed
Active time: 0 (sec)
slot 0: empty
Interface Outside (xxx.xxx.xxx.27): Unknown (Waiting)
Interface Inside (xxx.xxx.xxx.76): Unknown (Waiting)
Interface Inside2 (xxx.xxx.xxx.182): Unknown (Waiting)
Interface Inside3 (xxx.xxx.xxx.254): Unknown (Waiting)
slot 1: empty

Stateful Failover Logical Update Statistics
Link : Unconfigured.

Interface Inside3 was recently added and it appears not causing problem, although I just have 1 server on this subnet.

Thank you 

[Francesco Molino]

Ok HA isn't up and your restore may have caused it.
If you don't have access in cli to your secondary, then try shutting down its interfaces on switch side and see what happens.

[Techme]

Hello Francesco,

Thank you for the response.

I do not have access to the phisical hardware but I can ask to turn off the secondary firewall, would this action (turning off the secondary firewall) resolve the ARP request collision ? 

In case I notice that the ARP cache is not in collision anymore this will proof that the secondary firewall was causing the problem.

To restore the secondary firewall what would be the best steps to take?

You been so helpfull thank you very much.

Kind Regards,

[Francesco Molino · Accepted solution]

Based on your answers, I highly believe that when you gonna shutdown the secondary, ARP collision will stop. If not then troubleshooting continues.
Before shutting down, you can try a restart to see if HA comes up again, because config shouldn't be changed based on your inputs (just an acl).
If HA is not coming up, then you can simply:
- keep all its interfaces shutdown
- erase all config on your secondary
- configure only HA on your secondary
- make sure your primary config is saved (do a write mem just in case)
- bring up the HA interface and then all others

Your HA should be back UP

[Techme]

Hello Francesco,

Thank you for the help.

I will keep you updated and let you know how it goes.

Kind Regards