ASA active/passive - file management

[darren.g]

Learned ones! :-)

I've finally managed to get a window to implement active/passive across my pair of ASA5520's, and all works well except for one minor issue on the passive.

On config copy/parse in the initial setup, it complained about some of the requesit software not being available.

I had a rummage on the active node, and the only difference between the two is some anyconnect images which are on the active, but not the passive.

This isn't a huge issue, because I don't actually *use* any connect, however in trying to make the paassive happy, I ran into a problem.

I couldn't actually manipulate the passive node flash disk without using the console port and an X-modem upload (and if anyone thinks I'm going to upload 4 x 2 meg images via X-Modem at 9600 you're crazier than I am!).

So, my question is - is there any way, other than the only one I can see (failover tot he passive node, copy the files via TFTP over IP, fail back to the regular node) for my to either put the files onto the passive node flash, or copy them from the main node across the synchronisation link?

Thanks.

[Richard Burts]

Darren

You have not told us how your ASAs are set up so my response is based on assumptions about how you have done the connections and configuration. Most of the time in setting up active/standby for ASA you have the inside interfaces of each ASA connected on a common subnet and with IP addresses from that subnet on each interface. In this case you should be able to copy files using TFTP (or FTP or copying protocol of your choice) to the disk of the backup ASA.

HTH

Rick

[darren.g]

Richard Burts wrote:
Darren
You have not told us how your ASAs are set up so my response is based on assumptions about how you have done the connections and configuration. Most of the time in setting up active/standby for ASA you have the inside interfaces of each ASA connected on a common subnet and with IP addresses from that subnet on each interface. In this case you should be able to copy files using TFTP (or FTP or copying protocol of your choice) to the disk of the backup ASA.
HTH
Rick

Rick.

The ASA exactly duplicates the configuration of the primary to the secondary when using the standard "active/passive" failover - so the IP addresses of the "inside" interface are identical - the relevant sections from the configuration are below

failover

failover lan unit primary

failover lan interface failover GigabitEthernet0/3

failover link failvoer GigabitEthernet0/3

failover interface ip failover 172.20.0.1 255.255.255.252 standby 172.20.0.2

basically, both units are connected to the core switch in an identicle fashion - same VLAN's - but the secondary unit sits silent unless (and until) the primary fails - then it ARP floods the interface IP addresses to everything, takes over the state of existing transactions, and keeps on cookin'.

So no, I can't connect to the "inside" IP address of the standby unit because it doesn't have one - not one which will answer, anyway.

Cheers.

[Richard Burts]

Darren

Perhaps you could post the config of the inside interface for the ASA? In the typical config for active/standby there is an IP for the primary and an IP for the standby on the inside interface. It would be helpful to know if your ASA is configured in this way or not.

HTH

Rick

[darren.g]

Richard Burts wrote:
Darren
Perhaps you could post the config of the inside interface for the ASA? In the typical config for active/standby there is an IP for the primary and an IP for the standby on the inside interface. It would be helpful to know if your ASA is configured in this way or not.
HTH
Rick

Rick.

In a Checkpoint world, for example, you're correct - there are three IP addresses associated with an active/passive standby - one for each node, and one for the "virtual" address which floats wit the currently active node, and you can PING both node addresses as well as the virtual address.

With a PIX or ASA world (also Palo Alto) this is not how it works. The passive device is an *exact* copy of the active, down to IP addresses - it simply sits there and doesn't answer ARP requests for that IP address unless the primary fails and it loses synchronisation.

My "inside" interface from the active node looks like this

interface GigabitEthernet0/0

description ## Inside link to core

speed 1000

duplex full

nameif inside

security-level 100

ip address 10.100.0.249 255.255.255.248

no pim

no igmp

My "inside" configuration from the standby node looks like this

FW1# failover exec mate show run

interface GigabitEthernet0/0

description ## Inside link to core

speed 1000

duplex full

nameif inside

security-level 100

ip address 10.100.0.249 255.255.255.248

no pim

no igmp

