ASA/ASA site-to-site as a backup link

[jlmickens]

I've been tasked with implementing a plan to utilize a site-to-site vpn link as a backup link to remote offices.  I'm trying to simulate the solution in a lab, but am having some trouble with it. Currently our offices enjoy a point to point fiber link.  The site-to-site VPN will act as a backup if that link should happen to fail.

The sites are using OSPF to establish routing between the core router at the HQ and the L3 switch at the remote site.  I have static routes set up with a metric of 250 that will kick in if the link goes down and the OSPF routes are withdrawn.  The static route goes to the ASA devices.  Once the link is down, the OSPF routes drop, and the statics kick in (this all works fine), sending the traffic to the ASAs, which then establish the VPN tunnel between the sites. With the logging at debug, I can see connections being built and tore down normally, and from both ASAs it looks like traffic is flowing, but it's not.  I can't ping across, and nothing is connecting.  My test desktop, printers, etc, all lose connection to the HQ side and won't function.  I don't get any deny messages on the ASAs.

I have a site to site with a vendor utilizing the same ASA at the HQ, and that works fine.  All VPN settings were created using the ASMD VPN wizard.

Both ASA's are running 8.3.  Both ASA's have their default route set to the outside.

Any suggestions on where to look would be appreciated.  The HQ utilizes several different subnets, all of which need to be accessed from the remote site.  The VPN is set for all 4, but if I look at the sa (sh crypto ipsec sa), it only shows me one.  However, the client tunnel that works is utilizing 2 on the HQ side and is working.  Am I trying to much with 4?  Should I try building 4 separate VPNs, one for each subnet?

[blarragu · Accepted solution]

Hello,

You should be fine with 4 different statements within your interesting traffic ACL on the 5505.  One thing I noticed is that the 5505 is getting its IP via DHCP, so I am assuming you have a dynamic-static L2L type of a setup.  With this type of setup, the tunnel will always need to be initiated from the 5505 (dynamic) side.  One thing to look at is to verify that your NAT statements are ordered correctly.  With 8.3, the order of NAT is very important.

nat (inside,outside) source dynamic any interface
nat (inside,outside) source static NETWORK_OBJ_10.107.0.0_16 NETWORK_OBJ_10.107.0.0_16 destination static DM_INLINE_NETWORK_1 DM_INLINE_NETWORK_1

If the dynamic NAT is before the VPN NAT rule, the VPN NAT rule will never take effect.  You should be able to issue the command "show nat" or "show run nat" to verify that the VPN NAT comes before the dynamic NAT.  If the dynamic NAT shows up before the VPN NAT rule, you would want to remove the dynamic NAT rule and re-apply.

Some good troubleshooting commands are to verify that phase 1/phase 2 is up on both sides and that you see phase 2 encaps/decaps:

show cry isa sa

show cry ips sa

Thanks!
Brian

[jlmickens]

The DHCP was my only choice, as my lab is using a cable modem for the internet connection.  The traffic would generally be intiated at the remote office end, so that shouldn't be an issue.

As far as the NAT is concerned, I think the general dynamic NAT is in the 5505 by default.  I didn't use the cli to configure, so really had no control over what order they went in.    A sh nat gives me:

FWRR# sh nat
Manual NAT Policies (Section 1)
1 (inside) to (outside) source dynamic any interface
    translate_hits = 756, untranslate_hits = 15
2 (inside) to (outside) source static NETWORK_OBJ_10.107.0.0_16 NETWORK_OBJ_10.107.0.0_16 destination static DM_INLINE_NETWORK_1 DM_INLINE_NETWORK_1
    translate_hits = 0, untranslate_hits = 77
Auto NAT Policies (Section 2)
1 (inside) to (outside) source dynamic obj_any interface
    translate_hits = 0, untranslate_hits = 0

So you're saying that the number 2 above should be before the number 1, correct?

[blarragu · Accepted solution]

That is correct.  Nat statement 2 should come first.  You would just need to remove/re-add the dynamic NAT using following commands:

no nat (inside,outside) source dynamic any interface

nat (inside,outside) source dynamic any interface

This should remove and re-apply the dynamic NAT statement after the VPN NAT exemption statement.

Thanks!
Brian

[jlmickens]

Thanks!  That did the trick.

I think I still have a couple of routing issues going on, but almost everything is working at this point.

[jlmickens]

I'm still working with this same scenario.  I've got just about everything working.  When the main link drops, the traffic reroutes to the VPN over the ASA

and everything works great.  The one last issue I'm having now is that I can't access the ASA directly from the HQ side. I need to be able to access these devices once they are in the field.

I believe this is due to the default route being the outside interface.  When the link is up and working, the traffic would have to route to the inside interface instead of the outside.  As such, I'm trying to set up a default route with a monitor.  The IP address I'm monitoring would only be accessible when the main link is up, via the inside interface (10.99.0.101 in the diagram above).  When I try to add the monitored default route, I get:

(config)# route inside 0 0 10.107.0.1 track 101
ERROR: Cannot add route entry, conflict with existing routes

According to the documentation, this should be doable.  I should be able to have up to three default routes.  The only other default route is out the outside interface and is obtained via DHCP.  A show route reveals:

C    24.53.128.0 255.255.224.0 is directly connected, outside
S    10.107.0.0 255.255.0.0 [1/0] via 10.107.0.1, inside
C    10.107.0.0 255.255.255.0 is directly connected, inside
S    10.99.0.0 255.255.255.0 [1/0] via 10.107.0.1, inside
d*   0.0.0.0 0.0.0.0 [1/0] via 24.53.128.1, outside

I've posted a new question regarding this here.  Since this one is marked as solved, I figured it probably wouldn't get looked at much.