New 10 Gbit/s server available (BG)

[Staff 10014]

Hello!

We're very glad to inform you that a new 10 Gbit/s (full duplex) server located in Sofia (Bulgaria) is available: Wazn.

With Wazn, AirVPN infrastructure can now offer 10 Gbit/s full duplex lines and servers in strategic locations all over Europe: Switzerland, the Netherlands, Sweden and Bulgaria, all of them with direct peering with a wide variety of providers and at least two tier2 transit providers.

As WireGuard diffusion increases, such servers will be able to use more and more bandwidth, while the imminent OpenVPN DCO deployment on selected AirVPN servers will also provide for more scalability and performance. According to our tests (*) from Italy, the Netherlands, the United States and Germany (from both residential and business lines) and our statistics, in the countries with a presence AirVPN remains the fastest VPN for consumers in the world, both for available bandwidth and round trip times.
We are confident that the progressive increase of CPU power and available bandwidth, together with our usual commitment against overselling, will further widen the gap.

(*) Tests performed from tier1 providers such as Telecom Italia Sparkle or "near-tier1" ones such as Cogent and Hurricane. Tests performed against a wide variety of well known VPN services, including the most advertised ones.

The AirVPN client will show automatically the new server; if you use any other OpenVPN or WireGuard client you can generate all the files to access it through our configuration/certificates/key generator (menu "Client Area"->"Config generator"). The server accepts connections on ports 53, 80, 443, 1194, 2018 UDP and TCP for OpenVPN and ports 1637 and 47107 UDP for WireGuard.

Wazn supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard.

Full IPv6 support is included as well.

As usual no traffic limits, no logs, no discrimination on protocols and hardened security against various attacks with separate entry and exit-IP addresses and 4096 bit DH key not shared with any other VPN server.

You can check the status as usual in our real time servers monitor:
https://airvpn.org/servers/Wazn

Do not hesitate to contact us for any information or issue.

Kind regards and datalove

[OpenSourcerer 1441]

26 minutes ago, Staff said:

while the imminent OpenVPN DCO deployment on selected AirVPN servers will also provide for more scalability and performance

Small question regarding that. I don't see the respective kernel module in the kernel.org source, and the one from GitHub/GitLab seems broken on mainline kernels. Where do you source your kernel module from?

[Staff 10014]

56 minutes ago, OpenSourcerer said:

Small question regarding that. I don't see the respective kernel module in the kernel.org source, and the one from GitHub/GitLab seems broken on mainline kernels. Where do you source your kernel module from?

Hello!

From GitHub and yes, we have actually experienced various problems we wrote about a week ago or so, that's why you see this relevant delay in deploying DCO. Maybe DCO will have hard time to get its way into kernel.org, as we read of a lot of serious problems unresolved since months, but we'll see. We will keep you informed and we ensure you that we will not trigger a potential bomb in our kernels. If we reach an apparent stable environment, we will anyway deploy DCO very gradually.

Kind regards
 

[OpenSourcerer 1441]

May I ask which kernel version was the newest you were able to build it against? The newer 6.2 kernels abort with a rc 10 for me, so I can't even test this out with my own OpenVPN server. It's a bit sad, really.

[Staff 10014]

1 hour ago, OpenSourcerer said:

May I ask which kernel version was the newest you were able to build it against? The newer 6.2 kernels abort with a rc 10 for me, so I can't even test this out with my own OpenVPN server. It's a bit sad, really.

5.16. Correction, 5.10 We never tried to do it on 6, and we're sorry (and concerned) to hear that. Thank you for the information.

Kind regards
 

[Staff 10014]

@OpenSourcerer

Just in case this is a valuable information for you, ProMind tested and could build OpenVPN+DCO on kernel 6.2.7 (in a Fedora 37 system) without any problem, through the provided Makefile and no modifications at all. Swift procedure, not even a single warning was thrown.

Kind regards
 

[Antonio Quartulli 6]

Hi there, I am the main developer of the OpenVPN DCO kernel module and I am really happy to hear that you guys have been testing it out!
The larger the user base, the faster we can find and squash bugs!

Regarding compiling DCO, we normally strive to have it always compile on the latest kernel.
However, in the past few weeks we were focused on implementing some big and important changes, therefore we had to shift our effort a bit and could not work on compatibility with 6.1/6.2.

However, I think master compiles on 6.2 since a month at least.
I just tested in this very moment whether it compiles on the latest netdev tree and it does. So it should all be good for 6.3 as well!

Regarding issues: if you have experienced anything that could be reported, please do so on GH in the issue page. It's *vital* that users experiencing problems do report them upstream and provide reproducible steps (if possible).

At the moment we still have a few "quite hard to reproduce" issues open and it'd be nice to receive any kind of input regarding them if you are experiencing the same.

[OpenSourcerer 1441]

