Seperate L2L VPN Tunnels on Multiple External ISP Interfaces

[KatoNakatomi]

Due to special circumstances we have 2 ISP links on an ASA5510. I am trying to terminate some L2L VPN tunnels on one link and others on the second ISP Link, eg below:

LOCAL FIREWALL

crypto map outside-map_isp1 20 match address VPN_ACL_A
crypto map outside-map_isp1 20 set peer 1.1.1.1
crypto map outside-map_isp1 20 set transform-set TS-Generic

crypto map outside-map_isp2 30 match address VPN_ACL_B
crypto map outside-map_isp2 30 set peer 3.3.3.3
crypto map outside-map_isp2 30 set transform-set TS-Generic

crypto map outside-map-isp1 interface ISP_1
crypto map outside-map-isp2 interface ISP_2

crypto isakmp enable ISP_1
crypto isakmp enable ISP_2

route ISP_1 0.0.0.0 0.0.0.0  1.1.1.254
route ISP_2 3.3.3.3 255.255.255.255  2.2.2.254

Establising the VPN tunnels in either direction when using ISP_1 works fine establshing in either direction from remote access users and multiple L2L tunnels (only showing one for example).

On ISP_2

1. Peer 3.3.3.3 device establishes a VPN tunnel, but the return traffic does NOT get back to devices on 3.3.3.3 tunnel.

2. The local firewall does NOT establish a VPN tunnel going to 3.3.3.3

It would seem to indicate that the problems lies with this multihomed firewall not directing the traffic correctly to either return down and establised VPN tunnel (point1) or to intiate a tunnel if none exists (point 2).

Reconfiguring the VPN tunnel peer for 3.3.3.3 to be on ISP_1 of the local firewall, all springs into life! Any ideas, there are sufficient license etc...

[Jennifer Halim · Accepted solution]

Another route that you need is the destination subnet on VPN_ACL_B to be routed to ISP_2 as well.

So you would need to route the peer adddress (in your case 3.3.3.3) and the remote subnet (in your case destination subnet in VPN_ACL_B) to 2.2.2.254

[KatoNakatomi]

Thanks, that works

However I would have thought that the ACL applied to the CRYTO MAP would

1. Identify the interesting traffic matching to the VPN tunnel (as normal)

2. traffic identified would be routed down the tunnel not requiring routes to the remote (hidden networks) out a particular interface.

I guess in normal circumstances this route requirement is dealt \ hidden by the defaul gateway on the primary ISP_1 interfaces. Having routes in the config that indicate a local next hop would be confusing.

Agains thanks for the help, it works.

[Jennifer Halim]

Routing happens first before it gets encrypted, so it would check the routing table for the destination/remote subnet before it gets encrypted, and then routing happens again for the encrypted packet

[KatoNakatomi]

Thanks for the explanation, it helps to understand what is occuring and why.