VPN between Concentrator & Router

All,

I would appreciate any help on this - been looking at it all day.

I have a remote site LAN 192.168.143.0 /24, with 2 x routers. One of the routers connects to the HQ via the Internet, the other router, on the same LAN, connects to the Head Office via a Concentrator in a Co-Lo. On the Inside of the Concentrator I have a 2800 router that connects to an MPLS network.

(Internet Route) Remote Site----VPN Concentrator---2800 Router-----MPLS----/ (router 1) / / Head Office / / Remote site----------------------MPLS--------------------/ (router 2) (MPLS route)

The Head Office has 2 x routers as well.

I have been trying to figure out how to dynamically learn the route to

192.168.43.X /24 on the Concentrator so that I can push it out to the 2800 and onward advertise it into my Head Office via the MPLS network.

Not being a Concentrator guru, I have been through various options (reverse route injection) etc to advertise the remote route to my Head Office but nothing that convinces me that i am doing it correctly.

I need this to be dynamic as I am policy routing. Most of the traffic will go over the VPN. If the VPN fails I need all traffic to re-route via the active MPLS connection.

At present I find that my Head Office site sees the VPN as even after I 'pull' the Internet connection out. This blackholes the traffic instead of detecting the VPN failure and routing it all via the MPLS.

In summary my question is how I detect the remote LAN presence on my Concentrator to advertise it to my 2800. Furthermore, how I successfully detect the VPN failure so I can ensure that any dynamic routing is removed from he Concentrator routing table.

Regards

Darren

Reply to
Darren Green
Loading thread data ...

Concentrator to advertise it to my 2800

The VPN 3000 concentrator supports static routes, RIP and OSPF If you use EIGRP, then suggest the use of RIP which you will need to redistribute into EIGRP on the first router upstream form the concentrator on which you will alos need to enalbe RIP{.

Reply to
Merv

One problem with redistribution is that your administrative distance is no longer the same (although is configurable), and you are still dependant on a static route somewhere in the scheme.

I actually recommend a slightly more complex solution using GRE (although not too complex) but seems to work a lot better in my opinion. Since IPSec tunnels don't support any routing protocols you'll either have to use purely static routes, or redistribute static routes from the concentrator on the inside. In either case, you're still dependant on static routing being redistributed. Not to mention the other end (the branch office) still doesn't have dynamic routing with this option.

I find that a GRE tunnel does the trick. You'd have to make the VPN router a GRE tunnel end point, and the 2800 router on the inside of the concentrator a GRE end point. There is lots of documentation on Cisco's site about using GRE. Some solutions you'll find piggyback on the IPSec configuration, using the same end points as the IPSec end points for GRE. This is fine if you are using two routers for IPSec, but a concentrator does not support itself being a GRE end piont. So when looking through various documentation, be aware that this is not really GRE over IPSec, its completely independent from your IPSec tunnel; however, does pass through the IPSec tunnel.

With GRE you can run OSPF, EIGRP or just about any other routing protocol you may be using.

By doing this you can effectively send your routing protocol through the IPSec tunnel -- this opens many doors that you just can't do with static routing, even being redistributed. You can perform automatic load balancing or any other features of your dynamic protocol you may want to do - it could at this point be treated as if it were a regular point-to-point office.

Ryan

Reply to
rdymek

Ryan,

Thanks for the response and to Merv as well in the earlier post.

I will re-work the config along these lines.

Regards

Darren

Reply to
Darren Green

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.