All US west servers keep having issues

[haruka_ff 0]

This is really a recurring issue now and you might have known this already, but this is really affecting the experiences: https://airvpn.org/issues/  

Half of the recent issues are US west servers having packet losses, and while the status showing around 30% packet loss, in reality those servers just stop replying completely for a little while.

[Staff 10653]

Hello!

We checked our infrastructure monitoring data and can confirm recurring connectivity issues, concentrated on our five Los Angeles servers, not on all West Coast servers though. The recorded issues predominantly affect IPv6. If your VPN tunnel is established over IPv6, it is indeed very likely that these incidents explain the temporary complete loss of connectivity you describe.

The packet-loss percentage on the status page reflects results from multiple monitoring locations. A reading of around 30% does not mean that every connection loses 30% of its packets: connectivity from a particular network can fail completely while other paths remain available.

Is your VPN tunnel established over IPv4 or IPv6? We mean the address used to connect to the VPN server, rather than whether you access IPv6 destinations inside the tunnel. Please also provide the affected server names and, if possible, an approximate incident time with your time zone, so we can correlate your experience with our monitoring.

We apologize for the recurring IPv6 interruptions and we will open a request for investigation with the provider.

Kind regards
 

[haruka_ff 0]

Hi,

I connect via IPv4 to mainly Sarin and Revati servers though. the last issue I had was to Revati, around 07:35 UTC.

[Staff 10653]

Hello!

Thank you, that clarification helps. Since your tunnel endpoint is reached over IPv4, the recurring IPv6 pattern we mentioned does not explain your experience.

We see ICMPv4 nearby packet-loss reports for the servers you named: Sarin at about 07:20 UTC and Revati at about 07:58 UTC. These are close to, but do not exactly match, the 07:35 UTC time you reported. They come from distributed monitoring probes, so they cannot confirm what happened on your particular route.

Could you tell us which VPN protocol and client you use, and whether the VPN connection itself disconnected or stayed connected while traffic stopped? If available, please also share the connection log covering a few minutes around 07:35 UTC, with any keys or credentials removed. This should help us compare the event with the server and network records.

Kind regards
 

[SurprisedItWorks 54]

Quick note: I've been so frustrated the past few months with Los Angeles servers, especially since they are the US "best" so often, that I actually coded up a tiny daemon for my routers to have them detect those servers and if found, automatically switch OpenVPN to a non-L.A. server.  The Los Angeles servers have been so bad that I'm not comfortable leaving family to deal with them all day.

In other words, this issue isn't about one user at one particular time.  There's a bigger problem here.

Broader observation: Before the huge influx of former Mullvad users, I changed OpenVPN servers by hand a few times a year.  Now it's generally every day and often multiple times daily, no matter where (in the US, where I generally "am") those servers are, because the delays and stoppages become intolerable.  I don't know if it's about flood attacks, datacenter issues, or simply too many users.  I love Air for its features, transparency, and strong support, but this downside is real.  (I'm on OpenVPN 2.7.5 with DCO on three router models, all running a recent dd-wrt build using a linux 6.12 kernel.  Multiple Air accounts are involved.)