openVPN randomly disconnecting

[grapes2331]

Hello, my openVPN client keeps randomly disconnecting for now reason and i see `IP packet with unknown IP version=0 seen`. I selected MSS fix option within the instance config, but it still seems to happen. I am using the following certification I'm not sure if this is increasing my packet and I need to specify a different MTU.


TLS static key

Public Key Algorithm: Elliptic Curve Cryptography (ECC)

Key Size: 521-bit

Elliptic Curve: NIST P-521 (secp521r1)

Signature Algorithm: ECDSA (Elliptic Curve Digital Signature Algorithm) with SHA-512

[RianKellyIT]

Hey,

The "IP packet with unknown IP version=0" error is a classic symptom of an MTU mismatch causing fragmentation at the wrong layer. When an OpenVPN tunnel receives a fragment that starts with 0x00 instead of 0x40 (IPv4) or 0x60 (IPv6), you get exactly this message. It means a partial or mis-aligned packet is arriving at the tun interface.

MSS clamping helps for TCP but does nothing for UDP traffic or for fragmentation happening at the OpenVPN layer itself. The more reliable fix is to set fragment and tun-mtu in the client config.

Try adding these to your custom options on the client:

fragment 1300
mssfix 1260
tun-mtu 1400

The fragment directive tells OpenVPN to fragment packets at the VPN layer before they hit the tunnel, which prevents the underlying IP fragmentation that causes the version=0 issue. The tun-mtu value accounts for the overhead of the OpenVPN header plus your ECC TLS handshake frames.

The P-521 certificate itself is not adding per-packet overhead once the session is established -- the asymmetric key size only matters during the handshake. But it is worth double-checking your tunnel uses UDP rather than TCP, because OpenVPN over TCP adds an extra layer of retransmission that can compound fragmentation problems significantly.

One other thing to check: if you have any compression enabled (compress or comp-lzo), disable it. Compression can misalign packet boundaries and produce exactly this error, and it offers almost no benefit on already-compressed traffic.

If the fragment + tun-mtu adjustment does not help, enabling verb 4 logging will show you the exact sequence of events leading up to the disconnect and make the root cause clearer.

Hope this is useful.

[grapes2331]

Thank you! I will try this and get back to you if it works.

[grapes2331]

I went ahead and enabled those options but i get an error message. You can see below. It doesn't look like this is supported. Also, I see that there are these same options in the instance itself: Fragment Size, TUN device MTU, and also MSS Fix.



Should this be set in the instance as well ?



I also noticed that the interface was never assigned although it was still green in the GUI. I did go ahead and enable it. The interface has its own MTU and MSS options. Is there anything that needs to happen here?

What I ended up doing is setting TUN device MTU: 1400 and checking the MSS fix within the instance options. I then added only "mssfix" and"tun-mtu 1400" to my client export config.

[nero355]

I went ahead and enabled those options but i get an error message.

Because the account that posted it is SPAMming the web with "Machine Learning Chatbot" nonsense that is either false or outdated !!!

[grapes2331]

Lol, I was wondering that. However, it does seem that the other stuff I did fixed it? My connection is more stable with those other changes I made. The traffic graph also looks like what I'm used to seeing in the OpenVPN Connect UI.