Hacker News Reader

Comment by derefr | Hacker News Reader

A major difference, besides WireGuard's simplicity, is that IPSec is a layer 4 protocol (ESP packets instead of TCP/UDP packets) whereas WireGuard is a layer 5 protocol (runs over UDP), so switches don't choke on it, and so a WireGuard peer doesn't need a public-routable IP address, but can be behind NAT.

View on HN

IPSec works fine with UDP and NAT.

"fine" with NAT is a bit of an overstatement, I don't think anyone who has seriously interacted with IPSEC would call it anything but a gigantic pain in the ass

I'm not "seriously" interacted, but I have VPN server and I'm using it on all devices in my hope (laptop, PC, phone) which are behind WiFi NAT. They work just fine. I'm using strongswan and IKEv2 on server.

Your NAT behaves and likely has (working) IPSEC ALG stuff, plenty of setups don't.

More likely is that both ends are using IPSec NAT-T (https://tools.ietf.org/html/rfc3947), which has been widely supported for some time. NAT-T encapsulates IP packets inside UDP, with the IKE daemons (usually) as the UDP endpoints.

NAT-T is unfortunately not very reliable.

Try having more than one IKE responser behind same nat gw. Gets tricky to have both/all respond to udp 500...

WireGuard operates at layer 3. The first sentence from the white paper by Jason A.: “ WireGuard is a secure network tunnel, operating at layer 3...”. [1]

Regardless of the layer, in a few words WireGuard is a simple encrypted tunnel over UDP. Since it’s UDP - there’s no guarantee all packets will be delivered, BUT - what WireGuard places emphasis on is all packets delivered from the WireGuard interface will be authenticated and encrypted. Similarity if packets are received from a particular peer, replies to that IP address will be guaranteed to go to that same peer.

The best feature of all imho is OpenSSH inspired authentication - makes configuring server/peers really straightforward.

References [1] https://www.wireguard.com/papers/wireguard.pdf

The tunnel does not have to encapsulate messages at the same layer as the tunnel itself. Consider this thought experiment: if you send Ethernet frames over WebSockets, what layer is the protocol?

My understanding is the Wireguard messages are IP (L3) but the protocol messages itself are UDP (L4) and it seems reasonable to describe Wireguard as a session layer over UDP given how much state and connection information it maintains.

I see what you mean. Specifically in the context of VPNs I’ve always interpreted the layer in terms of the payload that’s being encapsulated - which as far as I understand is IP (L3) packets in Wireguard’s case.

Maybe due to my own ignorance I misunderstood the meaning of derefr’s comment. Apologies if I sounded rude!

No worries, you're fine, just trying to clear up the confusion. I've heard both terms used interchangeably depending on context. _Usually_ as an administrator you care about what's in the tunnel, but _usually_ as a designer you're worried about how the tunnel itself is communicated, so, yeah, confusing :)

The internet does not use OSI.

It never ceases to amaze me how stubbornly educators have clung to the OSI model. It describes a non-Internet protocol stack which was designed in the 1970s, and which was never fully implemented. Attempting to use its layers as an ontology for Internet protocols is doomed to failure, as some of its layers (especially Layer 6) describe components which have no direct equivalent on the Internet.

Layer 6 exists, it’s just that most layer 7 protocols “fix” their layer 6 protocol. E.g., JSON/RPC requires JSON; SOAP requires XML; etc.

But Layer 6 is where the difference lies between ASN.1’s representational encodings—DER, BER, XER, etc. You can switch out this “presentation layer” encoding without either your application layer caring (it just sees an ASN.1 codec library) or your transport layer caring (it’s just transporting an opaque octet-stream payload document.)

One might also describe Avro, Parquet, etc. as “presentation formats”—they all have canonical input ADTs, but multiple possible wire encodings depending on the schema supplied at encode time. But all such schemas decode back to the same input ADT.

OK? The Internet does not use OSI, but it sure was helpful just now as an educational tool for describing that "what layer a VPN operates on" can be confusing. Even if you don't literally use OSI layers, knowing that UDP builds on top of TCP and having a common vernacular to express that is pretty useful. Given that the entire thread was already using specific OSI layers (which have clear mappings to things the Internet does do), starting by saying "the OSI model is not what the Internet actually does" does not seem to be the most productive avenue towards fostering understanding :)

L1 to L4 are just a shorthand way network engineers talk about:

  1. The physical connection and voltage/light levels
  2. Switching and MAC addresses
  3. Routing and IP addresses
  4. TCP/UDP and port numbers

Of course we know it's more complicated than that, but it's still a useful simplification.

this is subject to interpretation

Reply on news.ycombinator.com