Routing – What are the reasons for choosing separate or combined VPN and Internet routers

designroutingvpn

Here's a network design question: I've just been reading "IPv6 for Enterprise Networks" by McFarland et. al. and it (among other Cisco documents) separates out Internet routing from remote access VPN. What are the advantages and disadvantages of using separate routers for remote access VPNs vs. general Internet traffic, assuming they go through the same uplink?

And as a secondary issue, what are the advantages or disadvantages in splitting out site-to-site and road warrior VPN between different routers?

(The VPN in my specific case is OpenVPN running on Vyatta, but from my perspective this is more about the design than the technology choice.)

Best Answer

There's a bunch of stuff to consider here, although a lot of it depends on your environment.

First, device flexibility. If there's an emergency update that needs a reboot of the device to take effect, are you ready to take down the combined services to deal with that update? This can become a rabbit's hole of "what if?" scenarios but it's something to think about.

Secondly, performance. Will a single device handle the encryption traffic and the routing? Will it do so for the lifetime of the product? Are you going to end up buying a "big" single replacement box because one of the functions needed more horsepower, where a "medium" and "small" box would do if they were separate?

Redundancy - this ties in to the flexibility point, do you require redundancy on any of these devices? Is it easier to maintain a single HA pair rather than multiples? Perhaps HA is only required for specific functions.

Routing - this can be fun if you've got separate devices bringing traffic in to the environment. Are they all aware of each other? Are they all aware of the (possibly) multiple paths available to each other? Simplifying down to less devices can be beneficial here, but if your environment isn't this involved you may never have to worry about it.

Additional services - are you running firewalling, traffic inspection, or threat prevention on these remote links? Are you going to need an additional "protection" box for every service you break out from the main device?

Those are some of the primary things we consider. In my opinion there isn't a simple "always do it this way" answer for this one.

Related Solutions

Cisco – Placement of firewall for VPN RA and L2L tunnels

Should the inside interface of the 5545 land first on the L2 edge switches and then trunk to the agg switches for better security or just have the inside drop straight into the Agg layer, also considering that private line traffic may come through yet another interface on the 5545 in the future

Since you did not say that the L2s would be running ACLs, I would not see a difference. I am guessing you will run tagging on the inside ASAs to the distribution layer. My firewalls connect directly to aggregation switches with a dedicated vlan that runs HSRP/VRRP between each set of firewalls and the agg switches.

As to private line traffic, I do not use ASA but I think they have the zones construct like IOS ZBF and you will keep VPN traffic from going to/from the private line traffic without going through packet filtering.

It sounds like default route points to the 5540 and you will use more specific routes to get to your internal VPN access pools and the private line addresses. The 5545 has the default route pointing to the 5540 and it is ok for VPN traffic to hit the internet directly (don't know if you split tunnel on your VPN clients) and other routes to your internal address space.

So I can not see any real problems with your plan. But some of my above assumptions may be wrong

Quagga OSPF – DR/BDR Mismatch and Losing Routes

To answer your question directly, this is expected behavior by OSPF and not a bug in Quagga.

So first, let's take a look at the DR/BDR section of the RFC.

Designated Router
    The Designated Router selected for the attached network.  The
    Designated Router is selected on all broadcast and NBMA networks
    by the Hello Protocol.  Two pieces of identification are kept
    for the Designated Router: its Router ID and its IP interface
    address on the network.  The Designated Router advertises link
    state for the network; this network-LSA is labelled with the
    Designated Router's IP address.  The Designated Router is
    initialized to 0.0.0.0, which indicates the lack of a Designated
    Router.

Backup Designated Router
    The Backup Designated Router is also selected on all broadcast
    and NBMA networks by the Hello Protocol.  All routers on the
    attached network become adjacent to both the Designated Router
    and the Backup Designated Router.  The Backup Designated Router
    becomes Designated Router when the current Designated Router
    fails.  The Backup Designated Router is initialized to 0.0.0.0,
    indicating the lack of a Backup Designated Router.

If the BDR field in the Hello packet header is set to 0.0.0.0, it means you do not have a BDR elected.

In your case this is because you have your other router set to a priority of 0, this makes the router ineligible to become a BDR (this is why you see "DROther" and not "BDR"). You just need to set the priority on your other router to something that isn't 0.

Here is the other piece from the RFC for some more context.

Router Priority
    An 8-bit unsigned integer.  When two routers attached to a
    network both attempt to become Designated Router, the one with
    the highest Router Priority takes precedence.  A router whose
    Router Priority is set to 0 is ineligible to become Designated
    Router on the attached network.  Advertised in Hello packets
    sent out this interface.

https://www.ietf.org/rfc/rfc2328.txt

Best Answer

Related Solutions

Cisco – Placement of firewall for VPN RA and L2L tunnels

Quagga OSPF – DR/BDR Mismatch and Losing Routes

Related Topic