[PATCH v2] openvpn: Add MTU related options

[Daniel Wagner]

OpenVPN has several command line option to configure how to handle the
MTU of packets. The plugin accepts a OpenVPN.MTU options which is
translated to '--mtu'. This options not available (has it ever
existed?) since 2.0. We recommend at least version 2.2 of OpenVPN.

It looks like no one is using this, because if he did, OpenVPN bails
out and complains about unknown --mtu option.

In this light, let's drop it and add the exising MTU releated options.
---

Changes since v0
- Update documation

doc/vpn-config-format.txt | 9 ++++++++-
vpn/plugins/openvpn.c | 7 ++++++-
2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/doc/vpn-config-format.txt b/doc/vpn-config-format.txt
index 23c9c14..1b49765 100644
--- a/doc/vpn-config-format.txt
+++ b/doc/vpn-config-format.txt
@@ -76,7 +76,14 @@ OpenVPN VPN supports following options (see openvpn(8) for details):
OpenVPN.CACert --ca Certificate authority file (M)
OpenVPN.Cert --cert Local peer's signed certificate (M)
OpenVPN.Key --key Local peer's private key (M)
- OpenVPN.MTU --mtu MTU of the tunnel (O)
+ OpenVPN.LinkMTU --link-mtu Set the TCP/UDP device MTU
+ and derive the tun MTU (O)
+ OpenVPN.TunMTU --tun-mtu Take the tun/tap device MTU and
+ derive the TCP/UDP MTU from it (O)
+ OpenVPN.TunMTUExtra --tun-mtu-extra Assume that tun/tap device adds
+ additional overhead (O)
+ OpenVPN.Fragment --fragment Enable internal fragmenation (O)
+ OpenVPN.MSSFix --mssfix Set uppper bound on TCP MSS (O)
OpenVPN.NSCertType --ns-cert-type Peer certificate type, value of
either server or client (O)
OpenVPN.Proto --proto Use protocol (O)
diff --git a/vpn/plugins/openvpn.c b/vpn/plugins/openvpn.c
index 9ee5795..04b7457 100644
--- a/vpn/plugins/openvpn.c
+++ b/vpn/plugins/openvpn.c
@@ -56,7 +56,12 @@ struct {
{ "OpenVPN.CACert", "--ca", 1 },
{ "OpenVPN.Cert", "--cert", 1 },
{ "OpenVPN.Key", "--key", 1 },
- { "OpenVPN.MTU", "--mtu", 1 },
+ { "OpenVPN.LinkMTU", "--link-mtu", 1 },
+ { "OpenVPN.TunMTU", "--tun-mtu", 1 },
+ { "OpenVPN.TunMTUExtra", "--tun-mtu-extra", 1 },
+ { "OpenVPN.Fragment", "--fragment", 1 },
+ { "OpenVPN.MSSFix", "--mssfix", 1 },
+ { "OpenVPN.MTUDisc", "--mtu-disc", 1 },
{ "OpenVPN.NSCertType", "--ns-cert-type", 1 },
{ "OpenVPN.Proto", "--proto", 1 },
{ "OpenVPN.Port", "--port", 1 },

[Hannikainen, Jaakko]

Post by Daniel Wagner
OpenVPN has several command line option to configure how to handle the
MTU of packets. The plugin accepts a OpenVPN.MTU options which is
translated to '--mtu'. This options not available (has it ever
existed?) since 2.0. We recommend at least version 2.2 of OpenVPN.

I'm currently rewriting plenty of documentation, other VPN types (or at
least L2TP and friends) also have this problem - several properties
which are simply incorrect and probably never used by anyone. I'll
check out the documentation and try to squash the rest of these today.

Jaakko

[Patrik Flykt]

