By choosing group 14, you are using a 2048 bit modulus, which means that you are fulfilling the requirements of FIPS. However, if your phase 1 is not coming up, then you may need to do some troubleshooting elsewhere. In order to isolate the specific problem that you may be facing, I suggest you first configure the link using a lower end encryption mechanisms, using DH group 2 for example (as seen in this lesson), get that to function correctly, and then begin making changes to the DH group and AES encryption. As you make each change, examine the link and see which step actually causes the VPN to remain down.
Some additional resources on DH key sizes and groups can be found at this Cisco community post:
In your particular case, the ASAs are connected to the routers using their OUTSIDE interfaces. It’s important to note that the two OUTSIDE interfaces must use IP addresses in the same subnet.
If we use the ranges in the lesson, we can say that ASA1 is using 192.168.1.254, and ASA2 is using 192.168.1.253. If ASA1 is active, the IP address being used to forward traffic is 192.168.1.254. If ASA1 fails, ASA2 assumes this IP address and continues to forward traffic as if nothing has happend.
Note that this means that both OUTSIDE interfaces of both devices are in the same subnet. However, in your topology, you have connected each one to a port on a router, which means that they are by definition on different subnets. In other words, this topology would not function.
R1 and R2 should ideally be SW1 and SW2 (Layer 3) which would then give you the ability to place both connections on the same subnet and to maintain a level of HA for those two devices as well using HSRP or VSS, or some other similar technology.
So the key here is to place both OUTSIDE interfaces on the same subnet. If you wanted to achieve this using your topology, then you would have to apply something like a BVI or a BDI in order to cause the router interfaces to act as switched interfaces so that the OUTSIDE interfaces of the ASAs would be in the same subnet, but that would not be ideal.
we have received error as LU allocate xlate failed in our on Standby unit ASA5585-SSP-20. What is the possible reason to cause this error ? How to resolve the issue ?
Doing a bit of research, it may be that you are running into a documented Cisco bug where you get the error “LU allocate xlate failed” on the standby device even through there is enough memory, as you are displaying in your output. The following link to the documentation of this specific bug states that an upgrade to the ASA software may be necessary:
Upgrade ASA software means, software version 8.4(2) to higher model ?
Device manager version 6.4(5) to higher model ?
Please confirm. Please also provide steps to upgrade model .
When we talk about upgrading, we refer to the ASA Software version. In your screenshot, the software version is 8.4.2(2), and this is what must be upgraded. The Device Manager Version shown is that of the ASA ASDM which is used for GUI configuration of the ASA.
If you have a service contract with Cisco, you can download updated ASA software at the Cisco Software Download site.
What happens when 2 active asa’s units see each other? Let’s say i decouple my secondary standby unit from the network (without turning the device off), which in turn would cause it to become secondary active because it is decoupled. Now both asa’s are active. If i then re-attach the now secondary active unit to the network, will it become standby, or maintain active?
As you can see from the configuration, ASA1 is configured with the failover lan unit primary command while ASA2 is configured with the failover lan unit secondary command.
This means that if ASA2 does not detect the primary device, it will automatically become active. Once it detects the primary device once again, it will automatically become secondary/standby.
I have a pair of ASA in active / standby failover mode. My primary asa which was active became standby and the secondary became active. I would like to put in the right order, the primary becomes active again and vice versa. How do you do this without losing the connection?
The very last statement in the lesson answers your question. This statement says:
Active/standby failover does not use preemption. Once you enable the interface again, the currently active ASA will remain active.
This means that as soon as a failover takes place, once the standby ASA becomes active, it now plays the role of the primary ASA. If the first ASA comes back online, the roles are not automatically switched.
In order to return the active status to the original device, the simplest solution is to shutdown an interface on the currently active ASA that will cause a failure and will cause the other device to become active. Even though users shouldn’t perceive any network problems with such an event, it’s always best to perform this during low network traffic times or during maintenance windows.
When configuring the Active/Standby feature on two ASAs, you can specify which specific interfaces will be monitored. By specifying the interfaces, you can let the ASAs know what event will actually trigger the failover. This is done using the monitor-interface command as shown in the lesson.
So in order to see the Active/Standby failover in action, you must shutdown an interface that is being monitored by the feature. Otherwise, the failover will not be triggered.
If I have two ASAs (A/S) and the failover link fails, a switchover of roles would happen, right?
Eventhough the data interfaces see each other.
For example , the failover link fails but the INSIDE interfaces see each other.
The behavior of the pair of ASAs in an Active/Standby arrangement when various events take place, such as a failover link failure, can be found here:
Now it is possible to create multiple failover links between two ASAs, and it is best practice to use dedicated links for this purpose. However, it is possible to use the shared data interface as a failover link as well, if you have no more free interfaces. This is not recommended, as it can leave you vulnerable to replay attacks, and may also cause congestion due to large amounts of stateful traffic traversing the failover link. More information about how to create these multiple failover links, and the best practices to do so can be found here:
Active/active failover on a Cisco ASA is supported only in multiple context mode. Here are some resources that will help you to gain a deeper understanding of active/active failover:
Also, take a look at the following Cisco documentation links on setting up multiple context mode as well as active/active failover.
Finally, if you’d like to suggest a new lesson on this topic, feel free to do so on the following Member Ideas page. There you may find that others have made similar suggestions and you can add your voice to theirs.
