Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Dean Davis <>
To: Nikolay Martynov <>,
Subject: Re: Connection hangs over CGNAT (Starlink)
Date: Mon, 19 Dec 2022 13:41:34 +1000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>


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


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 


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!

  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:

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

  git send-email \ \ \ \ \

* 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).