OpenVPN v2.5.1 (via backports) not honouring "fragment" config option #16

New Issue

Brandon Currell · 2024-07-15T10:47:43Z

Brandon Currell commented

2024-07-15 10:47:43 +00:00

Initial Report

Following some NFR maintenance due to #7, we have picked up an issue with link tunnels using OpenVPN and our v23.2 configuration standards.

In order to allow a default MTU value of 1500 for customer presentation, we have a fragment value set on each tunnel. This is the last line of defence against oversized packets if path MTU discovery or MSS clamping do not work / are not supported by an application.

In v2.5.1 of OpenVPN this fragment value is not being honoured and affected packets are being dropped or truncated with a "bad length" message. So far, the only report of this relates to VoIP traffic, however any other applications that don't use TCP, or don't support path MTU discovery will also be affected in a similar way (i.e. VPNs).

Rollout of the maintenance from #7 has been put on hold to prevent further impact.

Temporary Fix

As part of our network software stack, we have a pre-built version of OpenVPN v2.4.7 that we can roll back to on a per-link or per-connection basis. If a customer is experiencing an issue and needs this fix applying, there will be some sort of interruption whilst the tunnels are restarted.

Alternatively, we can rollback the installed version of OpenVPN to the previous stable version to affect all customers on an NFR, however this will require an additional maintenance window and will impact all connections at once.

Investigation

We are investigating whether this is a regression bug with OpenVPN, or an intentional change. Based on that, we will know if we need to update our configuration standards, or wait for an upstream bug fix to be rolled out before continuing our upgrade of OpenVPN.

We will also make an internal decision about how we wish to proceed with the NFR maintenance for #7, either by holding back the OpenVPN upgrade, or by switching everything to use our static built version.

### Initial Report Following some NFR maintenance due to #7, we have picked up an issue with link tunnels using OpenVPN and our v23.2 configuration standards. In order to allow a default MTU value of 1500 for customer presentation, we have a fragment value set on each tunnel. This is the last line of defence against oversized packets if path MTU discovery or MSS clamping do not work / are not supported by an application. In v2.5.1 of OpenVPN this fragment value is not being honoured and affected packets are being dropped or truncated with a "bad length" message. So far, the only report of this relates to VoIP traffic, however any other applications that don't use TCP, or don't support path MTU discovery will also be affected in a similar way (i.e. VPNs). Rollout of the maintenance from #7 has been put on hold to prevent further impact. ### Temporary Fix As part of our network software stack, we have a pre-built version of OpenVPN v2.4.7 that we can roll back to on a per-link or per-connection basis. If a customer is experiencing an issue and needs this fix applying, there will be some sort of interruption whilst the tunnels are restarted. Alternatively, we can rollback the installed version of OpenVPN to the previous stable version to affect all customers on an NFR, however this will require an additional maintenance window and will impact all connections at once. ### Investigation We are investigating whether this is a regression bug with OpenVPN, or an intentional change. Based on that, we will know if we need to update our configuration standards, or wait for an upstream bug fix to be rolled out before continuing our upgrade of OpenVPN. We will also make an internal decision about how we wish to proceed with the NFR maintenance for #7, either by holding back the OpenVPN upgrade, or by switching everything to use our static built version.

Brandon Currell added the

Network software

label 2024-07-15 10:47:43 +00:00

Brandon Currell referenced this issue

2024-07-15 10:48:58 +00:00

GRE + FOU - Null pointer exception resulting in hard crash of network appliance #7

Sign in to join this conversation.