Two tunnels in one Crypto-Map

[abatson]

I've got an ASA 5505 on my hands, with the enterprise license.  In the  example above, VPN "22" tunnel is up & passes traffic just fine.   VPN "11" won't come up.  I think I'm missing something.  is it related  to the two lines at the bottom?

crypto map MyVPN 11 match address toVPN-A

crypto map MyVPN 11 set pfs

crypto map MyVPN 11 set peer VPN-A_Peer

crypto map MyVPN 11 set transform-set ESP-3DES-MD5

-----------------------------------------------

crypto map MyVPN 22 match address toVPN-B

crypto map MyVPN 22 set pfs

crypto map MyVPN 22 set peer VPN-B_Peer

crypto map MyVPN 22 set transform-set ESP-DES-MD5

crypto map MyVPN interface outside

crypto isakmp policy 22

crypto isakmp nat-traversal 22

Thanks,

  Alex

[Marius Gunnerud]

Using the gateway across the VPN can be done in certain scenarios, mainly you will see this when using MPLS VPNs and I in GET VPN setups.  However, in this case the VPN is already setup and there is a route to the remote site IP that will be used as the gateway for locally originated traffic.  That gateway will never be used for establishing the VPN, if it is then the tunnel will be built and then dropped, built and then dropped and continue like that.

[abatson]

So, if I understand correctly, (and using my config I pasted in)....  the tunnel is terminated on the Outside interface, so I should route the traffic destined for the tunnel, to that interface's gateway.   This will get the traffic to the Outside interface but THEN it will be encrypted and sent thru the tunnel, because of the ACL, "toForestville"  so I should use:

route   DMZ    Forestville-FTP    255.255.255.255   192.168.1.1    5     (route that points down frame-relay)

route   outside   Forestville-FTP   255.255.255.255    172.26.188.1   1    (route that points the traffic to the Outside Interface, where it will be encrypted by virtue of the ACL, "toForestville", and because the tunnel is terminated on 'Outside')

[Marius Gunnerud]

Just be aware that the route pointing out the DMZ interface will never be used in this case unless the outside route is removed or its metric is increased.  If you are planning on using the DMZ route as a backup, then this would be ok.

please rate any helpful posts

[abatson]

Now the big question...  if I route traffic into the IPSEC tunnel by sending it to the 172.16.188.1 gateway (on the Outside Interface),  will this static route be deleted from the routing table when the tunnel goes down?

I need the ASA to detect a  failure of the IPSEC tunnel, then use the higher-cost route over the frame-relay.  In other words, I need it to act like a router --- when a path goes away, delete the route for it, until that path returns....

[Marius Gunnerud · Accepted solution]

If the tunnel goes down the route will still be in place. You would need to create a track object that tests reachability over the VPN and associate it with the route that sends traffic over the vpn.  Then if the remote destination is not reachable the route will be removed and the route with higher netric will take over

[abatson]

I've downloaded & read the Cisco article regarding setting up 'dual ISP redundancy', which deals with setting up a track object.   I can do that, but that will result in asymetric routing on the remote end.  (My side have moved from IPSEC to frame-relay, and the remote side is routing return traffic toward the tunnel (which is down))

Or, I guess I could set up a track-object which is something that is only available at the other end of the tunnel, (and set it that way on both sides), so that when the tunnel goes down, the routes on BOTH sides change properly, and then packets travel over frame-relay until the tunnel comes back up.

I bet 'dual-ISP redundnacy'  isn't written to deal with asymentry, since  that wouldn't be an issue, if you had two ISPs attached to the ASA.  Sending traffic into two different  ISPs is different than sending traffic to a remote site, where the packets have to come back on the same path.

Too bad this doesn't behave like a Juniper SRX firewall running JunOS.   The tunnel is assigned an interface name, and you can use that interface name explicitly when building a routing statement.  When the tunnel goes away, the routes pointing down the tunnel also go away.

[Marius Gunnerud]

Well, that goes without saying that if you set up tracking at one end then you have to ensure that the remote end also knows what to do when the IPsec tunnel goes down.

You can configure the ASA to ignor the asymetric routing by using TCP bypass.  This alows the ASA to ignor the TCP state.  Keep in mind that you still need to allow the traffic in the ACL on the frame-relay interface.

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_tcpstatebypass.html

[abatson]

It looks like if I'm sticking with a Cisco product for this, I need to use the tracked-object method to turn on/off the static routes into the IPSEC tunnel.   I guess we're done here,  thanks for all the help!    I'll be back when I need more help!