From: Dean Davis <dean_davis@withtel.com.au>
To: Nikolay Martynov <mar.kolya@gmail.com>, wireguard@lists.zx2c4.com
Subject: Re: Connection hangs over CGNAT (Starlink)
Date: Mon, 19 Dec 2022 13:41:34 +1000 [thread overview]
Message-ID: <2c5180c0a406fb9a68f367213940d06b2d4340ec.camel@withtel.com.au> (raw)
In-Reply-To: <CALGY4fuH9oXpa34nzyj+jc94sS+ZQ5MaJUktFJF2A2-p213vEQ@mail.gmail.com>
hi
same issue
I do kind of a automated ping test and if fails on the server side to
many times bring down interface and then back up in a bash script
with
nmcli connection down wg0 && nmcli connection up wg0
to me it looks to be connection state issue difference between new and
established/related ( can not confirm )
ugly but works for me
regards
dean
On Thu, 2022-12-15 at 21:12 -0500, Nikolay Martynov wrote:
> Hi!
>
> I'm experiencing strange behaviour with wireguard: from time to time
> connection 'freezes'.
> Most often I'm observing this on an Android phone when connected from
> my home over Starlink.
> Server: latest Openwrt, Client: latest Android app.
> The connection establishes and works fine for some time. After some
> time the client still shows connection is established, but no
> incoming
> data is coming.
> On a server side 'latest handshake' goes into hours/days.
> The freeze happens randomly, for no apparent reason and I think only
> over starlink. I do not think I have ever observed this problem on
> cell networks.
>
> Reconnection solves the problem immediately.
> I did some tcpdumping when the problem was present and found the
> following:
> * Server side sees incoming traffic from the client and sends
> responses.
> * On my own router connected to Starlink (i.e. interface between my
> router and Starlink router) I see data going from the client to the
> server - but no packets coming back.
>
> So my 'hypothesis' is that somehow Starlink's CGNAT 'forgets' one
> side
> of the connection - and so data continues to go in one direction, but
> it doesn't come back. The thing with the wireguard is that it looks
> like it doesn't change the outgoing port when it attempts to do
> another handshake. This means that it continues using the same 'half
> broken' connection forever.
>
> I think the same happens to me at least once on a Linux client - but
> the difference with the phone is that the phone is always on and
> therefore the duration of the connection is much longer.
>
> I tried experimenting with keepalive messages - but it looks like
> they
> make no difference. Once connection freezes I see keepalived arriving
> onto the server, server sending reply - but that reply never arrives
> to the client.
>
> It looks like the solution to this problem would be for the client to
> use a different outgoing port when sending a handshake but I was not
> able to find an option for that.
>
> Is this something that is possible to do?
> Thanks!
>
>
next prev parent reply other threads:[~2023-01-03 2:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-16 2:12 Nikolay Martynov
2022-12-17 22:15 ` Szymon Nowak
2023-01-10 9:44 ` reox
2022-12-18 13:24 ` Lonnie Abelbeck
2022-12-19 3:41 ` Dean Davis [this message]
2022-12-31 1:08 ` Nikolay Martynov
2023-01-10 10:55 ` Nikolay Kichukov
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=2c5180c0a406fb9a68f367213940d06b2d4340ec.camel@withtel.com.au \
--to=dean_davis@withtel.com.au \
--cc=mar.kolya@gmail.com \
--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).