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.