Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Lonnie Abelbeck <>
To: Nikolay Martynov <>
Subject: Re: Connection hangs over CGNAT (Starlink)
Date: Sun, 18 Dec 2022 07:24:04 -0600	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Have you tried reducing the MTU of the WG tunnel?

I have a similar use case with a WG tunnel over a T-Mobile Home Internet (TMHI) CGNAT network.

After some testing determining the reduced MTU of the TMHI network, I set the WG endpoints' MTU to be 1340.

The WG tunnel has been rock solid.


> On Dec 15, 2022, at 8:12 PM, 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!
> -- 
> Martynov Nikolay.
> Email:

  parent reply	other threads:[~2022-12-18 13:24 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 [this message]
2022-12-19  3:41 ` Dean Davis
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).