On 19-Feb-23 15:42, Roman Mamedov wrote: > On Sun, 19 Feb 2023 21:18:34 +0100 > Nico Schottelius wrote: > >> If I am not mistaken that would mean in practice: >> >> if orignal_pkg.ip_dst == one_of_my_ips then >> return_pkg.ip.src = orignal_pkg.ip_dst >> return_pkg.ip.dst = orignal_pkg.ip_src >> fi >> >> For me that sounds like a sane approach (aside from >> my very simplified algorithm). > Except there is no request and response in WG, and as such no original or > return packet. Another peer contacts you, then some time later you contact the > other peer. Or the other way round. > > WG-wise what will need to be done is to store in the each peer's information > structure the local IP that we are supposed to use for communication with that > peer; and updating it when receiving packets from the peer, using the > destination of those. So you would see a "Local IP" in each "peer" section > when doing a "wg show". > > Also, until there is such IP initially stored, it will have to be some default > outgoing IP of the system towards that peer. BTW, how would this work in your > setup, what if not the peer contacts you first, but your machine needs to > contact the peer? > The situation can be (and often is) the same for both peers. If you're the initiator, you send to the peer address using its configured or DNS IP address, and normal routing.  You note the address used to send, and use it for future communications to that peer.  The first packet sets state in the posited firewall/nat. Subsequent packets using the same source address ensures that the firewall sees them as the same flow. When the peer gets around to saying something - which it will at latest when the keepalive timer goes off, but probably sooner, it will have noted your source address and it's local IP address (the one you used).  So it will send using the source address that you know about. This is the same algorithm used by the peer, so they should agree. When either end detects and address change, the process restarts. There is a possibility that the initial packets pass in flight, but I think that would at most result in a dropped packet, which will be resent. I don't think there's a deadlock, but in the event of thrashing, a tie-breaker of using the lowest candidate IP address generally works.. When there are multiple choices, it doesn't really matter which pair of IP addresses are picked, as long as they're stable while the systems reside on the same networks.  (E.G. it could be two notebook PCs in different hotel rooms, not just two fixed servers or one fixed server and one mobile.)  The goal is to establish a flow that stateful packet inspection, NAT, routing can recognize and use to keep a pinhole open... I don't have time at the moment to work out the corner cases, but that's the overall approach.