> If this is the case, I believe this to be a flaw in the Wireguard protocol > design that > can lead to a lot of nuisance traffic. The spec makes statements such as the > following: > > | the outer external source IP of an encrypted WireGuard packet is used to > identify > | the remote endpoint of a peer, enabling peers to roam freely between > different > | external IPs, between mobile networks for example > > So this is not an unknown use case. However I believe it makes the assumption > that > the mobile device would continue to roam for eternity, and never be switched > off.
Wireguards design is such that if you have configured a wg interface, it is always "up", even if it hasn't sent a single packet to the remote side. This means that the network added by this interface will be available, and a route for it will be maintained so that a program can send packets this way. When such a packet wants to reach the remote of the wg tunnel, the interface will start handshake procedure, and try X times to reach what it hopes/thinks is the remote ip+port. Now, if cgnat or other measures makes it impossible to (re)establish the tunnel, it will still make a certain amount of attempts, and if programs (like ntpd, smtpd, syslogd or whatever) retries sending packets this whole process will keep on trying, using the last known information of the remote wg endpoint. It is not the same as other VPNs, but not inherently bad either. For many situations, this passive-up behaviour is what you want, even if it might not totally suit the mobile-sleeping client setup you had. No single design choice will match everyone's choices or expectations, so wg does it slightly differently from previous VPNs, but I don't see it as flawed just because it is not the same as the previous ones. -- May the most significant bit of your life be positive.
