DMVPN or Firewall-Based VPNs?

One of my readers sent me this question:

I'm having an internal debate whether to use firewall-based VPNs or DMVPN to connect several sites if our MPLS connection goes down. How would you handle it? Do you have specific courses answering this question?

As always, the correct answer is it depends, in this case on:

How much spoke-to-spoke traffic you have and whether you’re OK with that traffic passing through the central site.

Traditional IPsec-based VPN implementations use point-to-point tunnels to implement a hub-and-spoke connectivity model in which all the traffic between remote sites (spokes) passes through a central site (hub).

Most MPLS/VPN and DMVPN implementations use any-to-any connectivity model in which any two spokes can communicate directly without the traffic passing through the hub node.

Some firewall vendors support ADVPN, a standard alternative to DMVPN. However, while the point-to-point IPsec VPNs are ubiquitous, the ADVPN implementations are not so common. Instead of choosing between firewall-based VPN or DMVPN, you have to choose between many-vendor point-to-point or one-or-few-vendor multipoint solution.

Migrating from any-to-any connectivity to hub-and-spoke connectivity introduces additional latency, and increases the bandwidth requirements of the central site – the firewall terminating point-to-point hub-to-spoke tunnels has to handle all spoke-to-spoke traffic.

How easy it is to set up additional VPN tunnels and how many spokes you have.

Some VPN implementations require additional configuration for every spoke. Other implementations support dynamic VPN tunnels created from configuration templates.

If you have to configure each VPN tunnel on your firewall and have a significant number of spokes, I’d highly recommend automating the firewall configuration management by creating VPN configurations from a VPN data model and configuration templates. Numerous students of my Building Network Automation Solutions online course decide to do that as one of their homework assignments.

Of course it’s always possible to use a single-pane-of-broken-glass solution from your preferred $vendor.

On the other hand, you can make DMVPN configuration almost spoke-neutral – adding a new spoke does not require any changes on the hub routers.

Dynamic load balancing. It’s reasonably easy to perform application-based policy-based routing (assuming your device supports it) if you terminate VPN tunnels and MPLS connections on the same devices (regardless of whether you call them routers or firewalls), and if you believe in IWAN you could get some sort of centralized policy with PfRv3 (or through an orchestration system like Gluware). Getting the same results in a firewall(VPN)+router(MPLS) combo is interestingly complex.

This problem can also be solved with yet another layer of abstraction called SD-WAN.

The Relevant Webinars

Some of the basic differences between various VPN solutions are covered in the Choosing the optimal VPN service webinar, and DMVPN is covered in great details in various DMVPN webinars.

If you want to become fluent in network automation, there’s probably no better solution than the Building Network Automation Solutions online course. If you want to start small go for the Ansible for Networking Engineers online course.

4 comments:

  1. Most firewall vendors support ADVPN these days so it's down to preference / budget ;)
    Replies
    1. And this is why I love writing blog posts ;)) I always learn something new.

      Reworded the blog post (although I still somewhat disagree on the "most" part of your statement).
  2. I sometimes have to smile when network engineers talk about firewalls :) I am a security engineer and all major enterprise firewalls have had meshed VPNs (e.g. direct spoke to spoke without the need to go through the hub) for many years, long before the terms DMVPN and ADVPN were even created ;)

    Checkpoint, Juniper, Paloalto, Fortinet, you name it... they all had it for like... forever :)
    Replies
    1. Hmmm... it might be worth considering whether it's their ignorance, or whether they have hidden assumptions that are not obvious from their question (like "having low-end router at remote end" or "having to run routing protocol over the VPN").

      In any case, would you agree with my assertion that it's either one-or-few-vendor full-mesh VPN, or any-to-any-vendor P2P IPsec VPN?
    2. Oh yeah, absolutely, I agree with that. No Checkpoint is ever going to do a meshed VPN with, say, a Fortinet. Unless you use ADVPN.
  3. Thanks for posting this.

    Do you see much traction with RFC6407 GDOIv2? In principle it interoperates statelessly between C & J...

    https://www.juniper.net/documentation/en_US/junos/topics/concept/vpn-security-group-overview.html
    Replies
    1. I'm not exactly a VPN person, but no, I don't.
  4. There is a gross misconception about ADVPN being a standard. There was just a problem statement (RFC-7018) and it was intentionally not called DMVPN to avoid an existing term. There were two (main) solution proposals to the problem statement https://datatracker.ietf.org/doc/draft-detienne-dmvpn/ and https://datatracker.ietf.org/doc/draft-sathyanarayan-ipsecme-advpn/ but there was no standardisation of the solution. So, the problem statement became an RFC and it was left there.

    Both options have the draft document in public domain but there are, in fact, more implementations of DMVPN (Juniper, HP, Brocade, Huawei, open source, etc) than ADVPN; just that the names are different. Also, basic DMVPN still uses fully standardised protocols (NHRP, IPsec/IKE, GRE) so an implementation of these as per standards should be able to inter-op. ADVPN, on the other hand uses some notifications/payloads that were never standardised!

Add comment
Sidebar