Leaderboard

Hello! We're very glad to inform you that 6 new 1 Gbit/s (full duplex) servers located in Miami, Florida (USA), are available: Aladfar, Ascella, Chertan, Elkurud, Giausar, Meleph. The servers supports OpenVPN over SSL and OpenVPN over SSH, TLS 1.3, OpenVPN tls-crypt and WireGuard. The AirVPN client will show automatically the new servers; if you use any other OpenVPN or WireGuard client you can generate all the files to access them 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, 47107 and 51820 UDP for 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/Aladfar https://airvpn.org/servers/Ascella https://airvpn.org/servers/Chertan https://airvpn.org/servers/Elkurud https://airvpn.org/servers/Giausar https://airvpn.org/servers/Meleph Do not hesitate to contact us for any information or issue. Kind regards and datalove AirVPN Staff

Hi, this happens on a Debian Bookworm machine after upgrading eddie-ui to 2.24.1 Some logs: $ eddie-ui [ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException: The type initializer for 'Mono.Unix.Native.Syscall' threw an exception. ---> System.DllNotFoundException: /usr/lib/../lib/libMonoPosixHelper.so assembly:<unknown assembly> type:<unknown type> member:(null) at (wrapper managed-to-native) Mono.Unix.Native.Syscall.get_at_fdcwd() at Mono.Unix.Native.Syscall..cctor () [0x0000a] in <109e73170c824cceae3aaa135a64841a>:0 --- End of inner exception stack trace --- at System.Windows.Forms.XplatUIX11.UpdateMessageQueue (System.Windows.Forms.XEventQueue queue, System.Boolean allowIdle) [0x000f2] in <1ad3b9c5e8484f3cb4aaaf843739b786>:0 at System.Windows.Forms.XplatUIX11.UpdateMessageQueue (System.Windows.Forms.XEventQueue queue) [0x00000] in <1ad3b9c5e8484f3cb4aaaf843739b786>:0 at System.Windows.Forms.XplatUIX11.GetMessage (System.Object queue_id, System.Windows.Forms.MSG& msg, System.IntPtr handle, System.Int32 wFilterMin, System.Int32 wFilterMax) [0x0001c] in <1ad3b9c5e8484f3cb4aaaf843739b786>:0 at System.Windows.Forms.XplatUI.GetMessage (System.Object queue_id, System.Windows.Forms.MSG& msg, System.IntPtr hWnd, System.Int32 wFilterMin, System.Int32 wFilterMax) [0x00000] in <1ad3b9c5e8484f3cb4aaaf843739b786>:0 at System.Windows.Forms.Application.RunLoop (System.Boolean Modal, System.Windows.Forms.ApplicationContext context) [0x0034e] in <1ad3b9c5e8484f3cb4aaaf843739b786>:0 at System.Windows.Forms.Form.ShowDialog (System.Windows.Forms.IWin32Window owner) [0x001b7] in <1ad3b9c5e8484f3cb4aaaf843739b786>:0 at System.Windows.Forms.Form.ShowDialog () [0x00000] in <1ad3b9c5e8484f3cb4aaaf843739b786>:0 at System.Windows.Forms.MessageBox+MessageBoxForm.RunDialog () [0x00039] in <1ad3b9c5e8484f3cb4aaaf843739b786>:0 at (wrapper remoting-invoke-with-check) System.Windows.Forms.MessageBox+MessageBoxForm.RunDialog() at System.Windows.Forms.MessageBox.Show (System.String text, System.String caption, System.Windows.Forms.MessageBoxButtons buttons, System.Windows.Forms.MessageBoxIcon icon) [0x0000a] in <1ad3b9c5e8484f3cb4aaaf843739b786>:0 at Eddie.Forms.Linux.Program.Main () [0x000cc] in <f3c97e9149814a4b8fca99d0f2530ed5>:0 $ sudo apt upgrade $ sudo apt autoremove $ grep "upgrade " /var/log/dpkg.log 2024-02-29 08:05:53 upgrade eddie-ui:amd64 2.24.0 2.24.1 $ grep "remove " /var/log/dpkg.log 2024-02-29 08:06:39 remove ca-certificates-mono:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:39 remove cli-common:all 0.10+nmu1 <none> 2024-02-29 08:06:39 remove libmono-system-windows-forms4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:39 remove libmono-system-drawing4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:39 remove libgdiplus:amd64 6.1+dfsg-1+b1 <none> 2024-02-29 08:06:39 remove libgif7:amd64 5.2.1-2.5 <none> 2024-02-29 08:06:39 remove libmono-accessibility4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:39 remove libmono-btls-interface4.0-cil:amd64 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:39 remove mono-utils:amd64 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:39 remove libmono-webbrowser4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:40 remove libmono-posix4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:40 remove libmono-i18n-west4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:40 remove libmono-i18n4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:40 remove libmono-system-data4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:40 remove libmono-system-enterpriseservices4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:40 remove libmono-system-transactions4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:40 remove libmono-system-runtime-serialization-formatters-soap4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:40 remove libmonoboehm-2.0-1:amd64 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:40 remove libmono-corlib4.5-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:40 remove mono-runtime:amd64 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:40 remove mono-runtime-sgen:amd64 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:40 remove mono-gac:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:40 remove mono-4.0-gac:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:40 remove mono-runtime-common:amd64 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:41 remove libmono-system-security4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:41 remove libmono-system4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:41 remove libmono-security4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:41 remove libmono-system-core4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:41 remove libmono-system-numerics4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:41 remove libmono-system-xml4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:41 remove libmono-system-configuration4.0-cil:all 6.8.0.105+dfsg-3.3 <none> 2024-02-29 08:06:41 remove libmono-corlib4.5-dll:all 6.8.0.105+dfsg-3.3 <none> Three days ago all went well upgrading from 2.23.2 to 2.24.0 $ uname -a Linux 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01) x86_64 GNU/Linux Thank you for your work!

