Hello Janne, Janne Johansson writes: > Den tis 21 maj 2024 kl 09:50 skrev Nico Schottelius > : >> Hello Jason, >> do you mind applying the patch from Daniel? Or is there anything wrong with it? >> >> Daniel: amazing work, I was not aware that you have already put in the >> hard work, thank you so very much! >> >> The world (*) is suffering because of the lack of IP address binding in wireguard. >> >> (*) With world I refer to every engineer that needs to run wireguard in >> non-trivial situations with multiple IP addresses on one host, which is >> extremely common for anything that routes. > > Well, the main reason for wg to NOT do anything special is because > routing generally is done by looking at the destination ip and then No. Generally speaking that is incorrect. It is not special to reply with the same IP address. Generally speaking, when you have systems with multiple IP addresses you want to be able to steer the binding to an IP address. And even if you don't do that, you reply with the same IP address you have been contacted with. Wireguard does neither of it at the moment. I have written this already many times on this list, but the reason is very easy: - A connection is initiated from device A, connecting to router B on IP adddress a.b.c.d - The packet is correctly received by router B - The router replies incorrectly with address f.d.g.h - The reply packet is correctly blocked at the firewall of device A, because it comes from a random, unknown IP address This is the basic 101 of networking is to reply with the same address you have been contacted with, there is no discussion necessary. The whole world does it, even A-patch-y httpd (*) supports it. Since 1980 or so. Routing choices are independent of that, replying with the same IP address is a standard behaviour. Nico (*) As does ssh, nginx, ipsec protocols, openvpn, any rails application, any python application - I am not sure which software that binds to a socket does not support it, with the exception of wireguard.