Is there a windows torrent questions newsgroup?
Or a windows vpn newsgroup?

I need help in deciphering what the manpage for openvpn is trying to tell
me only when I'm torrenting (I don't get these errors any other time).
https://openvpn.net/community-resources/reference-manual-for-openvpn-2-0/

When I use deluge on windows to download piratebay movies the vpn output
does strange things by giving an error that I don't get otherwise.

The error seems to be telling me three things, one of which is that there
is an "authenticate/decrypt error", the second of which is that there is a
"bad packet id" and then the third thing is a suggestion that it "may be a
replay" (whatever that is).

I guess a replay is the same packet twice, but why would that matter?
Here are just three of the thousands of similar messages that happens.

2022-05-25 01:02:04 Authenticate/Decrypt packet error: bad packet ID (may
be a replay): [ #123456 ] -- see the man page entry for --no-replay and
--replay-window for more info or silence this warning with
--mute-replay-warnings

2022-05-25 01:02:05 Authenticate/Decrypt packet error: bad packet ID (may
be a replay): [ #123457 ] -- see the man page entry for --no-replay and
--replay-window for more info or silence this warning with
--mute-replay-warnings

2022-05-25 01:02:06 Authenticate/Decrypt packet error: bad packet ID (may
be a replay): [ #123458 ] -- see the man page entry for --no-replay and
--replay-window for more info or silence this warning with
--mute-replay-warnings

The manpage entry for "--no-replay" is here but I don't think disabling it
will benefit the security based on this warning not to disable it.
https://patchwork.openvpn.net/patch/1297/
--no-replay
Disable OpenVPN's protection against replay attacks. Don't use this option
unless you are prepared to make a tradeoff of greater efficiency in
exchange for less security.OpenVPN provides datagram replay protection by
default.
Replay protection is accomplished by tagging each outgoing datagram with an
identifier that is guaranteed to be unique for the key being used. The peer
that receives the datagram will check for the uniqueness of the identifier.
If the identifier was already received in a previous datagram, OpenVPN will
drop the packet. Replay protection is important to defeat attacks such as a
SYN flood attack, where the attacker listens in the wire, intercepts a TCP
SYN packet (identifying it by the context in which it occurs in relation to
other packets), then floods the receiving peer with copies of this packet.

The manpage entry for "--replay-window" is below but I don't think the
window is the critical issue, is it?
--replay-window n [t]
Use a replay protection sliding-window of size n and a time window of
tseconds.By default n is 64 (the IPSec default) and t is 15 seconds.

The manpage entry for "--mute-replay-warnings" is below but all it does is
turn off the warnings which doesn't accomplish anything else.
--mute-replay-warnings
Silence the output of replay warnings, which are a common false alarm on
WiFi networks. This option preserves the security of the replay protection
code without the verbosity associated with warnings about duplicate
packets.

Can you help me decipher why I get thousands of these warnings when
torrenting movies using deluge but not when I'm using vpn for other things?

From a security standpoint should I care if there is a packet being
replayed? What is the implication of a packet being replayed anyway?

On 5/27/2022 12:58 PM, Jerry wrote:
> Is there a windows torrent questions newsgroup?
> Or a windows vpn newsgroup?
>
> I need help in deciphering what the manpage for openvpn is trying to tell
> me only when I'm torrenting (I don't get these errors any other time).
> https://openvpn.net/community-resources/reference-manual-for-openvpn-2-0/
>
> When I use deluge on windows to download piratebay movies the vpn output
> does strange things by giving an error that I don't get otherwise.
>
> The error seems to be telling me three things, one of which is that there
> is an "authenticate/decrypt error", the second of which is that there is a
> "bad packet id" and then the third thing is a suggestion that it "may be a
> replay" (whatever that is).
>
> I guess a replay is the same packet twice, but why would that matter?
> Here are just three of the thousands of similar messages that happens.
>
> 2022-05-25 01:02:04 Authenticate/Decrypt packet error: bad packet ID (may
> be a replay): [ #123456 ] -- see the man page entry for --no-replay and
> --replay-window for more info or silence this warning with
> --mute-replay-warnings
>
> 2022-05-25 01:02:05 Authenticate/Decrypt packet error: bad packet ID (may
> be a replay): [ #123457 ] -- see the man page entry for --no-replay and
> --replay-window for more info or silence this warning with
> --mute-replay-warnings
>
> 2022-05-25 01:02:06 Authenticate/Decrypt packet error: bad packet ID (may
> be a replay): [ #123458 ] -- see the man page entry for --no-replay and
> --replay-window for more info or silence this warning with
> --mute-replay-warnings
>
> The manpage entry for "--no-replay" is here but I don't think disabling it
> will benefit the security based on this warning not to disable it.
> https://patchwork.openvpn.net/patch/1297/
> --no-replay
> Disable OpenVPN's protection against replay attacks. Don't use this option
> unless you are prepared to make a tradeoff of greater efficiency in
> exchange for less security.OpenVPN provides datagram replay protection by
> default.
> Replay protection is accomplished by tagging each outgoing datagram with an
> identifier that is guaranteed to be unique for the key being used. The peer
> that receives the datagram will check for the uniqueness of the identifier.
> If the identifier was already received in a previous datagram, OpenVPN will
> drop the packet. Replay protection is important to defeat attacks such as a
> SYN flood attack, where the attacker listens in the wire, intercepts a TCP
> SYN packet (identifying it by the context in which it occurs in relation to
> other packets), then floods the receiving peer with copies of this packet.
>
> The manpage entry for "--replay-window" is below but I don't think the
> window is the critical issue, is it?
> --replay-window n [t]
> Use a replay protection sliding-window of size n and a time window of
> tseconds.By default n is 64 (the IPSec default) and t is 15 seconds.
>
> The manpage entry for "--mute-replay-warnings" is below but all it does is
> turn off the warnings which doesn't accomplish anything else.
> --mute-replay-warnings
> Silence the output of replay warnings, which are a common false alarm on
> WiFi networks. This option preserves the security of the replay protection
> code without the verbosity associated with warnings about duplicate
> packets.
>
> Can you help me decipher why I get thousands of these warnings when
> torrenting movies using deluge but not when I'm using vpn for other things?
>
> From a security standpoint should I care if there is a packet being
> replayed? What is the implication of a packet being replayed anyway?

I found a Reddit via Google for this. Doesn't mean it's right,
but you can test for it.

Obviously, they like some notion of "stateful packet inspection" and are
numbering your packets. This is to prevent spoofing (someone injecting
packets artificially to break the crypto or something). An article here
gives an idea what that's like. By numbering the packets, this allows
the detection of duplicates. (The numbers don't have to be integer
counting numbers, that's just to make the concept easier to understand.
They can use a crypto based counting sequence to make it harder to fudge.)

https://en.wikipedia.org/wiki/Replay_attack

Someone here equates the out-of-sequence packets with "packet loss".
So a packet order of 1 2 3 5 yields you an error message. For whatever
this is worth, they consider checking the MTU might help.

https://www.reddit.com/r/VPNTorrents/comments/8jksb5/openvpn_authenticatedecrypt_packet_error_whats/

The VPN encapsulated your packets, and that could cause an MTU issue.

(For the VPN appliance we had at work, some of these transport issues
causes certain Windows activities to just plummet in performance. But
being an appliance, there weren't a lot of things I could adjust
when connected remotely to work.)

It implies that what passes for instructions, should have
addressed the maths for you and what value you should be using
so that VPN and non-VPN activities don't have troubles.

And the tuning procedure looks remarkably simple. One of the
posters on Reddit, provides this link.

https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn

Paul

On Sat, 28 May 2022 05:06:37 -0400, Paul wrote:

> And the tuning procedure looks remarkably simple. One of the
> posters on Reddit, provides this link.
>
> https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn

Thank you for those lookups.
It's cryptic so what I'll do first is try the easiest thing.
(and then I'll go back to the rest of your information for harder things)

The easiest thing seems to be to use the MTU (which from an acronym lookup
is called the Maximum Transmission Unit in Windows) to set the mssfix in
the vpn config file (which from an acronym lookup is called the Maximum
Segment Size in VPN).

(There is no mssfix setting in the vpn file at this point.)

As you said, it "seems" easy to determine the mssfix to set.
mssfix = (the MTU ping result below) - 40
But even that isn't as easy as they make it look.

Starting with this Windows advice to arrive at the correct MTU
https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn

They don't say if you're supposed to determine the MTU before you go onto
VPN or after, where it could be a very different number in each case.

Worse, on Windows, the command syntax given for Windows fails every time.

ping -n 1 -l 1500 -f www.example.com
Pinging www.example.com [93.184.216.34] with 1500 bytes of data:
Packet needs to be fragmented but DF set.
Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

Looking up how to get the MTU on Windows there is a lot about this problem.
https://www.thegeekpub.com/271035/openvpn-mtu-finding-the-correct-settings/
https://becomethesolution.com/how-to-change-and-check-windows-mtu-size
https://superuser.com/questions/1266391/how-does-specifying-mssfix-for-openvpn-enable-use-of-netflix

But even the articles about it say it's a "ball of confusion"
https://community.ipfire.org/t/openvpn-mtu-and-mssfix-ball-of-confusion/4645

I'll figure this out first and come back to you when I do.
It's more complicated than I thought even when it seems simple.

On 5/28/2022 1:12 PM, Jerry wrote:
> On Sat, 28 May 2022 05:06:37 -0400, Paul wrote:
>
>> And the tuning procedure looks remarkably simple. One of the
>> posters on Reddit, provides this link.
>>
>>     https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn
>
> Thank you for those lookups.
> It's cryptic so what I'll do first is try the easiest thing.
> (and then I'll go back to the rest of your information for harder things)
>
> The easiest thing seems to be to use the MTU (which from an acronym lookup
> is called the Maximum Transmission Unit in Windows) to set the mssfix in
> the vpn config file (which from an acronym lookup is called the Maximum
> Segment Size in VPN).
> (There is no mssfix setting in the vpn file at this point.)
>
> As you said, it "seems" easy to determine the mssfix to set.
> mssfix = (the MTU ping result below) - 40
> But even that isn't as easy as they make it look.
>
> Starting with this Windows advice to arrive at the correct MTU
> https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn
>
> They don't say if you're supposed to determine the MTU before you go onto
> VPN or after, where it could be a very different number in each case.
>
> Worse, on Windows, the command syntax given for Windows fails every time.
>
> ping -n 1 -l 1500 -f www.example.com
> Pinging www.example.com [93.184.216.34] with 1500 bytes of data:
> Packet needs to be fragmented but DF set.
> Ping statistics for 93.184.216.34:
>    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
>
> Looking up how to get the MTU on Windows there is a lot about this problem.
> https://www.thegeekpub.com/271035/openvpn-mtu-finding-the-correct-settings/
> https://becomethesolution.com/how-to-change-and-check-windows-mtu-size
> https://superuser.com/questions/1266391/how-does-specifying-mssfix-for-openvpn-enable-use-of-netflix
>
> But even the articles about it say it's a "ball of confusion" https://community.ipfire.org/t/openvpn-mtu-and-mssfix-ball-of-confusion/4645
>
> I'll figure this out first and come back to you when I do.
> It's more complicated than I thought even when it seems simple.

This is using the "DontFragment" capability of ping, to
check "whether a packet fits nicely or not". The Windows
version of ping, the "-f" is basically part of path MTU
discovery.

ping /? # check the help, while sitting in Command Prompt...

ping -n 1 -l 1500 -f www.example.com
Pinging www.example.com [93.184.216.34] with 1500 bytes of data:
Packet needs to be fragmented but DF set.
Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

You've just tested a pair of shoes

"Packet needs to be fragmented" <=== packet is too big

but the shoe did not fit.

"100% loss"

When you make -l shorter, eventually the packet goes through
and is not lost. We're using that special feature of the
ping, to measure our feet and shoes for "fit".

You ping with the VPN *running*, because you're trying to
make it work properly with VPN overhead present.

And anything, all the way to www.example.com, is part of
the path. So if you did a tracert www.example.com and it was
ten hops, any section of narrow pipe in those ten hops,
could affect the need to fragment into two packets.

|<=== The MTU of the wire outside your house ======>|
+--------------------+------------------------------+
| VPN-Encapsulation | The Windows Packet |
+--------------------+------------------------------+
| <== The Windows MTU =======> |

When you encapsulate traffic, if you want to avoid fragmentation,
the "thing" you're sending, the Windows Packet, has to be short
enough, so that one packet on the wire is used to carry
one Windows packet. That improves the efficiency, in the
sense of not turning every packet into a special case.

There is nothing wrong with "anything goes" encapsulation,
except that if not tuned, it's doing a lot of extra work,
and at high traffic rates, maybe something just gets broken.

By doing the tuning now, you're trying to avoid every packet
needing special treatment.

We also needed to do this in the Windows days, back when
people connected their ADSL modem directly to a Windows PC,
and the Windows PC terminated PPPOE for them. At the time,
I happened to be on a Mac, the Mac Classic didn't have PPPOE,
so you had to add software to terminate PPPOE encapsulation,
and there might have been some adjusting to be done there.

Later, the $39.95 router box was doing this for us. And
plain old Ethernet packets went from the home computer
to the router, the router did the PPPOE step.

The VPN encapsulation introduces a similar step.

It's been a long time, since I've needed to do anything
like this, and my memory isn't what it used to be. There
is probably a command in Windows to set the MTU or such,
but I don't remember what that is. And the sites that
used to offer advice, those web sites tend to disappear.

If you're really impatient, you can make a "giant adjustment"
and just chop your packets down to 512 bytes :-) That will at
least give you a chance to test whether this adjustment is
going to make a difference or not. All the careful
measuring crap is an "attempt to make it efficient".

Paul

On Sat, 28 May 2022 15:38:40 -0400, Paul wrote:

> You've just tested a pair of shoes
> but the shoe did not fit.

Oh. Duh. Now I get it.
I'm supposed to slowly lower the "1500" until it fails, which it does consistently only slightly below 1500.

ping -n 1 -l 1500 -f www.example.com

Pinging www.example.com [93.184.216.34] with 1500 bytes of data:
Packet needs to be fragmented but DF set.

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
......
Pinging www.example.com [93.184.216.34] with 1000 bytes of data:
Reply from 93.184.216.34: bytes=1000 time=8ms TTL=52

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 8ms, Maximum = 8ms, Average = 8ms

......

Pinging www.example.com [93.184.216.34] with 1300 bytes of data:
Reply from 93.184.216.34: bytes=1300 time=71ms TTL=52

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 71ms, Maximum = 71ms, Average = 71ms

......

Pinging www.example.com [93.184.216.34] with 1400 bytes of data:
Reply from 93.184.216.34: bytes=1400 time=8ms TTL=52

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 8ms, Maximum = 8ms, Average = 8ms

......

Pinging www.example.com [93.184.216.34] with 1450 bytes of data:
Reply from 93.184.216.34: bytes=1450 time=11ms TTL=52

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 11ms, Maximum = 11ms, Average = 11ms

......

Pinging www.example.com [93.184.216.34] with 1500 bytes of data:
Packet needs to be fragmented but DF set.

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

......

> You ping with the VPN *running*, because you're trying to
> make it work properly with VPN overhead present.

That was WITHOUT the VPN running.
Now I'll try it with the VPN running.

c:\> ping -n 1 -l 1500 -f www.example.com

Pinging www.example.com [93.184.216.34] with 1500 bytes of data:
Packet needs to be fragmented but DF set.

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

c:\>ping -n 1 -l 1000 -f www.example.com

Pinging www.example.com [93.184.216.34] with 1000 bytes of data:
Reply from 93.184.216.34: bytes=1000 time=72ms TTL=54

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 72ms, Maximum = 72ms, Average = 72ms

c:\>ping -n 1 -l 1300 -f www.example.com

Pinging www.example.com [93.184.216.34] with 1300 bytes of data:
Reply from 93.184.216.34: bytes=1300 time=84ms TTL=54

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 84ms, Maximum = 84ms, Average = 84ms

c:\>ping -n 1 -l 1400 -f www.example.com

Pinging www.example.com [93.184.216.34] with 1400 bytes of data:
Reply from 93.184.216.34: bytes=1400 time=289ms TTL=54

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 289ms, Maximum = 289ms, Average = 289ms

c:\>ping -n 1 -l 1450 -f www.example.com

Pinging www.example.com [93.184.216.34] with 1450 bytes of data:
Reply from 93.184.216.34: bytes=1450 time=72ms TTL=54

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 72ms, Maximum = 72ms, Average = 72ms

c:\>ping -n 1 -l 1500 -f www.example.com

Pinging www.example.com [93.184.216.34] with 1500 bytes of data:
Packet needs to be fragmented but DF set.

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

c:\>

> And anything, all the way to www.example.com, is part of
> the path. So if you did a tracert www.example.com and it was
> ten hops, any section of narrow pipe in those ten hops,
> could affect the need to fragment into two packets.

I don't know what I need to redact so I may redact too much.
c:\>tracert www.example.com

Tracing route to www.example.com [93.184.216.34]
over a maximum of 30 hops:

1 26 ms 31 ms 39 ms (this is the VPN server IP address redacted)
2 70 ms 53 ms 65 ms 192.168.1.1 (I think this is just my router)
3 48 ms 52 ms 51 ms (I redacted this first hop which might be comcast?)
4 200 ms 117 ms 94 ms (I redacted this next hop which might also be comcast?)
5 38 ms 38 ms 31 ms (I don't know if I need to redact all these or not)
6 38 ms 50 ms 68 ms (I don't know if I need to redact all these or not)
7 50 ms 59 ms 47 ms (I don't know if I need to redact all these or not)
8 44 ms 55 ms 63 ms (eventually I shouldn't need to keep redacting IPs right?)
9 45 ms 51 ms 113 ms as2906-c-4.chicago.ibone.comcast.net [66.208.228.62]
10 63 ms 64 ms 52 ms ae-66.core1.sab.edgecastcdn.net [152.195.85.131]
11 183 ms 51 ms 44 ms 93.184.216.34

Trace complete.

>
> |<=== The MTU of the wire outside your house ======>|
> +--------------------+------------------------------+
> | VPN-Encapsulation | The Windows Packet |
> +--------------------+------------------------------+
> | <== The Windows MTU =======> |

Now I'm starting to get why I needed to shorten the length.
I lose it between 1470 and 1480
c:\>ping -n 1 -l 1500 -f www.example.com

Pinging www.example.com [93.184.216.34] with 1500 bytes of data:
Packet needs to be fragmented but DF set.

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

c:\>ping -n 1 -l 1490 -f www.example.com

Pinging www.example.com [93.184.216.34] with 1490 bytes of data:
Packet needs to be fragmented but DF set.

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

c:\>ping -n 1 -l 1480 -f www.example.com

Pinging www.example.com [93.184.216.34] with 1480 bytes of data:
Packet needs to be fragmented but DF set.

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

c:\>ping -n 1 -l 1475 -f www.example.com

Pinging www.example.com [93.184.216.34] with 1475 bytes of data:
Packet needs to be fragmented but DF set.

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

c:\>ping -n 1 -l 1470 -f www.example.com

Pinging www.example.com [93.184.216.34] with 1470 bytes of data:
Reply from 93.184.216.34: bytes=1470 time=50ms TTL=54

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 50ms, Maximum = 50ms, Average = 50ms

> By doing the tuning now, you're trying to avoid every packet
> needing special treatment.

I think I have to first figure out what the MTU is for my Windows.
C:\>netsh interface ipv4 show subinterface

MTU MediaSenseState Bytes In Bytes Out Interface
------ --------------- --------- --------- -------------
4294967295 1 0 1418976 Loopback Pseudo-Interface 1
65535 5 0 0 OpenVPN Wintun
1500 1 17189665202 8311956861 eth0
1500 1 8000505014 315120613 Local Area Connection
1500 1 0 3940374 Npcap Loopback Adapter
1500 1 0 2644590 VirtualBox Host-Only Network
1500 1 0 2449481 VirtualBox Host-Only Network #2
1500 1 0 2448917 VirtualBox Host-Only Network #3

Is that telling me my Windows MTU is 1500 for my connection?
If that told me the MTU, why did I need the ping then?

Anyway I could change the MTU with a command like this but it's too risky.
C:\>netsh interface ipv4 set subinterface "Local Area Connection" mtu=1400

I think it's safer to change the MSSFIX in the VPN configuration file.
mssfix = (the MTU ping result) - 40

At largest the mssfix would be the MTU of 1500 - 30 which is "MSSFIX 1470"
is that the correct math?

I think, to be safe, I'll add the two lines to the VPN configuration file
that were recommended here and then let you know if that makes a difference.
https://www.thegeekpub.com/271035/openvpn-mtu-finding-the-correct-settings/

tun-mtu 1450
mssfix 1410

What could go wrong?

On 5/28/2022 5:10 PM, Jerry wrote:

> At largest the mssfix would be the MTU of 1500 - 30 which is "MSSFIX 1470"
> is that the correct math?
> I think, to be safe, I'll add the two lines to the VPN configuration file
> that were recommended here and then let you know if that makes a difference.
> https://www.thegeekpub.com/271035/openvpn-mtu-finding-the-correct-settings/
>
> tun-mtu 1450
> mssfix 1410
>
> What could go wrong?

I think that should be good enough for a test. Presumably
using mssfix, the size is adjusted just for the duration of
the VPN session.

And I don't know that this will fix anything. It's
just a test, based on some Reddit info.

What I would expect this to do, is change the efficiency
a bit. I wouldn't expect it to fix anything. But, try it and see.

The purpose of using "real" test results, is to prove or
disprove the math.

Paul

On Sat, 28 May 2022 21:22:42 -0400, Paul wrote:

> And I don't know that this will fix anything. It's
> just a test, based on some Reddit info.

I thank you for the advice to find out the default MTU (which for Windows
is 1500 I think) and the size of my shoes which seem to be 1470 on VPN.

As a result I added these two lines to the VPN configuration file.
tun-mtu 1450
mssfix 1410

With the result in the VPN log file of the following new messages.
2022-05-28 01:02:03 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1450)
2022-05-27 01:02:04 IPv4 MTU set to 1450 on interface 17 using SetIpInterfaceEntry()

As an aside, I finally found a good use for the Windows "F2" key (repeat up
to a character) which I had accidentally hit instead of F3 (repeat all).

C:\> ping -n 1 -f www.example.com -l 1500
F2 5
C:\> ping -n 1 -f www.example.com -l 1(I can type the rest in easily)

What surprised me wasn't that the "shoe" that fit on VPN was 1470
But it was also 1470 when I was not on VPN which I hadn't expected to see.

c:\>ping -n 1 -f www.example.com -l 1475
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

c:\>ping -n 1 -f www.example.com -l 1470
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),

I wonder what others out there get for their default Windows 10 shoe size?

On 5/29/2022 2:47 AM, Jerry wrote:
> On Sat, 28 May 2022 21:22:42 -0400, Paul wrote:
>
>> And I don't know that this will fix anything. It's
>> just a test, based on some Reddit info.
>
> I thank you for the advice to find out the default MTU (which for Windows
> is 1500 I think) and the size of my shoes which seem to be 1470 on VPN.
>
> As a result I added these two lines to the VPN configuration file.
> tun-mtu 1450
> mssfix 1410
>
> With the result in the VPN log file of the following new messages.
> 2022-05-28 01:02:03 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1450)
> 2022-05-27 01:02:04 IPv4 MTU set to 1450 on interface 17 using SetIpInterfaceEntry()
>
> As an aside, I finally found a good use for the Windows "F2" key (repeat up
> to a character) which I had accidentally hit instead of F3 (repeat all).
>
> C:\> ping -n 1 -f www.example.com -l 1500
> F2 5
> C:\> ping -n 1 -f www.example.com -l 1(I can type the rest in easily)
>
> What surprised me wasn't that the "shoe" that fit on VPN was 1470
> But it was also 1470 when I was not on VPN which I hadn't expected to see.
>
> c:\>ping -n 1 -f www.example.com -l 1475
>    Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
>
> c:\>ping -n 1 -f www.example.com -l 1470
>    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
>
> I wonder what others out there get for their default Windows 10 shoe size?

The length field in ping is probably the "payload" size
and the packets likely have an IP header on them of some size.

In my trace, one response may have come from Windows. The
second response, was my router piping up and telling me
the packet was too big. Maybe that's the impact of PPPOE
(as I'm on ADSL)? The third example was small enough to make it.

*******
ping -n 1 -f www.example.com -l 1480

Pinging www.example.com [93.184.216.34] with 1480 bytes of data:
Packet needs to be fragmented but DF set. Local windows response?

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

*******
ping -n 1 -f www.example.com -l 1470

Pinging www.example.com [93.184.216.34] with 1470 bytes of data:
Reply from 192.168.123.1: Packet needs to be fragmented but DF set. My $39.95 IPV4 router

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),

*******
ping -n 1 -f www.example.com -l 1460

Pinging www.example.com [93.184.216.34] with 1460 bytes of data: Reached example.com
Reply from 93.184.216.34: bytes=1460 time=49ms TTL=59

Ping statistics for 93.184.216.34:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 49ms, Maximum = 49ms, Average = 49ms

It looks like I don't have Wireshark on here, to capture the
packets and look at them.

Paul

On Sun, 29 May 2022 05:05:42 -0400, Paul wrote:
>> I wonder what others out there get for their default Windows 10 shoe size?
>
> The length field in ping is probably the "payload" size
> and the packets likely have an IP header on them of some size.

I think you may be correct as I had also tested a ping of the router
without VPN, thinking for some reason that it might not fail at 1500.

But it failed the same as pinging did with or without VPN to example.com.
C:\>ping -n 1 -f 192.168.1.1 -l 1500 (100% loss)
C:\>ping -n 1 -f 192.168.1.1 -l 1490 (100% loss)
C:\>ping -n 1 -f 192.168.1.1 -l 1480 (100% loss)
C:\>ping -n 1 -f 192.168.1.1 -l 1475 (100% loss)
C:\>ping -n 1 -f 192.168.1.1 -l 1470 (0% loss)
Reply from 192.168.1.1: bytes=1470 time=2ms TTL=64
Ping statistics for 192.168.1.1:
Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 2ms, Average = 2ms

Interestingly all the shoes fit at around size 1470
which means probably it's an "Ethernet thing" of some sort.

> In my trace, one response may have come from Windows. The
> second response, was my router piping up and telling me
> the packet was too big. Maybe that's the impact of PPPOE
> (as I'm on ADSL)? The third example was small enough to make it.

I get the same "DF bit" set (Don't Fragment flag) warning you got
when you used the "Do Not Fragment Option -f" as I had also done.

C:\>ping -n 1 -f 192.168.1.1 -l 1500
Pinging 192.168.1.1 with 1500 bytes of data:
Packet needs to be fragmented but DF set.
Ping statistics for 192.168.1.1:
Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),

That "DF set" warning shows up every time there is a 100% loss.

> *******
> ping -n 1 -f www.example.com -l 1480
>
> Pinging www.example.com [93.184.216.34] with 1480 bytes of data:
> Packet needs to be fragmented but DF set. Local windows response?
>
> Ping statistics for 93.184.216.34:
> Packets: Sent = 1, Received = 0, Lost = 1 (100% loss),
>
> *******
> ping -n 1 -f www.example.com -l 1470
>
> Pinging www.example.com [93.184.216.34] with 1470 bytes of data:
> Reply from 192.168.123.1: Packet needs to be fragmented but DF set. My $39.95 IPV4 router
>
> Ping statistics for 93.184.216.34:
> Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
>
> *******
> ping -n 1 -f www.example.com -l 1460
>
> Pinging www.example.com [93.184.216.34] with 1460 bytes of data: Reached example.com
> Reply from 93.184.216.34: bytes=1460 time=49ms TTL=59
>
> Ping statistics for 93.184.216.34:
> Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
> Approximate round trip times in milli-seconds:
> Minimum = 49ms, Maximum = 49ms, Average = 49ms

Thank you for that test. We get almost exactly the same result.
Yours finally made it at 1460 while mine make it at around 1470.

Since I get the same 1470 whether I use VPN or not and whether I ping my
home router or not, I don't think we ever needed the "example.com" site.

I think it's just a basic problem with ALL Windows Ethernet boards.
But I'm not sure since I never looked at this stuff prior to yesterday.

If someone else can confirm our numbers, that would help us understand.

> It looks like I don't have Wireshark on here, to capture the
> packets and look at them.

Those wireshark traces are beyond my pay grade based on this output.
https://netbeez.net/blog/ping/

On 5/29/2022 10:47 AM, Jerry wrote:

> I don't think we ever needed the "example.com" site.

What we wanted was

"something on the WAN side"

"equivalent to what we're trying to do -- test of traffic on WAN side"

"example.com has good plumbing"

Any old site would do. Up to a point.

You want simple sites to test against. And
as time passes, there are fewer and fewer "simple" sites.
Because of things like CloudFlare protection.

And remember that this is just a quick test, of the *theory*
that it's related to packet fragmentation handling at high
traffic rates. The idea was, to test this and move on.
As it might not be the problem.

Paul

On Sun, 29 May 2022 16:43:14 -0400, Paul wrote:

> And remember that this is just a quick test, of the *theory*
> that it's related to packet fragmentation handling at high
> traffic rates. The idea was, to test this and move on.
> As it might not be the problem.

I have been testing for a few days now and what happens is that I get
different warning messages by adding just the one line below to the vpn
ovpn config file.

tun-mtu 1450

Here's a short list of the type of errors that result this time.
2022-06-03 01:02:09 open_tun
2022-06-03 01:02:29 tap-windows6 device [Local Area Connection] opened
2022-06-03 01:02:39 IPv4 MTU set to 1450 on interface 17 using SetIpInterfaceEntry()
2022-06-03 01:02:44 Route addition via IPAPI succeeded [adaptive]
2022-06-03 01:02:14 Initialization Sequence Completed
2022-06-03 02:29:09 tun packet too large on write (tried=1500,max=1450)
2022-06-03 02:39:15 tun packet too large on write (tried=1454,max=1450)
2022-06-03 02:49:49 tun packet too large on write (tried=1454,max=1450)
2022-06-03 02:50:01 tun packet too large on write (tried=1500,max=1450)
2022-06-03 02:51:37 tun packet too large on write (tried=1454,max=1450)
2022-06-03 02:53:21 tun packet too large on write (tried=1454,max=1450)
2022-06-03 02:59:23 tun packet too large on write (tried=1500,max=1450)
2022-06-03 03:61:24 tun packet too large on write (tried=1454,max=1450)
2022-06-03 03:64:25 tun packet too large on write (tried=1470,max=1450)
2022-06-03 03:65:07 tun packet too large on write (tried=1453,max=1450)
2022-06-03 04:06:49 tun packet too large on write (tried=1455,max=1450)

I'm not sure what the openvpn client is actually doing about the packet
size but the old warning has been replaced with many of these new warnings.

I'm surprised that it seems to be continually testing a packet size BIGGER
than the one I specified, so the "tun-mtu" command must be just a
suggestion to the openvpn client program and not a hard limit maybe.

On 6/3/2022 11:30 PM, Jerry wrote:
> On Sun, 29 May 2022 16:43:14 -0400, Paul wrote:
>
>> And remember that this is just a quick test, of the *theory*
>> that it's related to packet fragmentation handling at high
>> traffic rates. The idea was, to test this and move on.
>> As it might not be the problem.
>
> I have been testing for a few days now and what happens is that I get
> different warning messages by adding just the one line below to the vpn
> ovpn config file.
>
> tun-mtu 1450
>
> Here's a short list of the type of errors that result this time.
> 2022-06-03 01:02:09 open_tun
> 2022-06-03 01:02:29 tap-windows6 device [Local Area Connection] opened
> 2022-06-03 01:02:39 IPv4 MTU set to 1450 on interface 17 using SetIpInterfaceEntry()
> 2022-06-03 01:02:44 Route addition via IPAPI succeeded [adaptive]
> 2022-06-03 01:02:14 Initialization Sequence Completed
> 2022-06-03 02:29:09 tun packet too large on write (tried=1500,max=1450)
> 2022-06-03 02:39:15 tun packet too large on write (tried=1454,max=1450)
> 2022-06-03 02:49:49 tun packet too large on write (tried=1454,max=1450)
> 2022-06-03 02:50:01 tun packet too large on write (tried=1500,max=1450)
> 2022-06-03 02:51:37 tun packet too large on write (tried=1454,max=1450)
> 2022-06-03 02:53:21 tun packet too large on write (tried=1454,max=1450)
> 2022-06-03 02:59:23 tun packet too large on write (tried=1500,max=1450)
> 2022-06-03 03:61:24 tun packet too large on write (tried=1454,max=1450)
> 2022-06-03 03:64:25 tun packet too large on write (tried=1470,max=1450)
> 2022-06-03 03:65:07 tun packet too large on write (tried=1453,max=1450)
> 2022-06-03 04:06:49 tun packet too large on write (tried=1455,max=1450)
>
> I'm not sure what the openvpn client is actually doing about the packet
> size but the old warning has been replaced with many of these new warnings.
>
> I'm surprised that it seems to be continually testing a packet size BIGGER
> than the one I specified, so the "tun-mtu" command must be just a
> suggestion to the openvpn client program and not a hard limit maybe.

It's possible this has something to do with path MTU discovery,
done at the VPN level.

The network is resilient and has path redundancy. If a segment fails,
we would not want the bottom to fall out of our boat. Network protocols
can route around a segment failure. If another segment is used, there
may be a need to "check the plumbing", push a test packet through, and
see whether it needs to be fragmented to be handled.

I only have a vague knowledge of networking, and there's at least
one other person here who could answer these questions.

On a typical session, I would have expected mechanisms like this
to "act more stable" than yours seems to.

*******

The error message is also bound to show up in Google.

https://www.reddit.com/r/HomeNetworking/comments/dzid1p/need_help_with_mtu_issues_in_a_tunnelled_tunnel/

In an example here, the tuning-person switches (end of thread)
to TCP from UDP. TCP is the "reliable three packet protocol",
whereas UDP is "fire and forget" and UDP requires a reliable layer
on top of it (requesting retransmission on detected packet loss).

https://forums.openvpn.net/viewtopic.php?t=25039

It should be apparent, after reading an infinite number of these
threads, that VPN is "reinventing networking" and leaving exposed
things we don't normally tune. The weird part is how some
of the what-could-be autotuned values are so far off from
realistic values. Even if you changed your end to 500, some
parts of this protocol would still be whining about packets
bigger than even 1500.

Paul