Well, apparently I was trying to build a tag from November last year all this time without noticing. Problem solved.

[Staff 10014]

13 hours ago, Antonio Quartulli said:

Hi there, I am the main developer of the OpenVPN DCO kernel module and I am really happy to hear that you guys have been testing it out!
The larger the user base, the faster we can find and squash bugs!

Regarding compiling DCO, we normally strive to have it always compile on the latest kernel.
However, in the past few weeks we were focused on implementing some big and important changes, therefore we had to shift our effort a bit and could not work on compatibility with 6.1/6.2.

However, I think master compiles on 6.2 since a month at least.
I just tested in this very moment whether it compiles on the latest netdev tree and it does. So it should all be good for 6.3 as well!

Regarding issues: if you have experienced anything that could be reported, please do so on GH in the issue page. It's *vital* that users experiencing problems do report them upstream and provide reproducible steps (if possible).

At the moment we still have a few "quite hard to reproduce" issues open and it'd be nice to receive any kind of input regarding them if you are experiencing the same.

Hello and thank you very much!

We confirm the "swift and painless compilation". The main problem we experienced is the following one:
https://github.com/OpenVPN/ovpn-dco/issues/14

Unfortunately we don't have much to add on what Schwabe already wrote. We can say that we had the issue only on a single VM (an AWS EC2 used momentarily for this purpose) during our very early testings (Debian 11, 5.10 kernel, OpenVPN 2.6/OpenSSL/DCO etc. in house built). Now that we are testing only on dedicated servers (minimal Debian 11 installation, Xeon E3 or Xeon E5 architectures on HP and Dell servers) we can not not manage to reproduce the issue anymore. Should we get some additional piece of info/dump/how to reproduce/etc. we will definitely inform you. The crashes that we had on the VM had an apparently random pattern, so we can't even say what to do to maximize the reproducibility likelihood, we're sorry. In our configuration some OpenVPN processes are working in UDP, other ones in TCP, both tls-auth and tls-crypt, in all combinations. OpenVPN on the VM was 2.6.0, we see now that you strongly recommend 2.6.2 and of course we will update.

LAST MIN. ADDITION: However, we now read a brand new comment on GitHub about the issue:
 

Quote

The receiving path for TCP connections has been totally reworked (and simplified), therefore this bug is "kinda" invalid at the moment.

Maybe we already built DCO including the TCP rework (on our dedicated server)? Can you tell when the rework and simplification have been committed?

Kind regards
 

[Antonio Quartulli 6]

3 hours ago, Staff said:

LAST MIN. ADDITION: However, we now read a brand new comment on GitHub about the issue:
 

Quote

The receiving path for TCP connections has been totally reworked (and simplified), therefore this bug is "kinda" invalid at the moment.

Maybe we already built DCO including the TCP rework (on our dedicated server)? Can you tell when the rework and simplification have been committed?

 

To use that change you need openvpn 2.6.2 in userspace, which was released just yesterday.

So the tests you performed were still using the old ovpn-dco version. You can easily check dmesg and see what version you have loaded.
If the DCO version starts with v0.1 it means it's the "old" one.
If it starts with v0.2, then you have the newest version including the change I am talking about. Just remember that you must use openvpn-2.6.2 to be able to use DCO v0.2.

Should you guys have a chance to run DCO v0.2 and encounter any issue, do not hesitate to let us know!
Thanks a lot

[go558a83nk 364]

On 3/24/2023 at 4:26 AM, Staff said:

the imminent OpenVPN DCO deployment on selected AirVPN servers

 

How imminent is this deployment?    We're nearing 3 months since this post and I'm eager to test.

[Staff 10014]

2 hours ago, go558a83nk said:

How imminent is this deployment?    We're nearing 3 months since this post and I'm eager to test.

Hello!

DCO must enter a phase where radical changes will not be applied. After that, it must reach a stable release. We will inform you about a new deployment plan which depends on when DCO becomes stable. Check also https://github.com/OpenVPN/ovpn-dco/issues and when the important note on https://github.com/OpenVPN/ovpn-dco is lifted

** NOTE **
ovpn-dco is currently under heavy development, therefore neither its userspace API
nor the code itself is considered stable and may change radically over time.

Kind regards

 

[oassQ9w4cbl4AySZhhth%p36x 3]

On 6/11/2023 at 5:59 PM, go558a83nk said:

How imminent is this deployment?    We're nearing 3 months since this post and I'm eager to test.

