--fragment option not supported

[Muhaammaad]

Any other way to achieve the same result?

[dsommers]

It has been decided to not implement --fragment in OpenVPN 3. This does sound drastic, and it is. But we want to resolve the challenge --fragment resolves differently, with the goal that this will not require configuration changes in the longer run.

We want to implement "ICMP Packet To Big" responses, which should resolve most of the issues for non-TCP traffic. In addition we have full support for --mssfix where you can set the packet size, this targets specifically TCP connections over the VPN tunnel. Both the ICMP PtB and --mssfix feature is already in place.

The reason we don't want to support --fragment is that it is a fairly intrusive change which needs to account for packet reordering and reassembly in the OpenVPN code base. This is something the OS already does way better, as part of their native network stacks. Adding yet another layer of packet fragmentation handling is just not the ideal way to resolve this issue. So by using --mssfix and ICMP Packet To Big instead, we signal to the OS that it needs to do something with the packet before it hits the TUN device again. This way we shift this responsibility to the proper place.

[h1z1]

Curious difference given they do completely different things. Sending back any response advertises the presence of a vpn to begin with. How would that work with bridging non-ip traffic?

[dsommers]

Curious difference given they do completely different things. Sending back any response advertises the presence of a vpn to begin with. How would that work with bridging non-ip traffic?

Well, OpenVPN 3 does not and has no plans to support TAP mode, which would be a requirement for bridging and non-IP based traffic. If this is a requirement for your use case, then OpenVPN 2.x is the alternative, which will continue to live and be maintained for many years forward.

[h1z1]

Good to know. There are still completely valid reasons for using an arbitrary packet size. Besides the case already given, another bigger one is making traffic a little less susceptible to timing analysis since the resulting vpn packets will not align with any particular flow. .

[dsommers]

another bigger one is making traffic a little less susceptible to timing analysis since the resulting vpn packets will not align with any particular flow.

OpenVPN 3 has a better approach of dealing with such kind of challenges, due to it's modularity. You only need to implement a "module" (as a C++ class) which processes the UDP/TCP packets and injects either data to be handled in a specific way on receiving side or adding random latencies in the packet flow (not requiring changes on the remote side) ... or any other clever idea you might come up with.

With this is implemented correctly, you don't need to change anything else than adding such a C++ class for handling obfuscation; the algorithm used for the obfuscation would be clearly defined and isolated.

While I understand that --fragment could be used to provide a working result for such a challenge, it is actually more an abuse of a feature - where the feature would be used for something else than what it was designed for. So I would not even consider --fragment being anything else than a hackish workaround for obfuscation.

[h1z1]

... You only need to implement a "module" (as a C++ class)

That isn't possible for many reasons, portability and quite frankly telling users to download some unofficial module isn't going to fly.

workaround for obfuscation.

Glad we agree on something. FWIW you're not understanding (or trivializing?) the importance of such things on hostile networks. tc can add entropy too but doesn't really address the resulting packet size.

[dsommers]

That isn't possible for many reasons, portability and quite frankly telling users to download some unofficial module isn't going to fly.

This is backwards. If you can come up with a solution which works, you can submit this module to be included in the upstream OpenVPN 3 project. It will go through peer review and it will be a process to get it included. But once reviewers finds the approach reasonable and the contributed source is good, then it will be included upstream in the end; becoming an official part of OpenVPN 3.

FWIW you're not understanding (or trivializing?) the importance of such things on hostile networks

That's quite blunt words. We fully understand the importance of obfuscation, in particular in networks in certain countries. But we also care about code maintenance and quality. We're not going to add a feature which is fairly broken by design, adding lots of fairly complicated code to resolve that feature and then see it being abused for something completely different. Then we rather put efforts solving the real issue first and leave the hackish workarounds behind us.

[h1z1]

If you can come up with a solution which works, you can submit this module to be included in the upstream OpenVPN 3 project.

[...]

But we also care about code maintenance and quality.

By removing a feature that worked in one version, claiming it was replaced by some other function completely outside the scope of that feature?

I could see an argument that it didn't scale as well but even they are doing different things.

[cron2]

Hi,

On Sat, Oct 12, 2019 at 11:28:22PM -0700, h1z1 wrote: > But we also care about code maintenance and quality. By removing a feature that worked in one version, claiming it was replaced by some other function completely outside the scope of that feature?

OpenVPN 3 is a fully new codebase, so nothing was "removed", but features received consideration whether the various tradeoffs speak in favour of "inclusion". As David said, OpenVPN 2 will not go away any time soon, and for anything not in the code base of OpenVPN 3 (tap mode, fragment, ...) it's a good alternative. 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 gert@greenie.muc.de

[h1z1]

Hi,
On Sat, Oct 12, 2019 at 11:28:22PM -0700, h1z1 wrote: > But we also care about code maintenance and quality. By removing a feature that worked in one version, claiming it was replaced by some other function completely outside the scope of that feature?
OpenVPN 3 is a fully new codebase, so nothing was "removed", but features received consideration whether the various tradeoffs speak in favour of "inclusion".

