Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Eicke Herbertz <wolletd@posteo.de>
To: wireguard@lists.zx2c4.com
Subject: Re: "roaming" between source ports does not work
Date: Tue, 24 Nov 2020 09:44:07 +0100	[thread overview]
Message-ID: <5b25bec2-4073-0139-fc4a-b179bd40828d@posteo.de> (raw)
In-Reply-To: <20201124075737.GA18512@matrix-dream.net>


[-- Attachment #1.1: Type: text/plain, Size: 4856 bytes --]

Hi,

I agree that something simple as changing the source port would have
been reported. However, I have very similar issues occasionally with
some of my systems that are all behind NAT. They are remote, so I can't
access their status information on error. Rebooting the devices usually
works and iirc, just disconnecting network for some time works, too.

I don't know if that's far fetched, but I actually suspect the cause of
this issue not in WireGuard, but in some buggy NAT-implementation out
there. This would only hold true though, if you are also able to fix
your issue by replacing related networking hardware.

My central point being however is, that I've probably experienced the
same issue.

Regards,
Eicke

Am 24.11.20 um 08:57 schrieb Ivan Labáth:
> 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 http://deb.debian.org/debian/ 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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-11-24  8:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-08 22:00 Matthias May
2020-11-24  7:57 ` Ivan Labáth
2020-11-24  8:44   ` Eicke Herbertz [this message]
2020-11-25 16:20   ` Matthias May

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5b25bec2-4073-0139-fc4a-b179bd40828d@posteo.de \
    --to=wolletd@posteo.de \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).