Hacker News Reader

Comment by 3np | Hacker News Reader

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.

View on HN

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