Ask HN: Vxlan over WireGuard or WireGuard over Vxlan?

2 days ago

When traversing a public network. Let’s agree going recursive (WireGuard inside VXLAN inside WireGuard) is a bad idea.

83 comments

mlhpdx

Reply
volkadav  2 days ago

https://man.openbsd.org/vxlan.4#SECURITY seems unambiguous that it's intended for use in trusted environments (and all else being equal, I'd expect the openbsd man page authors to have reasonable opinions about network security), so it sounds like vxlan over ipsec/wg is probably the better route?

notepad0x90  2 days ago

For site-so-site ovelay networks, use wireguard, vxlan should be inside of it, if at all. Your "network" is connected by wireguard, and it contains details like vxlan. Even within your network, when crossing security boundaries across untrusted channels, you can use wireguard.

Others mentioned tailscale, it's cool and all but you don't always need it.

As far as security, that's not even the consideration I had in mind, sure wireguard is secure, but that's not why you should have vxlan inside it, you should do so because that's the purpose of wireguard, to connect networks securely across security/trust boundaries. it doesn't even matter if the other protocol is also wireguard, or ssh or whatever, if it is an option, wireguard is always the outermost protocol, if not then ipsec, openvpn,softether,etc..whatever is your choice of secure overlay network protocol gets to be the tunnel protocol.

  • p0w3n3d  1 day ago

    There's also headscale - an OSS clone, if you're too paranoid to leave your keys to a company

q3k  2 days ago

