Re: [Openvpn-users] OpenVPN tunnel stopped working (no traffic) after upgrade to OpenVPN 2.7 (Fedora 44)

Hi,

(ignore my other mail about "please retry the dump", I can see it here)

On Thu, May 14, 2026 at 10:09:25PM +0200, Piotr Dobrogost wrote:
> On Thu, May 14, 2026 at 9:58???PM Antonio Quartulli <[email protected]> wrote:
> >
> > This looks interesting, but please don't filter for "icmp", because on
> > the uplink interface you can't see what's inside the OpenVPN packets.
> > So here you are filtering for "outern ICMPs".
> >
> > Please rather filter for "host xyz.sfx.pl" and do the test again.
> 
> [miner@hostx ~]$ sudo tcpdump -i enp5s0 host xyz.sfx.pl
> dropped privs to tcpdump
> tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
> listening on enp5s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
> 22:03:30.738318 IP hostx.45356 > xyz.sfx.pl.netmagic: UDP, length 96
> 22:03:30.738358 IP hostx.45356 > xyz.sfx.pl.netmagic: UDP, length 96
> 22:03:30.738509 IP hostx.45356 > xyz.sfx.pl.netmagic: UDP, length 99
> 22:03:30.738540 IP hostx.45356 > xyz.sfx.pl.netmagic: UDP, length 99
> 22:03:30.747016 IP xyz.sfx.pl.netmagic > hostx.50139: UDP, length 139
> 22:03:30.747019 IP xyz.sfx.pl.netmagic > hostx.50139: UDP, length 493
> 22:03:30.747019 IP xyz.sfx.pl.netmagic > hostx.50139: UDP, length 142
> 22:03:30.747019 IP xyz.sfx.pl.netmagic > hostx.50139: UDP, length 142
> 22:03:30.747178 IP hostx > xyz.sfx.pl: ICMP hostx udp port 50139
> unreachable, length 175
> 22:03:30.747196 IP hostx > xyz.sfx.pl: ICMP hostx udp port 50139
> unreachable, length 529
> 22:03:30.747203 IP hostx > xyz.sfx.pl: ICMP hostx udp port 50139
> unreachable, length 178

"Someone is confused about UDP port numbers".

So you are sending UDP packets with a source port of 45356, and the other
side is sending UDP packet to a destination port of 50139 (this should
be the same port), to which your system says "I know nothing about
50139, go way".

I have no idea how that can happen, and *only* happen if DCO is involved
(because no matter what DCO thinks "the source port is" the other end
should reply to that).

Can you dump

 - including the initial openvpn handshake (so we can see if userland
   and kernel agree on the port numbers)?
 - on the other side (so we can see if "something on the way" is messing
   up this)?

... and please do check "nft list ruleset" if there is some weird 
NAT rule that messes up the port numbers...

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             [email protected]

_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

-----BEGIN PGP SIGNATURE-----

iQGzBAEBCAAdFiEEti5qK05WVwt73GvgHYKe/spWKBIFAmoGLUgACgkQHYKe/spW
KBJ0GAwAjsew72tAJDQ1ajLbnOcgnbMMvurJq1u26OVy8igxmwuQweeNAKDFaPnK
hLit6VP82V1lFAGj0RIMkVQ4IlnGlhPCOxTrs4FLR++gu6IBm0dfkr9SMSTj8Wcf
6UTP+ZykHqYPuqaQE7kuEakpPnDmFbX7juYo5pdnHHk6OmJWTaYICCorwcnNwQkP
RtzHBSK4JYHGyiR2MSkTT+mo2DWTh3zy1oNaG09C06XrAZG2EFrULKw4FBcXyXXr
/x+CJAdpRDgy3GBLz8ODjwFgFitJseUOKTClqbIC83SbHoBcEJqlcpTRzySdDdJJ
eLwmnIvxe2a0kwp3BOOubyjAh4HRK48Cydz2n/ZTb0D2QI3eVmTFThhxsoczEYO3
T6QXVb2hF+6hxqWS13LjOH1/uwVl9LD8LUx1XHVbOwSbUv6RF26YJeZF62YkV75A
EUVmVjrOX8Beh/Ce20Ru4dDo6H66RbEYyxyw8zc/Fo3XSmLMu8zlIWCzTFHjA6Hp
/uJJ64Y9
=jNAn
-----END PGP SIGNATURE-----