IPSec, go tech!

[splitice]

Nothing to see here, just some much needed self-gratification. Geek content ahead.

Finally got pure IPSec tunnels working at X4B. Woot Woot! (Ok so probably not all that exciting to many people)

For those who arent aware "pure ipsec tunnel" is referring to the tunnel mode of IPSec, as apposed to IPSec Transport mode + GRE (or anything else). IPSec Tunnel mode is supported on many edge routers and is even technically supported natively by Windows (its a poorly documented feature, and relies on two hard to find and almost undocumented C WINAPI calls). It is also lighter weight than nesting protocols as it works via nesting the full (encrypted) IP payload inside the IPSec (and IP) datagram - this is similar to IP-in-IP. Its really IP-in-IPSec-in-IP

As @Francisco knows this has been a goal I have had for a very long time. I first started trying to get it working almost 2 years ago, spending many hours with him on IRC. Windows & Linux support, full encryption and automated setup for both platforms.

Side note, no FreeBSD automated setup yet, not sure if I will get around to automating that... its a bit more complex.

 

[Francisco]

BSD is a pain in the butt usually. The parameter order for GRE tunnels for instance is quite odd.

So what was the major road block? Doesn't the Windows IPSEC setup work in pure tunnel mode, or I guess it's riding on L2TP?

I'm pretty green when it comes to IPSEC so I'm not very well versed in it I can make it work but a lot of it still makes me go "Buh?"

Francisco

 

[splitice]

@Francisco Windows has two modes of operation IPSec + L2TP (one API) and plain IPSec (one almost undocumented API). Plain IPSec is almost impossible to find details on, even within MSDN. Its a part of a MCP certification, so there is some basic details around but nothing relevant to Linux communication - or even really anything that technical at all. Additionally no documentation in regards to the parameters supported or needed on either end, barely any documentation the WinApi's and the command line utility actually has a bug (over restrictive verification of valid parameters, winapi works). And error logging? Nope. TL;DR Basically lots of pain points.

TBH, Tunnel mode is really intended for edge routers joining distinct networks over the internet / insecure networks, not really something people do on Windows... usually. So yeah, this is probably a pretty novel use (tunnelling /32 networks) of the feature. I had a feeling it would work, just had to figure out how to make it do so.

Linux isn't exactly a walk in the park either, especially to automate with both Openswan and Strongswan available. Strongswan is supposedly backwards compatible, but the default values of a couple fields can cause issues.

And if your masochistic then you throw in NAT Traversal. Whomever designed NAT-T for IPSec was a cruel bastard.

Fortunately, I think I have a pretty decent understanding of IPSec now. It's rather impressive when it works. But its not something you want to mess with without a very good networking and OS understanding. Still the benefits of end to end encryption between points (such as a filtering service and backend) are hard to ignore.

 

[blergh]

Interesting. But why?

 

[splitice]

@blergh that seems like more of an argument for Pure IPSec tunnels than against it.

Transmission in plaintext for security critical data should be avoided. GRE & IP-in-IP (the standard for tunneling protocols) are un-encrypted unless IPSec transport is used, an IPSec Tunnel is another method (less layered, simpler). Offtopic - Everyone know PPTP is insecure, L2TP (not used in a pure IPSec tunnel) is the supposed upgrade.

sec as a protocol seems to create slightly more trouble for the spies. But the NSA has the resources to actively attack routers involved in the communication process to get to the keys to unlock the encryption rather than trying to break it, courtesy of the unit called Tailored Access Operations: "TAO got on the router through which banking traffic of interest flows," it says in one presentation.

To everyone in the industry, IPSec has no major vulnerabilities and is considered extremely secure when used with a secure encryption algorithm such as AES. If a TAO is required to break a router at either end it doesnt matter what encryption you are using, any encryption is broken if the malicious party has the key. That the NSA needs to resort to breaking into the machine to get access to its data is a good thing, it means the encrypted data is hence secure in transit.

 

[blergh]

My main worry would be the storing of old traffic/handshakes/etc for them to use/decrypt at a later time. I´ll just stick to being a butthurt basementdweller thinking the intertubes is just for me to play with.