The sole difference between the two configurations is here

Active node

failover

failover lan unit primary

failover lan interface failover GigabitEthernet0/3

failover link failover GigabitEthernet0/3

failover interface ip failover 172.20.0.1 255.255.255.252 standby 172.20.0.2

Standby node

failover

failover lan unit secondary

failover lan interface failover GigabitEthernet0/3

failover link failover GigabitEthernet0/3

failover interface ip failover 172.20.0.1 255.255.255.252 standby 172.20.0.2

Cheers

[Richard Burts]

Darren

From my perspective you have an atypical config for an ASA. I have done several ASA installs for active/standby and each of them has had an IP address for the active unit and a different IP address for the standby unit. Here is an example from one pair

!

interface GigabitEthernet0/1

description inside

nameif inside

security-level 100

ip address 172.18.179.33 255.255.255.240 standby 172.18.179.34

and with this config it is easy to establish a session to the standby unit and to copy data files to its disk.

HTH

Rick

[darren.g]

Richard Burts wrote:
 Darren
From my perspective you have an atypical config for an ASA. I have done several ASA installs for active/standby and each of them has had an IP address for the active unit and a different IP address for the standby unit. Here is an example from one pair
!
interface GigabitEthernet0/1
 description inside
 nameif inside
 security-level 100
 ip address 172.18.179.33 255.255.255.240 standby 172.18.179.34
and with this config it is easy to establish a session to the standby unit and to copy data files to its disk.
HTH
Rick

Richard.

You see, there we are at loggerheads. I've never seen active/passive failover done the way you describe - I've always done it the way I have it configured (and, truth be told and excluding the issue with file system management, I prefer it this way). This may be a holdover from my PIX days, but it's hard to teach an old dog new tricks. :-)

Your way requires a minimum of a /29 on "live" IP ranges - one address for each ASA at minimum, and one for the "upstream" router. My way can be done with a /30 because I only need one IP address for the ASA and one for the upstream router.

Which, while it does go to prove that no two network/security engineers will do the same thing the same way (:-)), doesn't resolve my original issue - and as far as I can tell, my only option at this time is to failover to the standby, upload the files via TFTP and then fail back to the primary.

Cheers.

[david.tran]

"In a Checkpoint world, for example, you're correct - there are three IP  addresses associated with an active/passive standby - one for each node,  and one for the "virtual" address which floats wit the currently active  node, and you can PING both node addresses as well as the virtual  address."

This is true whether you use Checkpoint ClusterXL or Nokia VRRP.  you always have three IP addresses.

"My way can be done with a /30 because I only need one IP address for the ASA and one for the upstream router."

Your way is NOT supported by Cisco TAC.  Both the Active/Standby Pix/ASA requires an unique IP address.  That's why on the Active Firewall, you willl see something like this:

interface Ethernet0

nameif outside

security-level 0

ip address 10.109.114.1 255.255.255.0 standby 10.109.114.2

no shut

interface Ethernet1

nameif inside

security-level 100

ip address 192.168.209.254 255.255.255.0 standby 192.168.209.253

no shut

route outside 0 0 10.109.114.254

failover

failover lan unit primary

failover lan interface failover Ethernet4

failover lan enable

failover key 123456

failover link state Ethernet5

failover interface ip failover 10.1.0.1 255.255.255.252 standby 10.1.0.2

failover interface ip state 10.0.0.1 255.255.255.0 standby 10.0.0.2

In other words, you can connect to both the Active and Standby firewall at the same time.  Assume you allow ssh to the outside interface of the firewall, you can ssh to both the 10.109.114.1 (Active) and 10.109.114.2 (standby) firewall at the same time.

[darren.g]

david.tran@finra.org wrote:
Your way is NOT supported by Cisco TAC.  Both the Active/Standby Pix/ASA requires an unique IP address.  That's why on the Active Firewall, you willl see something like this:

Interesting you say this, because it was the Cisco TAC which first walked me through setting up using this method on a PIX some 8 years ago.

