05-19-2010 03:09 AM - edited 03-06-2019 11:10 AM
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
Solved! Go to Solution.
05-19-2010 03:16 AM
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
05-19-2010 07:10 AM
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
05-19-2010 03:16 AM
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
05-19-2010 03:44 AM
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.
05-19-2010 04:28 AM
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
05-19-2010 04:53 AM
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
05-19-2010 05:05 AM
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
05-19-2010 06:54 AM
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
05-19-2010 07:10 AM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: