Re: "roaming" between source ports does not work

[Matthias May <matthias.may@westermo.com>]

On 24/11/2020 08:57, Ivan Labáth wrote:
> Hello,
> 
> are you sure changing of source port is the issue?
> Seems like something that would be reported a long
> time ago.
> 
> Wireguard handshake fails, if your timestamps aren't
> monotonically increasing - maybe this is the issue?
> 
> For confirmation - does connection fail on wg restart without
> a device power cycle, or if you change the source port
> while the tunnel is running?
> 
> If your device is power cycling on a schedule, without a RTC,
> you should arrange an increasing nonce/time, if you can save
> data, maybe use NTP or a workaround may be to remove and
> re-add the peer on the server on a compatible schedule, 
> 
> Regards,
> Ivan
> 
> 
> On Sun, Nov 08, 2020 at 11:00:30PM +0100, Matthias May wrote:
>> Hi
>>
>> == Premise
>> * I've recently implemented support for wireguard in our LTE-router.
>>
>> == Source Environment
>> * The basis is OpenWRT.
>> * Used versions:
>> * On the client/initiator:
>>  * wg
>>   * 1.0.20200908
>>   * ad33b2d2267a37e0f65c97e65e7d4d926d5aef7d530c251b63fbf919048eead9
>>  * wg-tools
>>   * 1.0.20200827
>>   * 51bc85e33a5b3cf353786ae64b0f1216d7a871447f058b6137f793eb0f53b7fd
>> * On the server/responder:
>>  * Debian stretch (9.13), installed from repository
>>  * deb https://urldefense.com/v3/__http://deb.debian.org/debian/__;!!I9LPvj3b!RT42f9KbvkRAUCotWoe9WbvdGg0pfsEckxDFl3iujPxZcNW5KHCoRkhTfxHA91cvFlQ$  unstable main
>>  * # wg --version
>>  * wireguard-tools v1.0.20200827
>>  * I don't really know what the version of the build dkms is
>>
>> == Issue
>> * We've implemented an automated test that seems to have a problem.
>>  * Each night, the device is configured to connect to the debian box.
>>   * This works fine the first time.
>>   * However it doesn't work anymore after this first time.
>>
>> == Observerion
>> When the "client" connects the first time, wg-output on the "server"
>> looks like this:
>>> interface: wg1
>>>   public key: 7GxCG4m+6Kf4wjJ9vbQaGFASLGXLB5ddPWgBYw4gOk8=
>>>   private key: (hidden)
>>>   listening port: 51821
>>>
>>> peer: fizBdi/YkdzFLaq6Hnq+OZaGmbJBYC15QSP1Mik/EFU=
>>>   endpoint: 172.29.42.230:38442
>>>   allowed ips: 10.0.41.3/32
>>>   latest handshake: 44 seconds ago
>>>   transfer: 8.01 MiB received, 7.96 MiB sent
>>
>> and on the "client:
>>> interface: wg1
>>>   public key: fizBdi/YkdzFLaq6Hnq+OZaGmbJBYC15QSP1Mik/EFU=
>>>   private key: (hidden)
>>>   listening port: 38442
>>>
>>> peer: 7GxCG4m+6Kf4wjJ9vbQaGFASLGXLB5ddPWgBYw4gOk8=
>>>   endpoint: 172.29.60.13:51821
>>>   allowed ips: 10.0.41.0/24
>>>   latest handshake: 1 minute, 3 seconds ago
>>>   transfer: 187.06 KiB received, 189.96 KiB sent
>>
>> Ports and IPs match, everything works.
>>
>> However on the second run of the test:
>> On the "server" still:
>>> peer: fizBdi/YkdzFLaq6Hnq+OZaGmbJBYC15QSP1Mik/EFU=
>>>   endpoint: 172.29.42.230:38442
>>>   allowed ips: 10.0.41.3/32
>>>   latest handshake: 4 minutes, 52 seconds ago
>>>   transfer: 8.05 MiB received, 7.99 MiB sent
>>
>> But the "client" shows:
>>> interface: wg1
>>>   public key: fizBdi/YkdzFLaq6Hnq+OZaGmbJBYC15QSP1Mik/EFU=
>>>   private key: (hidden)
>>>   listening port: 47858
>>
>> The client device has been restarted in between.
>>
>> Since the listen-port is set to 0, it obviously has now a new,
>> different, source-port.
>> The server doesn't pick this up.
>> Since peers may roam between IPs, i was under the impression, that it
>> would also roam between ports.
>>
>>
>> Is this working as intended?
>> If yes: How should the configuration look like to support clients doing
>> a power-cycle?
>>
>>
>> I'm aware, that i could set a static port on the client, but this won't
>> work when going through NAT with port-scrambling.
>> So i don't really have control over the source-port of the connection
>> anyway.
>> I suppose this would also apply when a router/firewall inbetween has
>> some aggressive killing of states where the keepalive is not fast
>> enough, and source-port scrambling is done.
>>
>> But the main usecase i'm looking at here is: restart of a device.
>>
>> BR
>> Matthias


Hi Ivan
Thank you for response.
It seems my message was hanging somewhere, at least i didn't see it show up on the list until just now, thus i gave up
on it.

Yes your suggestion to use NTP is/was correct.
I found some similar reports.
Once NTP was configured, roaming between ports started working.

BR
Matthias