Route Manipulation Through IPsec VPN's

[AJAZ NAWAZ]

  

Requirements:

1. RT-A and RT-B can be setup for HSRP or GLBP groups, or IGP routing on the LAN side

2. Voice traffic (i.e rtp streams) must be transported symetrically through RT-B<>ASA-B

3. If RT-B<>ASA-B VPN goes down - then traffic should failover to RT-A<>ASA-A VPN

4. Data&Wireless traffic must be transported symetrically through RT-A<>ASA-A VPN

5.  If RT-A<>ASA-A VPN goes down - then traffic should failover to  RT-B<>ASA-B VPN

6. Static routes are being redistributed on the core swithces into OPSF

How can deterministic routing through VPN's be made possible without GRE tunnels or DMVPN. There are so far two ideas in my mind. The first is perform srcNAT on the remote LAN subnets down one of the VPN's. The second is IPsla in some form on ASA's or router/switches. This is slightly complicated due to the SSG being in place at DC-A which is setup with static routing.

any more ideas?

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

thanks

Ajaz

[Jon Marshall · Accepted solution]

anawaz wrote:
Requirements:
1. RT-A and RT-B can be setup for HSRP or GLBP groups, or IGP routing on the LAN side
2. Voice traffic (i.e rtp streams) must be transported symetrically through RT-B<>ASA-B
3. If RT-B<>ASA-B VPN goes down - then traffic should failover to RT-A<>ASA-A VPN
4. Data&Wireless traffic must be transported symetrically through RT-A<>ASA-A VPN
5.  If RT-A<>ASA-A VPN goes down - then traffic should failover to  RT-B<>ASA-B VPN
6. Static routes are being redistributed on the core swithces into OPSF
How can deterministic routing through VPN's be made possible without GRE tunnels or DMVPN. There are so far two ideas in my mind. The first is perform srcNAT on the remote LAN subnets down one of the VPN's. The second is IPsla in some form on ASA's or router/switches. This is slightly complicated due to the SSG being in place at DC-A which is setup with static routing.
any more ideas?
------------------
thanks
Ajaz

Ajaz

Personally i would do src NAT down the tunnel if NAT works with all the applications. That way as you say traffic will automatically be sent back via the same way. I would source NAT on the ASA at the DC end so return traffic within the DC is sent back to the correct ASA.

One question though. How were you proposing to split the traffic from the LAN (ie the outbound traffic from the Branch)  to go to the right router ? PBR, different default-gateway ?

Edit - the advantage of Natting source IPs at the ASA is that within the DC you do not need to configure PBR, IP SLA etc. to make sure the traffic is sent back to the correct ASA. You only need to make sure that traffic is sent from the branch through the correct VPN.

Edit 2 - you still may need to use IP SLA within the Branch site to determine when to switch to the other VPN tunnel.

Jon

[AJAZ NAWAZ]

I agree Jon - srcNAT is a more elegant (if you can call it that), proposal the IPsla. I've used IPsla and it works fine - but not nice for the support folk.

[JM] One question though. How were you proposing to split the traffic from the LAN (ie the outbound traffic from the Branch)  to go to the right router ? PBR, different default-gateway ?

err... unless i'm missing something I was planning on setting up EIGRP at the branch inc switch - route control being the main driver. Although PBR did cross my mind I did that about that very briefly, but remember the routing has to be fault tolerant.

thanks for your input Jon.

[Mohamed Sobair]

Hi,

You can cosider the following:

Multiple HSRP groups on the LAN, voice traversing the router - B path while date traversing router-A path. IP - Sla on both router to make sure traffic is redirected if one of the IPsec VPN goes down.

you will need to make sure on the return path voice prefering path B IPsec VPN, this could simply be done by adding two static routes on the core , one with higher AD and redistribute them into OSPF. the Same applies for the DATA and wireless traffic.

Note:

Both ASAs should have all Networks (Voice , Data and wireless) permitted -- Interesting traffic.

HTH

Mohamed

[AJAZ NAWAZ]

hello Mohamed

In terms of IPsla what endpoint would you suggest we could perhaps monitor?, remember a default route out to the internet must exist at all times.

Ajaz

[Mohamed Sobair]

Hi Ajaz,

From both WAN Networks, and since you have IPsec VPN the ideal is to monitor the Router LAN interfaces from the Core and ASA's LAN interfaces  from the Router's side.

HTH

Mohamed

[AJAZ NAWAZ]

Mohamed,

You've actually raised quite a good point, but I'd be inclined to use hsrp object tracking at the branch office with srcNAT as a final solution. I just think it's a much neater solution. I don't know why, but I frown when it comes to IPsla :-/

Ajaz

[Mohamed Sobair · Accepted solution]

Ajaz,

Both will work just fine, I have give you an example of the other way around. I have designed/implemented and proposed a setup closely to yours with some differences to one of the cllients and it works pretty good.

Now, I have recently  implemented  SRc NAT for almost similar setup to one of my clients, and it also works well, this will also ensure some sort of security if you want to restrict traffic destined from the Core to your LAN (voice , wireless and Data).

Its just a proposed solution,

Mohamed