That appears to be your spin on it but when something exist in one version and not in another, it was removed. The feature literally is not there. OpenVPN 3 claims to be "protocol compatible" but is in fact, not. It implements some of v2. The only documented feature difference I can find is lacking server capability. What other protocol differences are there?

As David said, OpenVPN 2 will not go away any time soon, and for anything not in the code base of OpenVPN 3 (tap mode, fragment, ...) it's a good alternative.

It's not an alternative since v3 is not feature compatible with v2. The two will forever diverge leading to v2 being removed entirely some point down the road because it's "old".

OpenVPN 3 has a better approach of dealing with such kind of challenges, due to it's modularity.

.. is a fundamentally flawed statement in this. The feature is apparently viewed by OpenVPN as broken to begin with. Why on Earth would I re-implement it?

[cron2]

Hi,

On Sun, Oct 13, 2019 at 02:21:33AM -0700, h1z1 wrote: That appears to be your spin on it but when something exist in one version and not in another, it was removed.

The naming is a bit misleading, but technically it is not "a new version", but "a new program sharing many traits, bringing new benefits, and not implementing everything yet".

The feature literally is not there. OpenVPN 3 claims to be "protocol compatible" but is in fact, not. It implements _some_ of v2.

One could start splitting hairs on "what consists protocol, and what consists features" - but yes, it's definitely not *feature* compatible, and will very likely never be. One of the drawbacks of OpenVPN 2 is "too many features", so implementation velocity is much worse than for OpenVPN 3 ("too much code that needs to be taken into account when changing anything").

The only documented feature difference I can find is lacking server capability. What other protocol differences are there?

Server capability is, indeed, not "protocol" - both ends speak the very same protocol (negotiation, encapsulation, framing), but "feature". [..]

> As David said, OpenVPN 2 will not go away any time soon, and for anything not in the code base of OpenVPN 3 (tap mode, fragment, ...) it's a good alternative. It's not an alternative since v3 is not feature compatible with v2. The two will forever diverge leading to v2 being removed entirely some point down the road because it's "old".

OpenVPN 2 is open source. So it will not "go away". The existing team might at some point decide that they do no longer feel like maintaining it - in which case, new people can just fork the github repo (or the gitlab or sf.net repos) and continue the work. This has happened about 10 years ago, when the original author had no more time to work on it - this created a somewhat complicated situation for a time, and then David and I sorted it out and took over.

…

> OpenVPN 3 has a better approach of dealing with such kind of challenges, due to it's modularity. .. is a fundamentally flawed statement in this. The feature is apparently viewed by OpenVPN as _broken_ to begin with. Why on Earth would I re-implement it?

--fragment requires lots of extra code to deal with reassembly, while a generic transport obfuscation module (which could insert chaff, modulate packet sizes, wrap everything in a XOR layer, etc.) could do the *obfuscation* better that you argue for, and not require all the extra code and memory handling to deal with reassembly. And, if *you* really want fragmentation as such, *you* can do the work - this is what open source software is about. You want it so badly, nobody else is interested, you code a module for it. So - decide what you want: fragmentation, then use v2, or transport obfuscation, then go for an obfuscation module for v3. But please start contributing, instead of just making demands and complaining. 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 gert@greenie.muc.de

[h1z1]

And, if you really want fragmentation as such, you can do the work - this is what open source software is about. You want it so badly, nobody else is interested, you code a module for it.

This issue wasn't opened by me, or did you miss that?

So - decide what you want: fragmentation, then use v2, or transport obfuscation, then go for an obfuscation module for v3. But please start contributing, instead of just making demands and complaining.

I've made literally no demands of you nor anyone else. What the hell. The best part in this is you appear completely confused as to what this issue is even about. Mind boggling indeed.

I have forked OpenVPN. Cheers.

[cron2]

Hi,

On Sun, Oct 13, 2019 at 10:25:42PM -0700, h1z1 wrote: This issue wasn't opened by me, or did you miss that?

But you were the one who argued most heatedly...

> So - decide what you want: fragmentation, then use v2, or transport obfuscation, then go for an obfuscation module for v3. But please start contributing, instead of just making demands and complaining. I've made literally no demands of you nor anyone else. What the hell. The best part in this is you appear completely confused as to what this issue is even about. Mind boggling indeed.

This might be. The issue here is about --fragment, and David explained that this is a costly feature so OpenVPN 3 does not implement it. You have then started to argue that --fragment is important for traffic obfuscation, where I have said "there are better approaches". But maybe I am confused indeed, and your point was something else completely.

I have forked OpenVPN. Cheers.

You're welcome to do so - this is what Open Source is about. If priorities do not align, projects sometimes need to diverge, and sometimes the original fork then can benefit from the resulting code improvements. So where can we have a look at your fork? regards, 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 gert@greenie.muc.de

[dsommers]

Even though claiming that an OpenVPN Inc employee hijacks this issue, related an OpenVPN project is quite funny, it's time to close this discussion now. This does not lead anywhere now.

If anyone takes the effort any implements --fragment support, it will not be handled via this ticket. Patches implementing this feature will be reviewed and feedback provided accordingly whenever this event occur.