Post by Daniel Wagner
OpenVPN has several command line option to configure how to handle the
MTU of packets. The plugin accepts a OpenVPN.MTU options which is
translated to '--mtu'. This options not available (has it ever
existed?) since 2.0. We recommend at least version 2.2 of OpenVPN.
It looks like no one is using this, because if he did, OpenVPN bails
out and complains about unknown --mtu option.
In this light, let's drop it and add the exising MTU releated options.
---
Changes since v0
- Update documation
doc/vpn-config-format.txt | 9 ++++++++-
vpn/plugins/openvpn.c | 7 ++++++-
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/doc/vpn-config-format.txt b/doc/vpn-config-format.txt
index 23c9c14..1b49765 100644
--- a/doc/vpn-config-format.txt
+++ b/doc/vpn-config-format.txt
OpenVPN.CACert --ca Certificate authority file (M)
OpenVPN.Cert --cert Local peer's signed certificate (M)
OpenVPN.Key --key Local peer's private key (M)
- OpenVPN.MTU --mtu MTU of the tunnel (O)
+ OpenVPN.LinkMTU --link-mtu Set the TCP/UDP device MTU
+ and derive the tun MTU (O)
+ OpenVPN.TunMTU --tun-mtu Take the tun/tap device MTU and
+ derive the TCP/UDP MTU from it (O)
+ OpenVPN.TunMTUExtra --tun-mtu-extra Assume that tun/tap device adds
+ additional overhead (O)
+ OpenVPN.Fragment --fragment Enable internal fragmenation (O)
+ OpenVPN.MSSFix --mssfix Set uppper bound on TCP MSS (O)

Are any of these necessary for any use cases? If they are needed for
something, could the currently specified OpenVPN.MTU be used to derive
proper MTUs for the devices involved?

Cheers,

Patrik

[Sven Schwedas]

Post by Patrik Flykt
Are any of these necessary for any use cases? If they are needed for
something, could the currently specified OpenVPN.MTU be used to derive
proper MTUs for the devices involved?

They are necessary for some mobile carriers. We're fixing the tun MTU to
576 so OpenVPN doesn't die on (I think) Vodafone Germany's networks.