imminent is probably like a year or more away. if you are concerned about speeds (struggling to get over 300 mbps without openvpn going insane on latency, then consider migrating to wireguard. I've done that recently and can push 800 mbps through a single gateway. 

[go558a83nk 364]

6 hours ago, oassQ9w4cbl4AySZhhth%p36x said:

On 6/11/2023 at 11:59 AM, go558a83nk said:

How imminent is this deployment?    We're nearing 3 months since this post and I'm eager to test.

imminent is probably like a year or more away. if you are concerned about speeds (struggling to get over 300 mbps without openvpn going insane on latency, then consider migrating to wireguard. I've done that recently and can push 800 mbps through a single gateway. 

I'm using wireguard with great speed now but will be in a nation where VPN access is known to be restricted soon so I was hoping for DCO.  The weird thing is I'm able to connect to my other VPN provider using DCO on my (client) end and it works fine as documentation said it would (that there will be benefit if even just the client has DCO enabled).  But when I do the same for AirVPN no traffic flows but logs say the connection initiated fine.  I doubt that other VPN provider has an updated openvpn version so I'm guessing it's some other little quirk with the VPN tunnel options.

[oassQ9w4cbl4AySZhhth%p36x 3]

1 hour ago, go558a83nk said:

I'm using wireguard with great speed now but will be in a nation where VPN access is known to be restricted soon so I was hoping for DCO.  The weird thing is I'm able to connect to my other VPN provider using DCO on my (client) end and it works fine as documentation said it would (that there will be benefit if even just the client has DCO enabled).  But when I do the same for AirVPN no traffic flows but logs say the connection initiated fine.  I doubt that other VPN provider has an updated openvpn version so I'm guessing it's some other little quirk with the VPN tunnel options.

hmm interesting, only thing i can think of is maybe tls-crypt being enabled on your airvpn one and not on the other or vice versa? compare and contrast the logs with some higher level logging and openvpn should tell you why

[go558a83nk 364]

19 minutes ago, oassQ9w4cbl4AySZhhth%p36x said:

1 hour ago, go558a83nk said:

I'm using wireguard with great speed now but will be in a nation where VPN access is known to be restricted soon so I was hoping for DCO.  The weird thing is I'm able to connect to my other VPN provider using DCO on my (client) end and it works fine as documentation said it would (that there will be benefit if even just the client has DCO enabled).  But when I do the same for AirVPN no traffic flows but logs say the connection initiated fine.  I doubt that other VPN provider has an updated openvpn version so I'm guessing it's some other little quirk with the VPN tunnel options.

hmm interesting, only thing i can think of is maybe tls-crypt being enabled on your airvpn one and not on the other or vice versa? compare and contrast the logs with some higher level logging and openvpn should tell you why

nope, I tried with a tls-auth config for Air and it still didn't work.  It may have to do with compression settings.  I had to use some advanced directives regarding compression to get it to even connect to Air.  I didn't have to do such for the other provider but neither use compression.  So, I'm betting there's a sweet spot in compression settings that'll get it to work for Air.  I just haven't played with it much.

[Antonio Quartulli 6]

22 hours ago, go558a83nk said:

nope, I tried with a tls-auth config for Air and it still didn't work.  It may have to do with compression settings.  I had to use some advanced directives regarding compression to get it to even connect to Air.  I didn't have to do such for the other provider but neither use compression.  So, I'm betting there's a sweet spot in compression settings that'll get it to work for Air.  I just haven't played with it much.

Hi, DCO does not support compression. It is already considered insecure and not recommended, therefore it didn't make sense to have support for it in DCO.
This said, OpenVPN should log an error when trying to use compression with DCO. However, if the option is pushed by the server, something may sneak in. A log may help understanding what is going on.

However, if you want DCO to work, you should definitely disable compression.

[OpenSourcerer 1441]

7 hours ago, Antonio Quartulli said:

However, if you want DCO to work, you should definitely disable compression.

I add: You must absolutely explicitly disable it, and just as explicitly prevent the your client from pulling compression options.

comp-lzo no # <- you must remove this from the config, setting it to no is not enough
allow-compression off
pull-filter ignore comp-lzo
pull-filter ignore compress # <- don't need this with AirVPN

.

[go558a83nk 364]

12 hours ago, Antonio Quartulli said:

Hi, DCO does not support compression. It is already considered insecure and not recommended, therefore it didn't make sense to have support for it in DCO.
This said, OpenVPN should log an error when trying to use compression with DCO. However, if the option is pushed by the server, something may sneak in. A log may help understanding what is going on.

However, if you want DCO to work, you should definitely disable compression.

4 hours ago, OpenSourcerer said:

I add: You must absolutely explicitly disable it, and just as explicitly prevent the your client from pulling compression options.

comp-lzo no # <- you must remove this from the config, setting it to no is not enough
allow-compression off
pull-filter ignore comp-lzo
pull-filter ignore compress # <- don't need this with AirVPN

.

yes, I know that it doesn't support compression.  neither of my VPN providers uses compression and the only way I got AirVPN to connect was to have it ignore the comp-lzo push as opensourcerer wrote first elsewhere in this forum