Category: IPsec

The last bits of updated Never-Ending Story of IP Fragmentation were published a few days ago: IP fragmentation and tunnels and summary and related blog posts, RFCs and other articles.

In previous Software Gone Wild episodes we covered Snabb Switch and numerous applications running on it, from L2VPN to 4over6 gateway and integration with Juniper vMX code.

In Episode 98 we focused on another interesting application developed by Max Rottenkolber: high-speed VPN gateway using IPsec on top of Snabb Switch (details). Enjoy!

Some engineers solving the original challenges Johannes posted complained that they were too easy, so he created another scenario: find out what’s wrong in an IPsec setup using just the captured traffic. Good luck!

My friend Christoph Jaggi published new versions of his Metro- and Carrier Ethernet Encryptor documents:

• Technology introduction, including an overview of encryption mechanisms, Carrier Ethernet connectivity models, typical deployments, and key management challenges.
• Market overview, including standards, control- and data plane considerations, key- and system management, and network integration.

Enjoy!

Christoph Jaggi has just published the third part of his Metro- and Carrier Ethernet Encryptor trilogy: the 2015 market overview. Public versions of all three documents are available for download on his web site:

• Introduction to Metro- and Carrier Ethernet Encryption
• Evaluation Guide for Metro- and Carrier Ethernet Encryptors
• Metro- and Carrier Ethernet Encryptors: 2015 Market Overview

Christoph Jaggi, the author of Metro Ethernet and Carrier Ethernet Encryption Market Overview published an awesome follow-up document: an evaluation guide that lists most of the gotchas one has to be aware of when considering encryption gear, from deployment scenarios, network overhead and key exchange details to operational considerations. If you have to deal with any aspect of network encryption, this document is a must-read.

Someone recently sent me this scenario:

Our CIO has recently told us that he wants to get rid of MPLS because it is too costly and is leaning towards big Internet lines running IPSEC VPNs to connect the whole of Africa.

He was obviously shopping around for free advice (my friend Jeremy Stretch posted his answers to exactly the same set of questions not so long ago); here are the responses I wrote to his questions:

Jason Edelman wrote a great blog post after watching Ethan Banks struggle with yet another multi-vendor IPsec deployment. Some of his ideas make perfect sense (wiki-like web site documenting working configurations between vendor X and Y for every possible X and Y), others less so (tunnel broker – particularly in view of recent Tor challenges), but let’s step back a bit and ask ourselves “Why is IPsec so complex?”

Dual-stack exposures were the last topic Eric Vyncke and myself addressed in the IPv6 security webinar. They range from missing ip6tables on Linux hosts to unintentional split-tunnel VPNs and missing access classes on Cisco IOS devices.

Two years ago I wrote the another Fermatish post: I described how NHRP behavior changed in DMVPN networks using NAT and claimed that it might be a huge problem, without ever explaining what the problem is.

Fabrice quickly identified the problem, but it seems the description was not explicit enough as I’m still getting queries about that post, so here’s a step-by-step description of what’s going on.

Short answer: yes, it does.

During the geeky chat we had just after we’d finished recording the Data Center Fabric Packet Pushers podcast, Kurt (@networkjanitor) Bales asked me whether the MPLS/VPN-over-DMVPN scenarios I’m describing in Enterprise MPLS/VPN Deployment webinar really work (they do seem a bit complex).

I always test the router configurations I use in my webinars and I usually share them with the attendees. Enterprise MPLS/VPN Deployment webinar includes a complete sets of router configurations covering 10 scenarios, including five different MPLS/VPN-over-DMVPN designs, so you can easily test them in your lab and verify that they do work. But what about a live deployment?

After I made the “duct tape of networking” joke, I quickly became a GRE lover (according to @Neelixx – another Twitter account lost in the mists of time). Jokes aside, let’s see where it makes sense to use GRE.

Last days I was eating, drinking, breathing and dreaming DMVPN as I was preparing lab scenarios for my DMVPN webinar (the participants will get complete router configurations for 12 different scenarios implemented in an 8-router fully redundant DMVPN network).

Some of the advanced scenarios were easy; for example, I’ve found a passing reference to passive RIPv2 with IP SLA in the DMVPN/GETVPN Design & Case Study presentation (lost in the mists of time). I knew exactly what the author had in mind and was able to create a working scenario in minutes. Unfortunately, 2-tier hub site with IPSec offload was a completely different beast.

To understand the principles of DMVPN Phase I, remember these facts:

Arnold sent me an excellent question yesterday; he bought my Deploying Zone-Based Firewalls book, but found no sample configurations using IPSec VPN. I was able to find a few sample configurations on CCO, but none of them included the self zone. The truly interesting bit of the puzzle is the traffic being received or sent by the router (everything else is self-explanatory if you’ve read my book), so those configurations are not of great help.

Realizing that this is a bigger can of worms than I’ve expected, I immediately fixed the slides in my Choose the Optimal VPN Service webinar, which now includes the security models for GRE, VTI and DMVPN-based VPN services.