ANSWERED two sessions to same server causes 2 minute restarts ad infinitum

[FredNurk1 1]

Using openvpn on Linux and had 2 servers using the Netherlands group and once both got killed at the same time (probably a network outage) they went into an infinite loop of restarting in sync every 2 minutes upon timeout - both got the same server and went around again.  My client summary only ever showed 1 session even though both were active and coming from the same IP address.  Fixing one away from the group stopped the behavior.

 

This is a bug Air's end - just letting you know and alerting anyone else with the same problem.  Someone decided to get a bit over aggressive tidying up?

 

Sometimes I got 3-16 of these in the log 1 per sec before the inactivity timeout:

TLS Error: Unroutable control packet received from [AF_INET]213.152.161.68:443 (si=3 op=P_CONTROL_V1)

[OpenSourcerer 1435]

How do you imagine this to work if you connect two clients with the same exit IP to the same AirVPN server on the same port? Not a bug at all. Ensure you are at least using different ports.

[FredNurk1 1]

Problem you try to forward all ports to all sessions?   Is that what you are saying?

 

The real bug here is that the group destinations give the same server to the same account at the same time.  They need to be smarter and have a list and a way to avoid race conditions in connecting different servers to the same account!

 

Thanks,

 

ed: If you use "Earth" you can only have one session!

[OpenSourcerer 1435]

Problem you try to forward all ports to all sessions?   Is that what you are saying?

 

No, I'm not.

 

If you connect from the same ISP IP address to the same AirVPN server on the same protocol/port combo like UDP/443, using the same keys, the first connection will be cut off by design.

 

The real bug here is that the group destinations give the same server to the same account at the same time.

 

If it happens that the best server is the one you are already connected to, it's hardly a bug, isn't it? Especially if the best server is determined every five minutes or so.

[Staff 9973]

The real bug here is that the group destinations give the same server to the same account at the same time.  They need to be smarter and have a list and a way to avoid race conditions in connecting different servers to the same account!

 

Hello!

 

If you resolve a country or a continent or a planet name to determine which VPN server the system will connect to, what you experience is not a bug. When you connect multiple devices with the same key to the same OpenVPN daemon, only the last one receives properly packets, and will cause a disconnection to all the other ones. Not only this is not an OpenVPN bug, but this is a very appropriate and correct behavior: the opposite would be a real catastrophe!

 

Each computer can't know what any other is doing, unless you query Air API to determine the status of your account and make connection decisions accordingly. However, to connect multiple devices to the same servers, we already offer the option to use multiple client certificate/key pairs by the same account:

https://airvpn.org/topic/26209-how-to-manage-client-certificatekey-pairs

 

The other problem you mention. i.e. that a VPN server which goes down is still the "best" server according to some FQDN, is due to TTL. Actually, our authoritative DNS update the records every 2 minutes, but TTL is 1 hour, so on average you might have some DNS server updating the records after 30 minutes.

 

ed: If you use "Earth" you can only have one session!

 

Now that you know that this is not true, let's go deeper into the matter. An OpenVPN daemon runs always in the same core of a CPU. Even with AES-NI supporting CPUs, it's impossible, with our ciphers, to squeeze the full bandwidth we have available. Therefore, some sort of balancing becomes necessary.

 

Last year we implemented a new balancing system which turned out to work very well. Each VPN server runs as many OpenVPN daemons as possible (according to the CPU cores amount), and each daemon lives in its own private subnet. Servers welcome OpenVPN clients at kernel level by sending them to the OpenVPN daemon which is running in the least loaded core. It was a huge improvement when compared to the previous, relatively rudimentary in comparison, load balancing.

 

In this way we have been able to break the previous 900 Mbit/s limit on a single server (we touched around 1.7 Gbit/s on a server with hundreds of connected clients).

 

Therefore, when multiple clients with the same pair connect to the same VPN server, they might have no problems if they are sent to different OpenVPN daemons. However, the likelihood that it happens when such connections occur at the same time is very tiny, because load core competition can cause a core supremacy change in a longer time, given the redundancy of our infrastructure. Anyway, it's not the correct approach, as you experienced.

 

Our users who want to achieve the purpose need therefore to take care, as it is perfectly normal and somehow even trivial, of their own devices by managing correctly the client pairs. It's a 30 seconds job in general and we provide all the necessary tools with an extremely comfortable graphic interface, both on our web site and in our free and open source software for Android, Linux, Mac and Windows.

 

Kind regards

 

P.S. We fixed the typo in the thread ("ad infinitem" --> "ad infinitum")

[FredNurk1 1]

Thanks for your reply

If you resolve a country or a continent or a planet name to determine which VPN server the system will connect to, what you experience is not a bug. When you connect multiple devices with the same key to the same OpenVPN daemon, only the last one receives properly packets, and will cause a disconnection to all the other ones. Not only this is not an OpenVPN bug, but this is a very appropriate and correct behavior: the opposite would be a real catastrophe!

Agree so my subject and original post is valid and it IS a bug as BOTH servers are getting disconnected exactly in sync - once this starts you are stuck and both appear from a distance to be just having a bad day and working at much reduced performance...  (2 min on, 30 sec off) which does happen sometimes without this problem. some time randomising needs to be introduced into the algorithm to avoid this race condition.

[Staff 9973]

Thanks for your reply

If you resolve a country or a continent or a planet name to determine which VPN server the system will connect to, what you experience is not a bug. When you connect multiple devices with the same key to the same OpenVPN daemon, only the last one receives properly packets, and will cause a disconnection to all the other ones. Not only this is not an OpenVPN bug, but this is a very appropriate and correct behavior: the opposite would be a real catastrophe!

Agree so my subject and original post is valid and it IS a bug as BOTH servers are getting disconnected exactly in sync

 

 

Hello!

 

It's an expected and correct behavior due to how OpenVPN and more in general the Internet work. See our previous reply for more details, it looks like you missed the meaning of it.

 

Kind regards