(Though not yet with Connman, it's legacy deployments with
NetworkManager/manual OpenVPN, and some special industrial modems from
Vodafone. I can't say just how widespread the issue is otherwise.)

[Patrik Flykt]

Hi,

Post by Sven Schwedas

Post by Patrik Flykt
Are any of these necessary for any use cases? If they are needed for
something, could the currently specified OpenVPN.MTU be used to derive
proper MTUs for the devices involved?

They are necessary for some mobile carriers. We're fixing the tun MTU to
576 so OpenVPN doesn't die on (I think) Vodafone Germany's networks.

Which of the mtu, fragment and/or mssfix options do you end up using and
with what value?

Post by Sven Schwedas
(Though not yet with Connman, it's legacy deployments with
NetworkManager/manual OpenVPN, and some special industrial modems from
Vodafone. I can't say just how widespread the issue is otherwise.)

Cheers,

Patrik

[Sven Schwedas]

Hi,

Post by Patrik Flykt
Hi,

Post by Sven Schwedas

Post by Patrik Flykt
Are any of these necessary for any use cases? If they are needed for
something, could the currently specified OpenVPN.MTU be used to derive
proper MTUs for the devices involved?

They are necessary for some mobile carriers. We're fixing the tun MTU to
576 so OpenVPN doesn't die on (I think) Vodafone Germany's networks.

Which of the mtu, fragment and/or mssfix options do you end up using and
with what value?

We only change the tun-mtu value, none of the others. It seems to be
recommended to change the others too, but it fixed the problems for us,
and I didn't want to experiment more at the time. Presumably connman
would need to support all?

Post by Patrik Flykt

Post by Sven Schwedas
(Though not yet with Connman, it's legacy deployments with
NetworkManager/manual OpenVPN, and some special industrial modems from
Vodafone. I can't say just how widespread the issue is otherwise.)

Cheers,
Patrik
_______________________________________________
connman mailing list
https://lists.connman.net/mailman/listinfo/connman

[Patrik Flykt]

Hi,

The use of the different MTU options depend on you server and link
configuration. I don't think you can derive it. OpenVPN seems to offer
an option to learn the MTU size by doing some measurements but that
takes around 3 minutes according documentation. I recommend to just
expose those options and let the user decide what he needs.

Well, now the problem is that I have no idea what to add as MTU values
if I need to... Sven's "documented" problem and solution was to use
--tun-mtu, if that is the max sized packet that can go through
unfragmented it looks like the only option one should specify. And
--fragment seems to be needed always in addition to any of the MTUs?
Unless it's the default behavior?

Cheers,

Patrik

[Daniel Wagner]

Post by Patrik Flykt

The use of the different MTU options depend on you server and link
configuration. I don't think you can derive it. OpenVPN seems to offer
an option to learn the MTU size by doing some measurements but that
takes around 3 minutes according documentation. I recommend to just
expose those options and let the user decide what he needs.

Well, now the problem is that I have no idea what to add as MTU values
if I need to... Sven's "documented" problem and solution was to use
--tun-mtu, if that is the max sized packet that can go through
unfragmented it looks like the only option one should specify. And
--fragment seems to be needed always in addition to any of the MTUs?
Unless it's the default behavior?

I don't know if there is a sane MTU configuration setting for OpenVPN. I
reread the documentation several times and it seems you need to pick the
options according your configuration.

[Sven Schwedas]

Post by Daniel Wagner

Post by Patrik Flykt

The use of the different MTU options depend on you server and link
configuration. I don't think you can derive it. OpenVPN seems to offer
an option to learn the MTU size by doing some measurements but that
takes around 3 minutes according documentation. I recommend to just
expose those options and let the user decide what he needs.

Well, now the problem is that I have no idea what to add as MTU values
if I need to... Sven's "documented" problem and solution was to use
--tun-mtu, if that is the max sized packet that can go through
unfragmented it looks like the only option one should specify. And
--fragment seems to be needed always in addition to any of the MTUs?
Unless it's the default behavior?

I don't know if there is a sane MTU configuration setting for OpenVPN. I
reread the documentation several times and it seems you need to pick the
options according your configuration.

Yeah. Those values are left alone for the large majority of deployments
and I've only seen them used to deal with wonky carriers in WWAN
deployments.

Personally, I'd be fine with using the OpenVPN.ConfigFile parameter for
the few cases I end up needing it. (And I'm not even sure whether we're
going to migrate to connman.)

[Daniel Wagner]

Post by Sven Schwedas

Post by Daniel Wagner

Post by Patrik Flykt

The use of the different MTU options depend on you server and link
configuration. I don't think you can derive it. OpenVPN seems to offer
an option to learn the MTU size by doing some measurements but that
takes around 3 minutes according documentation. I recommend to just
expose those options and let the user decide what he needs.

Well, now the problem is that I have no idea what to add as MTU values
if I need to... Sven's "documented" problem and solution was to use
--tun-mtu, if that is the max sized packet that can go through
unfragmented it looks like the only option one should specify. And
--fragment seems to be needed always in addition to any of the MTUs?
Unless it's the default behavior?

I don't know if there is a sane MTU configuration setting for OpenVPN. I
reread the documentation several times and it seems you need to pick the
options according your configuration.

Yeah. Those values are left alone for the large majority of deployments
and I've only seen them used to deal with wonky carriers in WWAN
deployments.
Personally, I'd be fine with using the OpenVPN.ConfigFile parameter for
the few cases I end up needing it. (And I'm not even sure whether we're
going to migrate to connman.)

Good point. I completely forgot about ConfigFile. So

OpenVPN.MTU <n>

should map to

--tun-mtu <n> --fragment

?

[Sven Schwedas]

Post by Daniel Wagner

Post by Sven Schwedas

Post by Daniel Wagner

Post by Patrik Flykt

The use of the different MTU options depend on you server and link
configuration. I don't think you can derive it. OpenVPN seems to offer
an option to learn the MTU size by doing some measurements but that
takes around 3 minutes according documentation. I recommend to just
expose those options and let the user decide what he needs.

Well, now the problem is that I have no idea what to add as MTU values
if I need to... Sven's "documented" problem and solution was to use
--tun-mtu, if that is the max sized packet that can go through
unfragmented it looks like the only option one should specify. And
--fragment seems to be needed always in addition to any of the MTUs?
Unless it's the default behavior?

I don't know if there is a sane MTU configuration setting for OpenVPN. I
reread the documentation several times and it seems you need to pick the
options according your configuration.

Yeah. Those values are left alone for the large majority of deployments
and I've only seen them used to deal with wonky carriers in WWAN
deployments.
Personally, I'd be fine with using the OpenVPN.ConfigFile parameter for
the few cases I end up needing it. (And I'm not even sure whether we're
going to migrate to connman.)

Good point. I completely forgot about ConfigFile. So
OpenVPN.MTU <n>
should map to
--tun-mtu <n> --fragment
?

I'll admit I don't understand OpenVPN enough to answer that. I know that
we're not specifying it, I was under the impression that the Kernel
network stack fragments itself with tun-mtu set, and that --fragment was
to bypass that for… reasons.

IMO one more reason to leave it out of the connman plugin and defer that
to the config file, lest people start tinkering with it without needing to.