I will see if I can modify my setup (at least on the inside interface) to allow for this possibility, but for now I'm going to follow the "If it 'aint broke, don't f**k wit it" principle!

Cheers.

[darren.g]

Richard Burts wrote:
 Darren
From my perspective you have an atypical config for an ASA. I have done several ASA installs for active/standby and each of them has had an IP address for the active unit and a different IP address for the standby unit. Here is an example from one pair
!
interface GigabitEthernet0/1
 description inside
 nameif inside
 security-level 100
 ip address 172.18.179.33 255.255.255.240 standby 172.18.179.34
and with this config it is easy to establish a session to the standby unit and to copy data files to its disk.
HTH
Rick

A thought that just occured to me - how do you deal with routing in this scenario?

My ASA is connected to an internet router running BGP, and this internet router has a single, static route for our /23 subnet pointing to the IP address of the ASA's "outside" interface.

In the scenario you paint, if the primary unit fails, the secondary unit will come online - but will have a different IP address on its outside interface.

There is no dynamic routing running between my internet edge router and the ASA - do I need to either implement one, or use a weighted/floating static to route to the second ASA in the event of failure on the primary?

Inside I can live wit it - as I'm running OSPF, with the ASA originating the default route, so that's not really an issue - but how do I deal with the inbound routing to the "outside" interface?

Cheers.

[Richard Burts]

Darren

8 years ago on a PIX I can believe that TAC suggested (perhaps advocated) an implementation where there was a single IP address on an interface. Today on an ASA - not so much. But I am also a believer in the power of "if it aint broke ..." and have sympathy for your desire to leave it as it is.

Routing is not an issue and your ISP would never know if there were a failure event and the backup ASA takes over. The ASA does a very interesting thing in the failover situation. The "backup/standby unit becomes active/primary and takes over the IP address (and the MAC address) from the interface of the previous active ASA. So all connected devices (ISP, routers, switches, etc) see the same addressing no matter which device is active and there is no need for floating statics or fresh ARP advertisement.

I am a fairly old dog myself and I appreciate that sometimes we prefer the way that is familiar. And I will admit that doing the way that I suggest will require a larger block of IP addresses. (But can you tell me that the difference between a pair of /30 or a pair of /29 is going to make much difference in the IP addressing plan of your network?) But it also seems to me that there are advantages in the new approach:

- there is an enhanced failover process because the ASAs see each other and can track each other over their Inside and Outside interfaces and are not dependent on only the failover interface to detect a problem that may invoke failover.

- failover is quicker and more transparent - no need to re-ARP for addresses etc.

- and it allows you to manage each ASA, and update disk files independently.

HTH

Rick

[darren.g]

Richard Burts wrote:
Darren
8 years ago on a PIX I can believe that TAC suggested (perhaps advocated) an implementation where there was a single IP address on an interface. Today on an ASA - not so much. But I am also a believer in the power of "if it aint broke ..." and have sympathy for your desire to leave it as it is.
Routing is not an issue and your ISP would never know if there were a failure event and the backup ASA takes over. The ASA does a very interesting thing in the failover situation. The "backup/standby unit becomes active/primary and takes over the IP address (and the MAC address) from the interface of the previous active ASA. So all connected devices (ISP, routers, switches, etc) see the same addressing no matter which device is active and there is no need for floating statics or fresh ARP advertisement.
I am a fairly old dog myself and I appreciate that sometimes we prefer the way that is familiar. And I will admit that doing the way that I suggest will require a larger block of IP addresses. (But can you tell me that the difference between a pair of /30 or a pair of /29 is going to make much difference in the IP addressing plan of your network?) But it also seems to me that there are advantages in the new approach:
- there is an enhanced failover process because the ASAs see each other and can track each other over their Inside and Outside interfaces and are not dependent on only the failover interface to detect a problem that may invoke failover.
- failover is quicker and more transparent - no need to re-ARP for addresses etc.
- and it allows you to manage each ASA, and update disk files independently.
HTH
Rick

Rick.

