So my aim was to setup FortiGate High Availability failover in Active / Passive mode. I’m setting this up in EVE-NG and here’s what my lab looks like;
Note: Im using TWO connections for Heartbeat/Failover, you can simply use one if you prefer.
FortiGate High Availability (Pre-Requisites)
Obviously the firewalls need to be the same! For physical firewalls that’s straightforward, but be careful if you are using virtual FortiGates, make sure they are the same hardware and licence versions!
As you can see in my topology (above), each port needs to be connected to the same network on BOTH firewalls.
Make sure both firewalls are running the SAME firmware.
Make sure the interfaces are not getting their IP addresses from DHCP, or PPPoE.
I’m assuming the primary firewall is all setup and configured properly, the secondary firewall then needs to be built, licensed, and internet connected (so it can update etc). Note: It will take it’s config from the primary firewall when configured.
FortiGate High Availability (Active Passive) From Command Line
I know, Fortinet like to say that there’s no need to be working at command line these days, but when you see how easy it is to setup from CLI, you might choose to do it that way instead.
Primary FortiGate High Availability Setup
FortiGate uses priority to set the primary firewall, by default it sets the value to 128. So I’m going to set my Primary firewall to 200 and my Secondary firewall to 100.
Here are the commands you can simply copy and paste;
[box]
config system ha
set group-id 10
set group-name HA-GROUP
set mode a-p
set password Password123
set hbdev port3 0 port4 0
set session-pickup enable
set override enable
set override-wait-time 10
set priority 200
end
[/box]
What does all that mean? The Group ID and Group Name, are shared by all firewalls in the cluster. (Yes cluster, you can scale this up to more firewalls). Mode simply sets the mode to a-p (active passive). Hbdev denotes the interfaces used for the heartbeat network, (the zeros denote that they will be used equally). Session-pickup allows the firewalls to share the session state table for your clients, (i.e. provides seamless TCP session failover). Override is enabled, this will fail back the the primary firewall when it becomes available. Note: wait-time is enabled and set to 10 seconds to avoid any ‘flap / stutter’ that may cause disconnections when executing the override. Then finally the priority is set to 200.
Secondary FortiGate Hight Availability Setup
Practically the same, but you don’t need to set override, and the priority will be lower (100).
[box]
config system ha
set group-id 10
set group-name HA-GROUP
set mode a-p
set password Password123
set hbdev port3 0 port4 0
set session-pickup enable
set priority 100
end
[/box]
FortiGate HA Monitor and TroubleShooting
At this point go and have a coffee, the config needs replicating from the primary to the secondary, and this can take a few minutes. Use the following command to check;
[box]
get system ha status
[/box]
You want to see them both ‘in-sync‘.
To troubleshoot, use;
[box]
diagnose system ha status
[/box]
FortiGate Failover (Active Passive) From GUI
On the Primary (pre configured) firewall, System > HA > Change the drop down to Active-Passive.
Monitor Interfaces: {you can leave this blank, unless you only want to monitor certain interfaces}.
Heartbeat Interfaces: {enter one or more interfaces}.
What’s Management interface Reservation? : You can use this to have separate management for each firewall, (usually you can’t get to the standby/secondary firewall for GUI/SSH management etc).
Clock OK when complete
You should see something like this;
Jump onto the Secondary firewall, and set it the same, (with the exception of the priority).
Note: Override (Fail Back) cannot currently be set in the GUI.
Wait a while and hit refresh, you should see both firewalls in Sync
Possible Bug in 6.4.4 build 1803 (GA)
When carrying out the above procedure (from the web management console), my firewalls did not sync, while trouble shooting at command line they were both set as primary and appeared not to be able to see the other, they were saying;
{Firewall Serial Number}is selected as the master because it’s the only member in the cluster.
Despite many hours of troubleshooting/rebuilding, this kept happening, it worked fine when configured from command line, but not from the GUI. When I checked the commands after using the GUI I noticed that “set group-id {number}” was missing from the config. If I added this manually it started syncing straight away?
Related Articles, References, Credits, or External Links
Thanks to the good folk at Fortinet for sending me some licences to test this (much appreciated).
You want to deploy 2 Cisco ASA 55xx Series firewalls in an Active/Standby failover configuration.
Solution
Assumptions.
Hardware on both ASA firewalls is identical.
The correct license’s for failover are installed on both firewalls.
The same software versions are installed on both firewalls.
You have your PRIMARY firewall set up and running correctly (Everything works!).
In this example the firewalls were ASA5510’s and all interfaces were being used, so the Management port was used as the “Failover Link” (That needs a security plus license!).
This Link will use a crossover cable (Only available after version 7.0(2) before that you had to use a switch – I think!).
Also I’m using the same link for LAN Based failover (heartbeat) AND Stateful replication.
IP Addresses
Each interface will need its existing IP address, and an address to use whilst in “Standby”. In this example I will use the following,
4. Set up the failover LAN interface (In config mode!).
[box]
PetesASA(config)#
PetesASA(config)# failover lan interface FAIL-OVER Gigabitethernet1/7
INFO: Non-failover interface config is cleared on Management0/0 and its sub-interfaces
PetesASA(config)#
ciscoasa(config)#
ciscoasa(config)# failover lan interface FAIL-OVER Gigabitethernet1/7
INFO: Non-failover interface config is cleared on Management0/0 and its sub-interfaces
ciscoasa(config)#
[/box]
YES: that’s the same as the primary firewall there WON’T be a conflict).
Detected an Active mate
Beginning configuration replication from mate.
[/box]
19. When is says that is has ended replication On the secondary firewall, issue a “show failover” (Note: the hostname will have changed to the one on the primary firewall).
[box]
PetesASA(config)#
PetesASA(config)# show failover
Failover On
Failover unit Secondary
Failover LAN Interface: failover Management0/0 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 4 of 250 maximum
Version: Ours 7.2(2), Mate 7.0(5)
Last Failover at: 14:49:43 UTC May 4 2007
This host: Secondary - Standby Ready
Active time: 0 (sec)
slot 0: ASA5510 hw/sw rev (1.1/7.2(2)) status (Up Sys)
Interface Outside (123.123.123.124): Link Down (Waiting)
Interface DMZ1 (192.168.1.254): Link Down (Waiting)
Interface DMZ2 (192.168.2.254): Link Down (Waiting)
Interface Inside (172.16.1.254): Link Down (Waiting)
slot 1: empty
Other host: Primary - Active
Active time: 514 (sec)
slot 0: ASA5510 hw/sw rev (1.1/7.0(5)) status (Up Sys)
Interface Outside (123.123.123.123): Link Down (Waiting)
Interface DMZ1 (192.168.1.1): Link Down (Waiting)
Interface DMZ2 (192.168.1.1): Link Down (Waiting)
Interface Inside (172.16.1.1): Link Down (Waiting)
slot 1: empty
[/box]
20. To double check go back to the PRIMARY firewall and issue the same command.
[box]
PetesASA(config)# show failover
Failover On
Failover unit Primary
Failover LAN Interface: failover Management0/0 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 15 seconds
Interface Policy 1
Monitored Interfaces 4 of 250 maximum
Version: Ours 7.0(5), Mate 7.2(2)
Last Failover at: 13:21:42 UTC May 4 2007
This host: Primary - Active
Active time: 616 (sec)
slot 0: ASA5510 hw/sw rev (1.1/7.0(5)) status (Up Sys)
slot 1: empty
Interface Outside (123.123.123.123): Link Down (Waiting)
Interface DMZ1 (192.168.1.1): Link Down (Waiting)
Interface DMZ2 (192.168.2.1): Link Down (Waiting)
Interface Inside (172.16.1.1): Link Down (Waiting)
Other host: Secondary - Standby Ready
Active time: 0 (sec)
slot 0: ASA5510 hw/sw rev (1.1/7.2(2)) status (Up Sys)
slot 1: empty
Interface Outside (123.123.123.124): Link Down (Waiting)
Interface DMZ1 (192.168.1.254): Link Down (Waiting)
Interface DMZ2 (192.168.2.254): Link Down (Waiting)
Interface Inside (172.16.1.254): Link Down (Waiting)
[/box]
21. The failover time out of the box is a bit pants, to nail it down a little, on the PRIMARY ASA
22. Save the config. (Note: config changed WILL be replicated to the standby firewall).
[box]
PetesASA(config)#
PetesASA(config)# write mem
Building configuration...
Cryptochecksum: 6650f6c9 09bbb5f0 0dafa0d1 8fc08aba
8756 bytes copied in 3.680 secs (2918 bytes/sec)
[OK]
PetesASA(config)#
[/box]
23. When done pull the power on ASA 1 to fail. With a constant ping running you usually will only lose 1 ping packet.
Failover Commands to Copy and Paste
Note: This assumes you have already added ‘standby’ IP addresses to all you interfaces and is using GigabitEthernet0/4 as the failover interface. Change the values in bold to match your requirements.
[box]
Primary Firewall Config
clear configure interface GigabitEthernet0/4
interface GigabitEthernet0/4
no shut
exit
!
failover lan interface failover GigabitEthernet0/4
failover interface ip failover 192.168.255.9 255.255.255.252 standby 192.168.255.10
failover lan key 666999
failover lan unit primary
failover
failover link failover GigabitEthernet0/4
!
failover poll 1 hol 3
failover poll interface 3
interface GigabitEthernet0/4
failover poll interface 3
exit
!
Standby Firewall Config
clear configure interface GigabitEthernet0/4
interface GigabitEthernet0/4
no shut
exit
!
failover lan interface failover GigabitEthernet0/4
failover interface ip failover 192.168.255.9 255.255.255.252 standby 192.168.255.10
failover lan key 666999
failover lan unit secondary
failover
failover link failover GigabitEthernet0/4
!
[/box]
Related Articles, References, Credits, or External Links
Thanks to Barry van Dijk for correcting up my syntax mistake 🙂
I’ve had very little exposure to JUNOS and Juniper equipment, and later in the year I have to deploy some for a client in a failover cluster. So I had a good look round on the Internet, and found loads of good blog posts and KB articles like this one. The problem is they are all geared to setting up a cluster, they ASSUME you then know about security zones, how to add default routes, and setup NAT etc. So they don’t cover that. Yes you then can set up a cluster, but it has no IP addresses, and you cant pass any traffic though it! Hopefully this will redress the balance.
Solution
Before you start, you obviously need two physical firewalls running the same OS, and this whole procedure is carried out from command line, (I’m using the console cable).
Things that took me a while to grasp, that you need to know.
1. The SRX240 has 16 ports numbered ge-0/0/0 to ge-0/0/15, when you cluster them the ports on the secondary firewall (node1) are renumbered to ge-5/0/0 to ge-5/0/16.
2. As soon as you cluster the firewalls the first port (on both) is reserved for management. That’s ge-0/0/0 and ge-5/0/0 they are then refereed to as fxp0.
3. As soon as you cluster the firewalls the second port (on both) is reserved for the firewalls control plane. That’s ge-0/0/1 and ge-5/0/1 they are then refereed to as fxp1.
4. You need to dedicate another port on both firewalls for the firewalls data link this can be any port, but to keep things simple I’ll use the next free port on both firewalls (ge-0/0/2 and ge-5/0/2). These will then be referred to as fab0 and fab1 (respectively).
Thats the clustering side of things, what about the networks I’m going to connect to the firewall. Take a look at this diagram;
Both the firewalls have a connection to each network (which makes sense if they are going to fail over). I’ve got an ‘outside’ network that connects to the Internet. ‘Inside’ I’ve got two networks, (most people reading this will have one, but remember this is practice for a live client, and they have two data LANS).
As all the networks are connected in two places, where do you assign IP addresses? Well above you can see the outside connections are plugged into ge-0/0/4 and ge-5/0/4. You add both these physical interfaces to a Reth (Redundant Ethernet Interface), and you assign the IP to that. So I have three Reth interfaces, (Reth0 for outside, Reth1 for the first inside network, Reth2 for the second inside interface).
So only Reth interfaces have IP addresses? Well no, the two fxp0 interfaces on each physical firewall, also get an IP address (for out of band management), and it’s a different one for each firewall.
Step 1: SRX240 Setup a Chassis Cluster.
1. Before we start you need to delete the existing interfaces from the config (ALL of them), otherwise you will get some errors later on when you try and commit (save) the firewall config. Also remove the hostname, we will set that in a minute.
[box] delete interfaces ge-0/0/0
delete interfaces ge-0/0/1 —Repeat for the rest of the interfaces—
delete interfaces ge-0/0/14
delete interfaces ge-0/0/15
delete system host-name[/box]
2. Connect ge-0/0/0 to management network > Connect ge-5/0/0 to management network >
Connect ge-0/0/1 on Primary to ge-5/0/1 on Standby, (this can’t be changed and will be the fxp0 connection) > Connect ge-0/0/2 on Primary to ge-5/0/2 on Standby (this can be changed but will be the fab0 and fab1 connection).
3. Carry out the following procedure on BOTH firewalls. This sets the host names of the firewalls and the IP addresses of the management interfaces.
[box]set groups node0 system host-name FW-A
set groups node0 interfaces fxp0 unit 0 family inet address 192.168.254.1/24
set groups node1 system host-name FW-B
set groups node1 interfaces fxp0 unit 0 family inet address 192.168.254.2/24
set apply-groups “${node}”[/box]
4. On FW-A (the primary node0) turn on clustering.
6. Back on FW-A (the remainder of the config will be done on node0), set the configuration for the data link, notice I’m deleting the interface again, (I had a lot of bother with this so let’s play it safe). Then I’m saving the changes with a ‘commit’ command, because at this point if something is wrong it will tell you.
[box]delete interfaces ge-0/0/2
set interfaces fab0 fabric-options member-interfaces ge-0/0/2
set interfaces fab1 fabric-options member-interfaces ge-5/0/2
commit[/box]
Step 2 Create Redundancy Groups
1. Redundancy group 0 is created by default so set the priority for that one first.
[box]root@FW-A# set chassis cluster redundancy-group 0 node 0 priority 100
root@FW-A# set chassis cluster redundancy-group 0 node 1 priority 1[/box]
2. Create a new redundancy group that the Reth interfaces will use.
[box]root@FW-A# set chassis cluster redundancy-group 1 node 0 priority 100
root@FW-A# set chassis cluster redundancy-group 1 node 1 priority 1[/box]
Step 3 Define and Add Physical Interfaces to the Reth Interfaces
1. Define the number of Reth interfaces (two inside and one outside).
[box]root@FW-A# set chassis cluster reth-count 3[/box]
2. Allocate Reth0 to the physical interfaces (for outside).
{primary:node0}[edit interfaces]
root@FW-A# set ge-0/0/8 gigether-options redundant-parent reth1
root@FW-A# set ge-5/0/8 gigether-options redundant-parent reth1
root@FW-A# set reth1 redundant-ether-options redundancy-group 1
root@FW-A# set reth1 unit 0 family inet address 192.168.20.1/24 [/box]
6. Setup Reth2 (inside). Add the physical interfaces, and apply redundancy group 1 (again) then save the changes.
1. To get traffic out to the Internet. the cluster needs the IP of its ‘next-hop’, (usually the router supplied by your ISP).
Note: If you’re anything like me after you enter this you will try and ‘ping’ the router from the firewall, or ping an Internet. IP address, at this point that wont work, (you need to allocate interfaces to security zones first).
[box]root@FW-A# set routing-options static route 0.0.0.0/0 next-hop 123.123.123.1[/box]
Step 5 Add interfaces to Security Zones and Allow Traffic Out
Note: I’m simply allowing all traffic out.
1. Make sure the Security Zones ‘Trust’ and ‘Untrusted’ Exist
[box]root@FW-A# show security zones or
root@FW-A# run show security zones[/box]
2. Add the Reth0 Interface to the Untrusted zone.
[box]root@FW-A# set security zones security-zone untrust interfaces reth0.0 [/box]
3. Allow traffic.
[box]{primary:node0}[edit]
root@FW-A# set security zones security-zone untrust host-inbound-traffic system-services all
root@FW-A# set security zones security-zone untrust host-inbound-traffic protocols all[/box]
4. You can check the changes before you commit them.
5. Then add Reth1 and Reth2 to the Trusted zone and repeat the process to allow all traffic.
[box]root@FW-A# set security zones security-zone trust interfaces reth1.0
root@FW-A# set security zones security-zone trust interfaces reth2.0
root@FW-A# set security zones security-zone trust host-inbound-traffic system-services all
root@FW-A# set security zones security-zone trust host-inbound-traffic protocols all[/box]
6. Let’s check to see all that worked.
[box]
{primary:node0}[edit]
root@FW-A# show security policies from-zone trust to-zone untrust
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
{primary:node0}[edit]
root@FW-A# show security policies
from-zone trust to-zone untrust {
policy trust-to-untrust {
match {
source-address any;
destination-address any;
application any;
}
then {
permit;
}
}
}
[/box]
Step 6 Allow Remote Management
1. We have two interfaces dedicated to out of band management, and we gave them an IP address earlier. Here I’m allowing remote administration via web to the J-Web console.
[box]root@FW-A# set system services web-management https interface fxp0.0[/box]
Step 7 Perform NAT on ‘Outgoing’ traffic.
1. Here we are doing what Juniper call ‘Source NAT‘ where we translate many addresses to one, (as in this case, but it can be a ‘pool’ of IP addresses). For the Cisco heads (like me) we are doing PAT.
Note: If you see Juniper mention ‘Destination NAT‘ they are usually talking about NATTING inbound traffic to one (or more) internal IP addresses.
[box] set security nat source rule-set TRUST-TO-UNTRUST from zone untrust
set security nat source rule-set TRUST-TO-UNTRUST to zone trust
set security nat source rule-set TRUST-TO-UNTRUST rule PAT-INTERFACE match source-address 192.168.0.0/16
set security nat source rule-set TRUST-TO-UNTRUST rule PAT-INTERFACE match destination-address 0.0.0.0/0
set security nat source rule-set TRUST-TO-UNTRUST rule PAT-INTERFACE then source-nat interface [/box]
Related Articles, References, Credits, or External Links
While trying to deploy Solarwinds to monitor a Juniper SRX failover cluster, we were having no joy connecting to the management interface of the secondary/standby firewall. The management (fxp0) interface on the primary (node0) firewall we could get to OK.
]
After jumping on the secondary firewall (via the console connection) we observed the following;
error: the routing subsystem is not running
Solution
As you can see (above) I couldn’t get the routing services started. And I soon found out, this is quite normal, the primary (active) firewall maintains the routing instance, the secondary firewall does not.
Well that fine but what about out Solarwinds box, what happens if the secondary firewall goes down? No one would know, and we also can’t take daily backups of its config.
To fix this problem you need to use the ‘backup-router’ command. This lets the appliance maintain some routes in the event that it is not hosting the live routing instance.
1. I’ll connect to to the primary firewall from this console session on the secondary firewall with the following command;
[box]request routing-engine login node0[/box]
2. Now I can add the backup-router routes, but assign them to the secondary (node1) firewall. Note: Where 192.168.100.1 is the next hop.
[box]
To get traffic back to the Solarwinds Management Server
set groups node1 system backup-router 192.168.100.1 destination 10.1.20.10/32
To get traffic back to the Cisco ACS Appliance
set groups node1 system backup-router 192.168.100.1 destination 10.1.20.10/32
[/box]
3. Don’t forget if the firewalls failover you will have the same problem (but the opposite way round), so I need the same to the primary node as well.
[box]
To get traffic back to the Solarwinds Management Server
set groups node0 system backup-router 192.168.100.1 destination 10.1.20.10/32
To get traffic back to the Cisco ACS Appliance
set groups node0 system backup-router 192.168.100.1 destination 10.1.20.10/32
[/box]
3. Save the config with a ‘commit’ command.
Related Articles, References, Credits, or External Links
You have two ASA firewalls deployed in Active/Standby failover configuration, and need to upgrade either the operating system or the ASDM. As you already have a high availability solution you do not want any downtime.
Before we start, we need to make sure we know the difference between primary, secondary, active and standby.
From the rear (Active=Green, Standby=Amber)
The Primary and Secondary firewalls are physical firewalls, the primary will always be the primary, and the secondary will always be the secondary. (Unless you manually change the configuration to force things otherwise!).
The Active firewall will be the firewall that’s passing traffic and in operation, and the Standby firewall is sat waiting to take over, each physical firewall can be either active or standby.
Solution
To get updates from Cisco you need to have a valid support agreement for your firewalls and a Cisco CCO account to log in with. (download link)
In this example, I’m going to upgrade both the firewalls from 8.4(5) to 9.1(1), and the ASDM from version 7.1(1) to 7.1(1)-52. When we start, the primary firewall is the active firewall.
In the past I’ve upgraded from 8.2(5) to 8.4(5), and (here) 8.4(5) to 9.1(1). I’ve never had a problem HOWEVER, DO NOT ATTEMPT an upgrade until you have a good backup of the config.
1. First you need to upload the software to the flash memory on BOTH firewalls, you can either connect to the ASA via command line and TFTP them there, or connect to the ASDM and upload them from your PC/Laptop. If you have an AnyConnect XML profile take a backup of that also (I’ve seen them disappear).
UPLOAD THE OPERATING SYSTEM
Petes-ASA> enablePassword:*********
Petes-ASA#copy tftp flash
Address or name of remote host []? 10.0.0.127
Source filename []? asa911-k8.bin
Destination filename [disk0]? asa911-k8.bin
Accessing tftp://10.1.0.127/asa911-k8.bin.. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<<<<Removed lots for the sake of Space>>>>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Writing file disk0:asa911-k8.bin... !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!
<<<<Removed lots for the sake of Space>>>>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
27260928 bytes copied in 49.250 secs (556345 bytes/sec)
UPLOAD THE ASDM SOFTWARE
Petes-ASA#copy tftp flash
Address or name of remote host []? 10.0.0.127
Source filename []? asdm-711-52.bin
Destination filename [disk0]? asdm-711-52.bin
Accessing tftp://10.1.0.127/asdm-711-52.bin.. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
<<<<Removed lots for the sake of Space>>>>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Writing file disk0:asdm-711-52.bin... !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!
<<<<Removed lots for the sake of Space>>>>
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
17790720 bytes copied in 32.200 secs (555960 bytes/sec)
[/box] Upload via ASDMConnect to the ASDM > Tools > File Management > File Transfer > Between Local PC and Flash > Navigate to the file(s) on your local machine > Upload.
REMEMBER TO DO THIS FOR BOTH FIREWALLS!Note: You can copy the file to the standby firewall’s flash memory, from the primary firewall, using the following syntax (though I usually just swap the console cable over!).
2. On the Primary Active Firewall, set the new OS as the default, below I check to see what file the ASA will boot from, then I change it to the new one, finally I remove the link to the old file. You don’t need to carry out the last step, but I like to leave things tidy.
[box]
Petes-ASA# show running-config boot system
boot system disk0:/asa845-k8.bin
Petes-ASA# configure terminal
Petes-ASA(config)# boot system disk0:/asa911-k8.bin
Petes-ASA(config)# no boot system disk0:/asa845-k8.bin
Petes-ASA# show running-config boot system
boot system disk0:/asa911-k8.bin
[/box]
3. If you are also upgrading the ASDM, you need to set the new one as the default image.
[box]
Petes-ASA(config)# asdm image disk0:/asdm-711-52.bin
Petes-ASA(config)# show run asdm image
asdm image disk0:/asdm-711-52.bin
no asdm history enable
[/box]
4. Save the changes.
[box]
Petes-ASA(config)# write mem
Building configuration...
Cryptochecksum: e150e036 036082e0 6d054a3d 1c7fd9fa
16257 bytes copied in 3.350 secs (5419 bytes/sec) [OK]
[/box]
5. Whilst still on the primary active firewall, you need to reboot the secondary standby firewall with the following command:
[box]
Petes-ASA(config)# failover reload-standbyYOU MAY SEE A WARNING LIKE THE FOLLOWING - THIS IS OK
************WARNING****WARNING****WARNING********************************
Mate version 9.1(1) is not identical with ours 8.4(5)
************WARNING****WARNING****WARNING********************************
Beginning configuration replication: Sending to mate. End Configuration Replication to mate
Petes-ASA(config)#
[/box]
6. This may take a little while, remember it has to reboot, and depending on the version you are upgrading to, may need to change some of the config i.e. in this case of upgrading pasr 8.3 (and newer) all the NAT rules need to be changed. You can check to see if it’s back online by issuing a ‘show failover command (whilst still on the primary firewall). You will know when the secondary firewall is up and ready as you will see ‘Secondary – Standby Ready’.
Note: If you can see the status lights on the standby firewall watch for them to be green,green,amber,green,off (ASA5510).
Warning: Due to the limitations of HTML, your output will be formatted a little differently, you will see the output displayed like this, but the text is the same.
[box]
Petes-ASA(config)# show failover
Failover On Failover unit Primary Failover LAN Interface:
failover Management0/0 (up)
Unit Poll frequency 1 seconds,
holdtime 3 seconds
Interface Poll frequency 3 seconds,
holdtime 15 seconds
Interface Policy 1
Monitored Interfaces 3 of 110 maximum
Version: Ours 8.4(5), Mate 9.1(1)
Last Failover at: 13:25:54 GMT/BST Dec 6 2012
This host: Primary - Active Active time: 350 (sec)
slot 0: ASA5510 hw/sw rev (2.0/8.4(5)) status (Up Sys)
Interface outside (123.123.123.123): Normal (Monitored)
Interface inside (10.0.0.254): Normal (Monitored)
Interface backup (234.234.234.235): Normal (Monitored)
slot 1: ASA-SSM-10 hw/sw rev (1.0/CSC SSM 6.2.1599.0) status (Up/Up)
Logging port IP: 10.0.0.252/24 CSC SSM, 6.2.1599.0, Up
Other host: Secondary - Standby Ready <<<<<< Here we go!
Active time: 326 (sec) slot 0: ASA5510 hw/sw rev (2.0/9.1(1)) status (Up Sys)
Interface outside (123.123.123.124): Normal (Monitored)
Interface inside (10.0.0.249): Normal (Monitored)
Interface backup (234.234.234.234): Normal (Monitored)
slot 1: ASA-SSM-10 hw/sw rev (1.0/CSC SSM 6.3.1172.0) status (Up/Up)
Logging port IP: 10.0.0.248/24
CSC SSM, 6.3.1172.0, Up
Stateful Failover Logical Update Statistics
Link : failover Management0/0 (up)
Stateful Obj xmit xerr rcv rerr
General 1709 0 491 49
sys cmd 58 0 58 0
up time 0 0 0 0
RPC services 0 0 0 0
TCP conn 896 0 244 48
UDP conn 280 0 45 1
ARP tbl 474 0 141 0
Xlate_Timeout 0 0 0 0
IPv6 ND tbl 0 0 0 0
VPN IKEv1 SA 0 0 1 0
VPN IKEv1 P2 1 0 1 0
VPN IKEv2 SA 0 0 0 0
VPN IKEv2 P2 0 0 0 0
VPN CTCP upd 0 0 0 0
VPN SDI upd 0 0 0 0
VPN DHCP upd 0 0 0 0
SIP Session 0 0 0 0
Route Session 0 0 0 0
User-Identity 0 0 1 0
Logical Update Queue Information Cur Max Total Recv Q: 0 24 2101 Xmit Q: 0 1 2311
Petes-ASA(config)#
[/box]
7. Now you need to force a failover to the secondary firewall, (again do this on the primary active firewall).
[box]
Petes-ASA(config)# no failover active
Petes-ASA(config)#
Switching to Standby
[/box]
8. Now reboot the primary firewall and that should boot to its new operating system.
[box]
Petes-ASA(config)# reload
Proceed with reload? [confirm] {Enter}
[/box]
9. Once complete, log back in and you can make the primary firewall active once more.
[box]
Petes-ASA>
Detected an Active mate Beginning configuration replication from mate.
Petes-ASA>
End configuration replication from mate.
Petes-ASA> en
Password:*********
Petes-ASA# configure terminal
**** WARNING **** Configuration Replication is NOT performed from Standby unit to Active unit. Configurations are no longer synchronized.
Petes-ASA(config)# failover active
Switching to Active
[/box]
Related Articles, References, Credits, or External Links