
Show HN: VPN-Contained-IPSec-Basic - davidgatti
https://github.com/0x4447/0x4447-product-vpn-contained-IPSec-basic
======
wahern
Cloud computing... fun times. FWIW, IPSec+IKE can actually be quite simple.
For example, here's the _lone_ configuration line from /etc/iked.conf needed
to create a VPN tunnel using OpenBSD:

    
    
      ikev2 "home-to-colo" quick active esp \
        from 1.2.3.4 to 0.0.0.0/0 \
        peer yournode.cloudvendor.com \
        ikesa auth hmac-sha2-256 enc aes-128 prf hmac-sha2-256 group curve25519 \
        childsa enc aes-128-gcm group curve25519 \
        psk "some password"
    

That's the whole of it beyond enabling the iked service at startup. The other
side of the above tunnel (taken from a working example, names changed to
protect privacy) is exactly the same except the flows are reversed (from
0.0.0.0/0 to 1.2.3.4) and its configured for passive mode (waits for someone
to connect and claim the flow for 1.2.3.4). The above tunnel is actually used
to give my home router a static IP address (1.2.3.4), routed through a vultr
VM. vultr let's you add up to 2 additional IP addresses to a $5/month
instance.

An X.509-based PKI setup is just as easy, other than generating and signing
the certificates.

It's actually easier than using Wireguard, IMHO. Now, if you want to be
interoperable with random vendors you have to be mindful of which cipher
suites are supported. Few IPSec implementations support curve25519, for
example. I manually specify the ikesa and childsa cipher suites in the above
to ensure that the negotiated ciphers will be hardware accelerated on my
PCEngines APU2, but also to prove that IPSec can use the latest cipher modes
like aes-gcm and curve25519. OpenBSD even supports chacha20-poly1305 if you
wanted to be really hip. But aes-128 + SHA-256 + one of the ECDSA groups (I
forget which one) is supported by all modern BSD, Linux, macOS, Windows, and
iPhone implementations, so in 2019 near universal support is actually quite
easy to achieve.

Technically you shouldn't need to specify any cipher modes at all as IKE
endpoints can negotiate a shared set themselves. But IKE works differently
than TLS. Rather than a peer sending all supported ciphers and the other peer
selecting one from their shared set as TLS does, the IKE peers go through
multiple cycles of proposals and rejections. The problem is that many vendor
implementations will give up after 2 or 3 cycles, so you need to constrain the
supported cipher suites to ensure they agree on cipher modes within the first
few proposal cycles. Easiest thing to do is to just constrain one endpoint to
the known best cipher suite.

Alas Android still only supports IKEv1 natively, which means for maximum
interoperability you have to rely on IKEv1 + L2TP server side. L2TP is usually
implemented as a separate service requiring additional configuration, which
adds to the confusion. IKEv2 simultaneously simplified tunnel setup while also
obsoleting L2TP. The irony of Android possibly getting native Wireguard before
native IKEv2 kills me....

FWIW, Linux IPSec stacks like FreeSwan don't have the concise configuration of
OpenBSD's IKE daemon, partly because the Linux ecosystem sucks at polish,
partly because OpenBSD's IKE daemon is many years newer and has less baggage.
But conceptually it's just as simple.

~~~
davidgatti
Nice! Thanks for the extra details, very useful.