Caution is advised. That country is well known for IT terrorism and similar activities. Often likely state-sponsored. Unless you need an encrypted tunnel to that country, I wouldn’t touch this VPN provider with a stick.

Correlation != Causation. What if the service was set up by a desperate party because Russia banned VPN usage? Don't you think it makes sense? If you are a Russian in Russia and you cannot pay for the VPN services around the world because of sanctions (those services would give you a less restricted internet, after all), wouldn't you try to find a service which accepts whatever payment processors are available to you? Exactly – learn Russian or ask someone like me to translate for you. Don't go through the world, fingers pointing in crude directions, and voicing mere suspicions. No, it doesn't. Yandex is what Google is to US, or Tencent to China – a provider of various internet services tailored to a specific ethnic group's market. Yandex has got its own networks, which includes targeted advertising and analytics. Why shouldn't Yandex be allowed to offer their services to Russian diasporas across the world? Betteridge's law of headlines states that "any headline that ends in a question mark can be answered by the word no".

I see this as well. I also see when making the upgrade from stable to experimental the following packages are removed: ca-certificates-mono cli-common libgdiplus libmono-accessibility4.0-cil libmono-btls-interface4.0-cil libmono-corlib4.5-cil libmono-corlib4.5-dll libmono-i18n-west4.0-cil libmono-i18n4.0-cil libmono-posix4.0-cil libmono-security4.0-cil libmono-system-configuration4.0-cil libmono-system-core4.0-cil libmono-system-data4.0-cil libmono-system-drawing4.0-cil libmono-system-enterpriseservices4.0-cil libmono-system-numerics4.0-cil libmono-system-runtime-serialization-formatters-soap4.0-cil libmono-system-security4.0-cil libmono-system-transactions4.0-cil libmono-system-windows-forms4.0-cil libmono-system-xml4.0-cil libmono-system4.0-cil libmono-webbrowser4.0-cil libmonoboehm-2.0-1 mono-4.0-gac mono-gac mono-runtime mono-runtime-common mono-runtime-sgen mono-utils Looking at the apt package dependencies, I see eddie-ui:amd64 2.21.8 (stable) depends on: libc6 (>= 2.3.2) sudo curl libnotify-bin mono-runtime mono-utils libmono-system-core4.0-cil libmono-system-windows-forms4.0-cil openvpn stunnel4 libsecret-tools libayatana-appindicator3-1 while eddie-ui:amd64 2.24.1 (experimental) only depends on: libc6 (>= 2.3.2) policykit-1 curl libnotify-bin openvpn stunnel4 libcurl4 libsecret-tools libayatana-appindicator3-1 so some mono deps seem to have been missed.

Version 2.24.1 with some bugfixes released. In some packages, WireGuard was not the default, fixed in 2.24.1. As soon as possible. Tray icon should be fixed in 2.24.1 Fixed in 2.24.1, same issue also for @drum Both under investigation, thank you for your tests and patience! Under investigation, thank you for your tests and patience! Kind regards

Please do enlighten the readers. Frankly, Android doesn't care about the VPN protocol, and neither do mobile operators. Android only cares whether there is a VPN connection active using the VPNService API, which it is if Shadowsocks uses that same API to work. So what you wrote is not 100% accurate. Consider yourself reminded of the fact that AirVPN is a VPN provider, not a proxy provider. Support for any kinds of proxy services will not see the light of day for the forseeable future. Others requested it in the past:Now, Shadowsocks and V2Ray are proxies, SoftEther is not a protocol but a software supporting other protocols in both server and client mode, and "something else" must be named for evaluation.

