Forums

[occ2]

Environment

– WireSock Secure Connect 3.8.2.1, Windows 10 x64

– Per-app split tunneling (AllowedApps: Telegram.exe, firefox.exe, …), MTU 1280

– Server: Ubuntu 24.04, amneziawg kernel module (DKMS, amnezia PPA), amneziawg-tools v3.1.20260812

 

Client config (keys/endpoint removed, values changed except S4):

Jc = 10, Jmin = 500, Jmax = 914

S1 = 63, S2 = 68, S3 = 85, S4 = 22

H1..H4 = non-overlapping ranges (e.g. H1 = 180000000-360000000)

Id = <domain>, Ip = dns, Ib = chrome

 

Problem

With the AWG 2.0 config in Transparent Mode the tunnel connects and Telegram works,

but in browsers (Firefox and Chrome) many websites load for ~30 s or never load.

 

What I tested

1. Same server + same 2.0 parameters in the official AmneziaWG for Windows 3.1.0 -> everything works.

2. Same server + 2.0 on Android (AmneziaWG 3.1.4) -> everything works.

3. WireSock Transparent Mode + AWG 1.5 config on the same server (no S3/S4, fixed H1-H4) -> works.

4. WireSock Transparent Mode + AWG 2.0 -> the problem described above.

5. MTU 1200 instead of 1280 -> partial improvement (some sites start working, others still stall).

6. Virtual Adapter Mode -> works, but after editing the AllowedApps list the problem returns

until WireSock is fully restarted (exit from tray + start again).

7. Disabling HTTP/3 in Firefox or IPv6 in the profile -> no effect.

 

Assumption

In Transparent Mode the S4 padding (added to every data packet in AWG 2.0) may not be taken

into account when calculating the maximum packet size / MSS, so large packets are dropped.

 

Request

Please check AWG 2.0 support in Transparent Mode. I need Transparent Mode. I can provide logs and run test builds.

[Vadim Smirnov]

Thank you for the detailed report and comparison tests.

We checked the 3.8.2.1 code: S4 is already included in the MTU calculation and TCP MSS adjustment. With MTU = 1280 and S4 = 22, the effective inner MTU is 1258 bytes, assuming no SOCKS5 proxy. This is quite low, but it does not establish the cause of the stalls, particularly since lowering the MTU partially helped.

Please try these tests in Transparent Mode, keeping all other settings unchanged:

Set MTU = 1380 and retry the affected websites.
Remove the MTU line to test automatic MTU selection.
Before each test, fully exit WireSock and the browser, then start them again so that TCP connections negotiate MSS afresh.
The problem after editing AllowedApps is also significant and may be separate. When it happens in Virtual Adapter Mode, please check whether restarting only the browser restores connectivity, or whether restarting WireSock is required.

If the problem persists, please provide a debug log covering connection startup and one failed website load, together with the test’s MTU setting. Please also provide the original non-secret AWG parameters, including the actual S1–S4 and H1–H4 values; remove private keys, preshared keys and endpoint details.

These comparisons will help distinguish an MTU/MSS problem from a connection-state or rule-update issue.

[occ2]

Hi Vadim,

Thanks for the suggestions. I ran the tests in Transparent Mode with
everything else unchanged, fully restarting both WireSock and the browser
before each run:

– MTU = 1280 (baseline): still stalls.
– MTU = 1380: works.
– No MTU line: works.
– Virtual Adapter Mode / AllowedApps test: skipped. I need Transparent Mode,
and since it now works, a full WireSock restart after my rare AllowedApps
edits is fine for me.

I captured a debug log with MTU 1280 (startup plus failing page loads).
I couldn’t find a way to attach files here, so I sent the sanitized log
and the actual S1-S4 / H1-H4 values in Ticket#821156 on help.wiresock.net
on November 9. The lines that stand out:

MTU=1280
[TUN]: Packet size is above MTU: ip_len = 1280 MTU = 1258 => Injecting ICMP Packet Too Big
[TUN]: Converted IPv6 packet to ICMPv6 Packet Too Big (MTU: 1258, payload: 1210 bytes)

Each appears 80 times, all for IPv6. There are no similar events for IPv4.

One problem seems clear: the effective MTU of 1258 is below the IPv6
minimum link MTU of 1280. Per RFC 8201, a host must not lower its path
MTU below 1280 when it receives a Packet Too Big with a smaller value.
So Windows keeps sending 1280-byte IPv6 packets, WireSock keeps rejecting
them, and those IPv6 connections hang.

That may not be the whole story, though: as mentioned in my first post,
disabling IPv6 in Firefox didn’t help, so IPv4 connections also seem to
stall with MTU 1280, just without any messages in the log. Perhaps some
IPv4 packets are not covered by the MSS adjustment either.

With MTU 1380 or the default, everything works, and MTU – S4 stays
>= 1280.

Possible fix for the IPv6 part: never go below 1280 for IPv6 (clamp the
IPv6 MTU/MSS), or at least warn when MTU – S4 < 1280.

Questions:
1. Does this match what you see in the code, and what could cause the
IPv4 stalls?
2. Until a fix is out, would you recommend MTU 1380 with S4 = 22, or
simply omitting the MTU line?

Thanks!

[Author]

Posts