Your reply just answered my biggest question - how the ASA's deal with the changover of the IP addressing.

Your final points are pretty valid - the ability to manage each disk seperately and faster failover (without the need for an ARP flood) are big plusses in setting up this way.

My only remaining query is how do I configure it now? Is it enough for me to just modify the current primary, and it will automagically update the current standby unit? Or am I going to have to blow away the secondary, modify the primary, and then re-establish the pair?

I can manage the additional IP addresses - owing to the way this pair *was* configured (as two individual units, with each one doing a half-arsed job of *some* of the firewalling), each subnet involved is actually already a /29 instead of a /30 - so if I can successfully get away with just adding in the additional commands and having the existing failover interface mirror the config, then I'll probably move to doing it your way - next time I can convince someone that theyr eally don't need absolute 24x7 uptime, especially when there's nobody here at 6 am!

I appreciate your input - it's thought provoking, and looks like leading this old dog to actually learning some new tricks!

Cheers.

[Richard Burts]

Darren

I have not done quite what you are facing and so can not speak from experience. But based on the experience that I do have and on my understanding of the ASA processing logic I believe that the solution is fairly simple. Just access the primary ASA and make the config changes to supply the standby addressing specification. Based on how the ASAs share the configuration I believe that the standby unit will get the config change and will apply the new standby address to its interfaces.

From one old dog to another - I say go for it - make the config change to specify the standby addressing and see what happens.

HTH

Rick

[darren.g]

Richard Burts wrote:
Darren
I have not done quite what you are facing and so can not speak from experience. But based on the experience that I do have and on my understanding of the ASA processing logic I believe that the solution is fairly simple. Just access the primary ASA and make the config changes to supply the standby addressing specification. Based on how the ASAs share the configuration I believe that the standby unit will get the config change and will apply the new standby address to its interfaces.
From one old dog to another - I say go for it - make the config change to specify the standby addressing and see what happens.
HTH
Rick

Rick.

I've now done it on the 'inside' and "outside' interfaces (not yet on my DMZ's, which are sub-interfaces on a trunk, but I'm about to), and it apepars to have not broken anything.

However, while this appears to have worked (see below), I still don't seem to be able to access the "inside" interface from my desktop.

Interestingly, I *can* access it from a switch located at the datacentre (where the firewalls are), just not from my desk at the office - although I can access the primary unit perfectly well.

Is there something I have to do to the secondary to allow access from remote hosts on the inside interface?

FW1# sh failover

Failover On

Failover unit Primary

Failover LAN Interface: failover GigabitEthernet0/3 (up)

Unit Poll frequency 1 seconds, holdtime 15 seconds

Interface Poll frequency 5 seconds, holdtime 25 seconds

Interface Policy 1

Monitored Interfaces 2 of 250 maximum

Version: Ours 8.2(1), Mate 8.2(1)

Last Failover at: 08:24:23 AEDT Nov 7 2011

        This host: Primary - Active

                Active time: 171789 (sec)

                slot 0: ASA5520 hw/sw rev (2.0/8.2(1)) status (Up Sys)

                  Interface inside (10.100.0.249): Normal

        Other host: Secondary - Standby Ready

                Active time: 0 (sec)

                slot 0: ASA5520 hw/sw rev (2.0/8.2(1)) status (Up Sys)

                  Interface inside (10.100.0.250): Normal

Thanks.

Darren

[darren.g]

Darren Gibbs wrote:
However, while this appears to have worked (see below), I still don't seem to be able to access the "inside" interface from my desktop.
Interestingly, I *can* access it from a switch located at the datacentre (where the firewalls are), just not from my desk at the office - although I can access the primary unit perfectly well.

Answering my own question.

The failover device doesn't have anything but "connected" routes in its routing table - so of course I can't connect to it remotely, because it doesn't know how to send packets *back* to me.

So, am I missing something here? From where I sit, I'm no better off than the solution I was using - slightly worse in that I now have additional IP addresses used - is there soemthing I'm *not* doing to enable me to access the standby unit?

Cheers.