Hub/Spoke VPN with same subnet on spokes

Unanswered Question
May 20th, 2010
User Badges:

We are encrypting a single subnet ( subnet A ) of traffic from each branch to our HQ and also DR our site.


Each branch is connected to HQ via MPLS and to DR via MPLS, HQ and DR is connected via MetroE.


The subnet that needs to be encrypted from the branches is trunked from HQ to DR


The potential exists for the branches to send/receive to/from this subnet in both HQ and DR at the same time.


Branch to HQ is a standard VPN tunnel, encrypting subnet A with no NATing


I am thinking that I could NAT the subnet on the DR side MPLS edge router and then configure two VPN tunnels in each branch router.


I could then configure tunnel 1 access-list to send to subnet A, tunnel 2 access-list sends to NATed subnet A.


Does this sound plausable?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
gatlin007 Wed, 05/26/2010 - 07:22
User Badges:
  • Silver, 250 points or more

It’s difficult to scale a NAT solution to HQ and DR over several branches.


If you have equipment that supports GRE I would recommend developing a routing protocol relationship over GRE tunnels that are then encrypted with IPSEC.  If you aren’t using equipment that supports GRE I strongly suggest looking into acquiring some.


This will ensure the packet forwarding decision is based on a dynamic routing protocol versus a static ACL used to define ‘interesting traffic’.  Something nice to have in a DR situation.


-The packet comes into the branch router from the branch LAN

-Branch router has a route for destination address over a GRE tunnel

-Branch router has an IPSEC tunnel that matches the GRE headers.  The static ACL for ‘interesting traffic’ never had to change – It’s always matching GRE source/destination pair.

- HQ router receives an IPSEC packets and decrypts it

- The decrypted packet now has a GRE header; HQ router removes GRE header as the tunnel interface evaluates it.

- HQ router evaluates the destination address and forwards according to its route table.


Here is one example:


http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a008009438e.shtml



Best regards,


Christopher Gatlin

http://www.travelingtech.net

wilson_1234_2 Wed, 05/26/2010 - 16:16
User Badges:

Outstanding Christopher!


I actually got the NAT thing working, but I can't use it in this application.


I actually thought of what you are talking about, but I wonder if I am overly complicating things. I would like to have a dynamic solution and I think it would work,


I was thinking of doing ipsec vpn over gre.
I am not sure this would work, please tell me what you think or if you have a better idea:
I only need to encrypt one subnet, everything else can go without encryption.
We are using BGP between the branch routers and the HQ site and the branch routers and the DR site.
HQ has OSPF internally, area 0
DR has OSPF internally, area 1
If I were to configure ipsec vpn and create a gre tunnel inside that, I should be able to us OSPF for this single subnet, inside the gre tunnel.
I could advertise only the endpoint hosts thru OSPF, everything else would route via BGP.
If the traffic is sourced from HQ, that path would be used, if sourced from DR, that path would be used.
Does this sound like I am over complicating things?
Do you think this would even work?
gatlin007 Thu, 05/27/2010 - 14:04
User Badges:
  • Silver, 250 points or more

There is the possibility of asymmetric routing in and out of the tunnel and /32 routes for specific hosts will be difficult to manage.  In order to prevent asymmetric situations it’s easier to send all enterprise traffic over the GRE/IPSEC tunnel.  The security people will admire it as well.


Because there’s an OSPF area 0 at HQ and an OSPF area 1 at DR, there is the possibility of problems if HQ fails isolating the DR site from the backbone area; especially if the OSPF routing domain is extended into the branches. 


I would extend OSPF area 0 into the data center to prevent an HQ failure from separating nodes from the backbone area.  Then use the same OSPF area number for all branches over the GRE interfaces. 


Build GRE tunnels sourcing the WAN interface at the branch.  On the HQ, DR sides also use the WAN interface; this will prevent the GRE tunnel from back feeding through the other hub site.  Sometimes it’s better to use loopbacks, but in your topology stick to the WAN interfaces.


Don’t redistribute OSPF into BGP.  This will ensure enterprise traffic takes the OSPF route learned over the tunnel.  If enterprise routes are in the BGP table they will be preferred because of eBGP admin distance realized with your service provider.


If you only have a few branches I’d stick with regular GRE tunnels; if you have lots of branches consider DMVPN. 



Regards,


Christopher Gatlin

http://www.travelingtech.net

wilson_1234_2 Fri, 05/28/2010 - 13:18
User Badges:

Thanks Christopher,


Why use the same area for all of the branches?

gatlin007 Fri, 05/28/2010 - 15:25
User Badges:
  • Silver, 250 points or more

Using one OSPF area for all branches enables a ‘cookie cutter’ approach that simplifies provisioning and NOC supportability.  Functionally it works well.

The less variables the NOC has to deal with the more successful the NOC will be.  The more successful the NOC is the more time engineers have for studying for the next CCIE exam; or perhaps a beer.


Christopher Gatlin
http://www.travelingtech.net

Actions

This Discussion