Comment by tssva | Hacker News Reader

Comment by tssva | Hacker News Reader

Parent Full thread

While it may be good from an encryption and basic security configuration perspective I find wireguard lacking from a networking and administration perspective.

Networking wise it implements a point to multipoint model which is just awful to deal with. I had hoped that moving on from frame relay and ATM had killed this model but wireguard brings it right back. Then you also have to deal with complications of wireguard interfaces always being up. The two combined means doing anything but the most basic setups means more complicationd with more chance for incorrect configuration than an ipsec or openvpn alternative.

Then there is the whole troubleshooting problem. When it doesn't work wireguard provides much less information to troubleshoot the issue than ipsec and openvpn.

Also there is the irritating lines of code comparison vs ipsec and openvpn when for the most part it is comparing apples to oranges since wireguard doesn't include many of the features of either which are required for an enterprise site to site or road warrior VPN solution. Once the solutions are in place to provide comparable functionality the attack surface is likely to be pretty comparable.

I've done a lot of professional work over the past few months† with WireGuard and can't think of a piece of information I've ever needed to troubleshoot it that it doesn't provide. You know about `dynamic_debug`, right?

There's also just not that much to debug! You've got keys, allowed IP lists, and endpoint addresses. There aren't a lot of other knobs to turn!

I think a thing that gets people into trouble with WireGuard is not understanding how modest its design is. The goal of WireGuard is to drop into the networking stack as just another interface. It doesn't intend to implement an entire new networking model on top of itself. My experience has generally been, if it's straightforward to express in the Linux networking model, it's straightforward with WireGuard.

I think this is a very good thing. I really don't want to have to think about what the OpenVPN developers believe about networking in general. I want to bring up secure transports and route packets over them the way I'd route over any other tunnel I want orthogonal, predictable interfaces that I (or Tailscale, or whatever) can build more complicated things on top of.

† https://fly.io/blog/ipv6-wireguard-peering/

Every communication method is point to point at some layer.

If wg is a low layer that only attempts to do the tunneling job and leaves the routing and directory jobs to others, that seems just fine to me.

I prefer seperation of concernes.

wireguard interfaces aren't point to point. Point to point would be much better than the point to multipoint interface model wireguard has chosen.

Wireguard claims separation of concerns but then sticks itself in the routing and packet filtering process instead of leaving those wholly to the existing established solutions.

The philosophy is: use external tools to manage what you're describing, like cloudflare warp, WG itself is designed to be as simple as it is.

IPSec is just like that, it's just wireguard can be manually setup with the minimal wg command, while nobody uses IPSec barehanded.

Could you elaborate on how these issues and limitations you mention can manifest in practice? I’ve set up a couple of different topologies and haven’t felt limited yet.

Though troubleshooting packet loss is not fun and I haven’t been able to figure out how to avoid that and fragmentation, but I believe that’s more due to me than WG itself.

not op but one issue i have with it is that it ignores the routing table as soon the packet hits the interface. what i mean is if i tell the linux network stack to route packets "via" some address (which normally would involve arp) this configuration is completely ignored and the packet gets routed to whatever endpoint has the destination address as (confusingly named) AllowedIP address set. I expected it to do the lookup based on that via address and was trying to figure out what went wrong way too long. I think it would be kinda trivial to do this as i expected it after some minor research but that also led me to think it is supposed to be this way for some reason or another.

Yes, that's the normal behavior. If you have 172.16.10.0/24 that you are accessing via a wg peer at 172.16.1.10, then that peer needs to have both the 172.16.1.10/32 and the 172.16.10.0/24 in that peers allowedips. Then you can set a kernel route of 172.16.10.0/24 via 172.16.1.10 an the routing should work correctly.

no, the via part is just not considered. it does not make much sense to try though as it is impossible to have multiple peers with the same AllowedIPs addresses set. if it would honor the via address and allow me to configure multiple peers with the same AllowedIPs setting some dynamic routing could be made possible but it is not. However, i do configure it like you described just for consistency reasons when looking at the routing tables.

i.e. i could have peer A at 172.16.1.1 and peer B at 172.16.2.1. peer A would have AllowedIPs=172.16.1.1/32,172.16.0.0/24 and peer B would have AllowedIPs=172.16.2.1/32,172.16.0.0/24 and i could decide which peer gets traffic for 172.16.0.0/24 using the routing table by setting the via address to either 172.16.1.1 or 172.16.2.1 respectively. however, as stated this is not even allowed as only one peer would be able to have that subnet in its AllowedIPs setting present.

Ahh. If you are using wg-quick, the the script automatically adds interface level routes to the routing table that would override any manual static routes. You could add a Table=off flag to the wg interface config, and then you won't have the automatically generated route table entries based on the AllowedIPs flags, and your manual routes will be respected.

i do not. i manually manage these routes all by myself using systemd-networkd... these routes are respected but the via address is ignored nonetheless. to repeat myself, the via part of the route is not considered; i even double checked this by reading the code and furthermore did a PoC if it could be done. as soon as the route hits the interface the packets get routed according to the AllowedIPs setting regardless of any via address set on that route. If you are inclined enough to do so you can try it yourself. set it to a non existing address and you will see it will be routed regardless... or even set it to the address of an existing peer that has it set in its AllowedIPs setting and you will notice the peer that has the packets destination set as AllowedIPs setting will get the packets. which makes some sense as return traffic would only be allowed to come from that peer anyhow. i.e. for incoming packets the routing table is not even considered at all (analog to reverse path filtering).

What's the fragmentation issue you're having?

Not OP, but I've seen one small issue with using WireGuard on GCP VMs — you must limit MTU to 1380 or it starts silently dropping some packets and leaves you wondering why some HTTPS sites refuse to load (I thought I set up a VPN to avoid censorship? why the hell am I still having the same issues?) Probably an obvious thing for a networking expert, but it took me a few minutes to figure out what's going on.

Kind of an aside, but the network engineers I've worked with would mockingly blame MTU every time there was a connectivity problem, because it so rarely turns out that MTU is the issue. (I trust in this case you are correct though.)

Reply on news.ycombinator.com