Drop the VXLAN. There's almost never a good reason to stretch L2 over a WAN. Just route stuff across.

  • dgl  2 days ago

    This.

    Instead you can create multiple Wireguard interfaces and use policy routing / ECMP / BGP / all the layer 3 tricks, that way you can achieve similar things to what vxlan could give you but at layer 3.

    There's a performance benefit to doing it this way too, in some testing I found the wireguard interface can be a bottleneck (there's various offload and multiple core support in Linux, but it still has some overhead).

  • cjaackie  2 days ago

    This is the correct answer, routing between subnets is how it’s suppose to work. I think there are some edge cases like DR where it seems like stretching L2 might sound like a good idea, but it practice it gets messy fast.

  • iscoelho  2 days ago

    EVPN/VXLAN fabrics are becoming industry standard for new deployments. MACSEC/IPsec is industry standard for site-to-site.

    You'd be surprised to know that this is especially popular in cloud! It's just abstracted away (:

denkmoon  2 days ago

Not super related to the OP but since we're discussing network topologies; I've recently had an insane idea that nfs security sucks, nfs traversing firewalls sucks, kerberos really sucks, and that just wrapping it all in a wireguard pipe is way better.

How deranged would it be to have every nfs client establish a wireguard tunnel and only have nfs traffic go through the tunnel?

  • QuantumNomad_  2 days ago

    > How deranged would it be to have every nfs client establish a wireguard tunnel and only have nfs traffic go through the tunnel?

    Sounds good to me. I have my Wireguard tunnel set up so that only traffic intended for hosts that are in the Wireguard network itself are routed over the Wireguard tunnel.

    I mostly use it to ssh into different machines. The Wireguard server runs on a VPS on the Internet, and I can connect to it from anywhere (except from networks that filter Wireguard traffic), and that way ssh into my machines at home while I am away from home. Whereas all other normal traffic to other places is unaffected by and unrelated to the tunnel. So for example if I bring my laptop to a coffee shop and I have Wireguard running and I browse the web with a web browser, all my web browsing traffic still gets sent the same normal way that it would even if I didn’t have the tunnel running.

    I rarely use NFS nor SMB, but if I wanted to connect either of those I would be able to that as well over this Wireguard setup I have.

  • eugenekay  2 days ago

    I built a NFS3-over-OpenVPN network for a startup about a decade ago; it worked “okay” for transiting an untrusted internal cloud provider network and even over the internet to other datacenters, but ran into mount issues when the outer tunnels dropped a connection during a write. They ran out of money before it had to scale past a few dozen nodes.

    Nowadays I would recommend using NFS4+TLS or Gluster+TLS if you need filesystem semantics. Better still would be a proper S3-style or custom REST API that can handle the particulars of whatever strange problem lead to this architecture.

iscoelho  2 days ago

VXLAN over WireGuard is acceptable if you require a shared L2 boundary.

IPSec over VXLAN is what I recommend if you are doing 10G or above. There is a much higher performance ceiling than WireGuard with IPSec via hardware firewalls. WireGuard is comparatively quite slow performance-wise. Noting Tailscale, since it has been mentioned, has comparatively extremely slow performance.

edit: I'm noticing that a lot of the other replies in this thread are not from network engineers. Among network engineers WireGuard is not very popular due to performance & absence of vendor support. Among software engineers, it is very popular due to ease of use.

jrm4  2 days ago

Whenever I see threads like this, I think its related but I'll be honest, my networking understanding might be limited.

I use Tinc as a daily driver (for personal things) and have yet to come up with a new equivalent, given that I probably should. Does Vxlan help here?

  • iscoelho  2 days ago

    VXLAN is for L2 between campuses. It is commonly used in enterprise and cloud networks.

  • imiric  2 days ago

    Tinc is a fantastic piece of software. Very easy to use and configure, and it just works.

    These days I lean towards WireGuard simply because it's built into Linux, but Tinc would be my second choice.

solaris2007  2 days ago

If a situation where production vxlan is going over Wireguard arises, then someone in leadership failed to plan and the underlying Wireguard tunnel is coping with that failure. No doubt, OP already knows this and all too well.

The problem is no doubt a people problem. I have learned to overcome these people problems by adhering to specific kinds of communication patterns (familiar to Staff Engineers and SVPs).

There is no reason that Wireguard over vxlan over Wireguard can't work, even with another layer (TLS) on top of Wireguard. Nonetheless it is very suboptimal and proprietary implementations of vxlan tend to behave poorly in unexpected conditions.

We should remember that vxlan is next-get vlan.

The type of Wireguard traffic encapsulated within the vxlan that comes to mind first is Kubernetes intra/inter-cluster pod-to-pod traffic. But this Wireguard traffic could be between two legacy style VMs.

If I were the operator told "you need to securely tunnel this vxlan traffic between two sites" I would reach for IPsec instead of Wireguard in an attempt to not lower the MTU of encapsulated packets too much. Wireguard is a layer 4 (udp) protocol intended to encapsulate layer 3 (ipv6 and legacy ip) packets.

If I were the owner of the application I would bake mutual TLS authentication on QUIC with "encrypted hello" (both elliptic and PQ redundant) into the application. The applications would be implemented in Rust, or if not practicable to implement the application in Rust I would write into the Helm chart a sidecar that does such a mutual TLS auth part (in Rust of course).

I would also aggressively "ping" in some manner through the innermost encapsulation layer. If I had tenancy on a classic VM doing Wireguard over the vxlan I would have "ping -i 2 $remote_inside_tunnel_ipv6" running indefinitely.

kjuulh  2 days ago

I use vxlan on top of wireguard in my hobby set up. Probably wouldn't recommend it for an actual production use-case. But that is more or less because of how my homelab is setup (Hetzner -> Home about 20ms latency roundtrip).

I considered dropping my root wireguard and setting up just vxlan and flannel, but as I need NAT hole punching I kind of need the wireguard root so that is why i ended up with it.

Going Wireguard inside the vxlan (flannel) in my case, would likely be overkill, unless I wanted my traffic between nodes between regions to be separated from other peers on the network, not sure where that would be useful. It is an easy way of blocking out a peer however, but that could just as well be solved on the "root" wireguard node.

There might be some MTU things that would be messed up going nested wireguard networks.

inetknght  2 days ago

> Let’s agree going recursive (WireGuard inside VXLAN inside WireGuard) is a bad idea.

But it's not necessarily a bad idea. It depends on the circumstances, even when traversing a public network.

stevefan1999  2 days ago

Is there a WireGuard equivalent that does L2 instead of L3? Need this for a virtual mesh network for homelabbing. I have this exact setup, running VXLAN or GENEVE over WireGuard tunnel using KubeSpan from Talos Linux but I simply think having L2 access would make load balancer much easier

uberduper  2 days ago

What are your discovery mechanisms? I don't know what exists for automatic peer management with wg. If you're doing bgp evpn for vxlan endpoint discovery then I'd think WG over vxlan would be the easier to manage option.

  • uberduper  2 days ago

    If you actually want to use vxlan ids to isolate l2 domains, like if you want multiple hypervisors separated by public networks to run groups of VMs on distinct l2 domains, then vxlan over WG seems like the way to go.

mbreese  2 days ago

What are you trying to do? Why are you trying to link networks across the public internet?

tucnak  2 days ago

For traversing public networks, simply consider BGP over Wireguard. VXLAN is not worth it.

  • ghxst  2 days ago

    I've used wireguard for a while, not sure why I never considered doing BGP over it, might make for a fun weekend project.

    • tucnak  2 days ago

      BGP is vastly superior to any L2 make-believe trash you can imagine, and amazingly, it often has better hardware offloading support for forwarding and firewalls. For example, 100G switches (L3+) like MikroTik's CRS504 do not support IPv6 in hardware for VXLAN-encapsulated flows, but everything just works if you choose to go the BGP route.

      L2 is a total waste of time.

      12 replies →

pjd7  2 days ago

Tell us why you think so at least.

  • ronsor  2 days ago

    Reduced MTU chopping off your maximum packet size from all the extra headers and other overhead you're adding?

justsomehnguy  2 days ago

WG is L3 transport

VXLAN is L2-like tranport over L3

You can have EoIP over WG with any VLANs you like.

You can have a VXLAN over plain IP, over EoIP, over WG, over IPSec. Only WG and IPSec (with not NULL sec) do providecany semblance ofvencryption in transit

And mandatory X\Y problem.

DiabloD3  2 days ago

I mean, ultimately, thats how Google routes internally.

IPSec-equivalent, VXLAN-equivalent, IPSec-equivalent.

Prevents any compromised layer from knowing too much about the traffic.

  • pixl97  2 days ago

    Internal is fine because you control things like MTU so you don't have to worry about packet fragmentation/partial loss.

  • tucnak  2 days ago

    What gave you that idea? Internally, Google uses GRE/GENEVE-like stuff but for reasons that have nothing to do with "preventing compromise" or whatever, but because they're carrying metadata (traces, latency budgets, billing ids.) That is to say, encapsulation is just transport. It's pretty much L3 semantics all the way down... In fact, this is more or less the point: L2 is intractable at scale, as broadcast/multicast doesn't work. However, it's hard to find comparisons to anything you're familiar with at Google scale. They have a myriad of proprietary solutions and custom protocols for routing, even though it's all L3 semantics. To learn more:

    Andromeda https://research.google/pubs/andromeda-performance-isolation...

    Orion https://research.google/pubs/orion-googles-software-defined-...

    • zeroxfe  2 days ago

      The last time I was there, there were many layers of encap, including MPLS, GRE, PSP, with very tightly managed MTU. Traffic engineering was mostly SDN-managed L3, but holy hell was it complex. Considering that Google (at the time) carried more traffic than the rest of the Internet combined, maybe it was worth it.