Starting this topic as a way for me to vent and perhaps see that I'm not the only one to see crazy routing by my ISP. The topic has come up in other threads, with knowledgeable people confirming my belief that ISPs relegate VPN traffic to very low priority. Route testing shows that this low priority isn't based on packet inspection but simply the destination of the traffic (and, I assume, the source). In other words, traffic both directions between us and the server is affected. Trace to Draco, primary IP address 2 [7922] [COMCAST-22] xe-3-1-3-sur02.east.tx.houston.comcast.net (68.85.252.81) 8.8ms 3 [7922] [COMCAST-22] ae-9-ar01.bisbee.tx.houston.comcast.net (68.85.246.65) 7.9ms 4 [7922] [COMCAST-16] be-33662-cr02.56marietta.ga.ibone.comcast.net (68.86.92.89) 30.7ms 5 [7922] [COMCAST-16] hu-0-12-0-6-pe01.56marietta.ga.ibone.comcast.net (68.86.89.18) 24.4ms 6 [7922] [iBONE-CCCS-2] 50.242.148.190 30.9ms 7 [174] [NET-154-54-0-0] be2847.ccr41.atl01.atlas.cogentco.com (154.54.6.101) 42.4ms 8 [174] [NET-154-54-0-0] be2687.ccr41.iah01.atlas.cogentco.com (154.54.28.70) 28.8ms 9 [174] [NET-154-54-0-0] be2441.ccr21.dfw01.atlas.cogentco.com (154.54.41.66) 30.1ms 10 [174] [NET-154-54-0-0] te0-0-0-0.agr12.dfw01.atlas.cogentco.com (154.54.31.114) 41.1ms 11 [174] [NET-154-24-0-0] te0-0-2-3.nr11.b000821-1.dfw01.atlas.cogentco.com (154.24.19.222) 37.1ms 12 [174] [COGENT-A] 38.88.50.34 35.6ms 13 [15003] [NETBLK-NOBIS-TECHNOLOGY-GROUP-06] [target] 64.120.63.90 32.1ms Note it goes all the way to Atlanta, then back to Dallas through Houston on Cogent. Why on earth do they send it to Atlanta to get on Cogent's network? Dallas is only 4 hours drive from Houston and as you'll see from the next trace, Comcast has a connection to Cogent right in Houston. Trace to Draco, alternate IP address 2 [7922] [COMCAST-22] xe-3-1-2-sur03.east.tx.houston.comcast.net (68.85.251.245) 7.7ms 3 [7922] [COMCAST-22] ae-18-ar01.bearcreek.tx.houston.comcast.net (68.85.246.69) 8.6ms 4 [7922] [COMCAST-16] be-33662-cr02.dallas.tx.ibone.comcast.net (68.86.92.61) 15.6ms 5 [7922] [COMCAST-16] be-12493-pe01.houston.tx.ibone.comcast.net (68.86.84.158) 20.4ms 6 [7922] [CBC-COMCAST-1] 173.167.59.42 20.5ms 7 [174] [NET-154-24-0-0] te0-0-1-0.rcr12.iah02.atlas.cogentco.com (154.24.26.89) 21.0ms 8 [174] [NET-154-54-0-0] be2145.ccr41.iah01.atlas.cogentco.com (154.54.1.85) 24.1ms 9 [174] [NET-154-54-0-0] be2441.ccr21.dfw01.atlas.cogentco.com (154.54.41.66) 20.1ms 10 [174] [COGENT-NB-0000] te0-0-0-0.agr11.dfw01.atlas.cogentco.com (66.28.4.50) 21.0ms 11 [174] [NET-154-24-0-0] te0-0-2-0.nr11.b000821-1.dfw01.atlas.cogentco.com (154.24.15.50) 21.7ms 12 [174] [COGENT-A] 38.88.50.34 24.2ms 13 [15003] [NETBLK-NOBIS-TECHNOLOGY-GROUP-06] [target] 64.120.63.92 20.4ms Amazingly, the trace gets to Dallas in the 4th hop, but then heads right back to Houston to get on Cogent's network. It makes zero sense unless you realize that Comcast are doing this crap on purpose. I have rarely seen a route that heads directly to the VPN server upon reaching Dallas, finding Cogent's network there instead of having to get back to Houston. Understand that this is normal, everyday behavior. I have another VPN provider with servers in Dallas and Atlanta. Amazingly, all the Atlanta servers route through Dallas, and all the Dallas servers route through Atlanta. So, the routes are available, but purposely screwed up. Finally, check this out. Instead of tracing the route to Draco, I instead trace the route to Cogent's router at 38.88.50.34, seen in hop 12 above. Check out the premium routing I get now. 2 [7922] [COMCAST-22] xe-3-1-3-sur03.east.tx.houston.comcast.net (68.85.251.249) 10.2ms 3 [7922] [COMCAST-22] ae-18-ar01.bearcreek.tx.houston.comcast.net (68.85.246.69) 9.1ms 4 [7922] [COMCAST-16] be-33662-cr02.dallas.tx.ibone.comcast.net (68.86.92.61) 14.1ms 5 [7922] [COMCAST-16] be-12495-pe03.1950stemmons.tx.ibone.comcast.net (68.86.85.194) 13.7ms 6 [7922] [iBONE-CCCS-3] 50.248.118.246 13.0ms 7 [174] [NET-154-54-0-0] be2763.ccr21.dfw01.atlas.cogentco.com (154.54.28.73) 14.1ms 8 [174] [NET-154-54-0-0] te0-0-0-0.agr12.dfw01.atlas.cogentco.com (154.54.31.114) 13.8ms 9 [174] [NET-154-24-0-0] te0-0-2-3.nr11.b000821-1.dfw01.atlas.cogentco.com (154.24.19.222) 15.2ms 10 [174] [COGENT-A] [target] 38.88.50.34 13.6ms