Not connected, Your IP: 216.73.216.3
Online: 40029 users - 478688 Mbit/s total BWAll Activity
This stream auto-updates
- Past hour
-
-
-
-
-
- Today
-
-
-
-
-
-
-
Any idea when a full M-Series Arm client will be released for Mac?
-
-
-
after a BUNCH of trial and error, thankfully, AI helped me get it figured out. I had to do a bunch of changes in my OPNsense to redirect the port and I am honestly not even smart enough to try and touch on it. I actually reported this thread in hopes of it being deleted but they never acknowledged it
- Yesterday
-
Eddie Desktop Edition 2.25 beta released
harold.lewis replied to Staff's topic in News and Announcement
sorry, I'm still having problem, some result here: (µ/ýXÌÈNå„T0ÎÈ ÿœ·¾>²Ç¬.˜ƒµéRßýpî–Fð? =:ømgä¤ÈŽT’”\¹‰hwï÷Uà(jÖP3RKÉþÖú¼F©ä«Èžf=ð*Ô‘|n$ª½Bå“ g/›ú¼»ùIÃO¦rA‘go7ýb?Çõü°4f¶ê÷a)WsóèÙmêŒ2O©•”xÝOöz(ÏX#¨úÙÌo·ÏPàø}Vªëõ¹›Ë´›å26?Û¢3•ÿOÛDg¢ÌœYHÏÄñ]wj5;u¡’«ã7ÆLV(£«P/·PÉÕR¨äj¸¶¦šuÙ¨_Ïeíw·,%Ê^ñ÷uÿwö®¥Á°ô¯ø–\ͯé¾+ñ‹éí–œ}3OÞ¦vW¢FWæÎ)•·Ý°?Ž_Å﾿kóC[·û!Ÿ¿ÓŠ•J³ýMvȯëþóý»>̹{wÖú±¿Wµ¾ä*‹Ÿ©P1S¢,˜RûÉýé¿-Ìo×Ü^Íí³öîVûªý(¤]±äêZF»îwËŒ`þøZ&ƒ'µ»oG•\={÷<UnS«½äêv¹Ðî¼£À¼;ïb^ÓžÍÞ5ëw¸Ñ“j§TRTD0æü™zÕ]H»ìîíï+»{ËîÞ²Rª»üT>[ÛD[™góÊ«W–=ù[Ù’«¡Êfq›œ-¹ú?,eŲ¨Ï£lŒåêß,Ê–\Q`ø}¡Í–\ͦv?˶&ù7Ë–\Õ}h-¹ZrÖU3òd¿–\ÓÊà Ìù;ûŠR\*ÙܧÙ×¼–\e½j?ÛUe×”]O~]×Õ³gëš|¡kÉÕs]y¹fóûõZrÿfõšÙýÙÖTõžz5¿zºjÉU·ŒZr5ôümUñTQºô±ÑÝ'ËË¡+¹šulF¦õœ—\…™_÷ïYþöÆÇ0¹ä*k«¼lW^rUÔo™üå|Z‰yïÍÃqµÊ)sóñæÍ_™ATÃ/Õ<¹¨j“—\EqP•7L:Y [•þM÷›Ž½ý) õiÉÕDâYÆöš¹ívyZr5-¹ºSÔç_µó3=uZrõ£%W¿ÙïzoU™ìþl‹šZ±=‰(Ÿí’«ù³[&Û§l‹äJ\…ŸŸû¤®åO½ÝÔ'Ó¬yÊÎ’«Ü÷R–¿Pv®¸¬=7{~¢ų̂”¸Ï’«áYrUÅØgB0õ²{õoyžØvÝú,¹j¶fëš%WÝ}rYëöómUs©|-?GñkùiŽ§™²_צ8v®Ý½jSÔ— ‹†Ÿ6µYrUü¶î÷*S¬û–9ƒáwú²äjXŠ¾ìeÉU÷UË“lŸ1³UK±,¹²@ö/Cùéij)ÓßÕ«×_¿â–q˜éŽ,ÑÃlò“å½ëŽ`øµ\—\åÉ%WQß›1¢>33Q«CZ(%‚ã©[õ;Mþ±:¦¾²?•ÿ÷ü(ñ;ÁñÛŸ«e|n–«§Þî ?V¯3ÞO`˜?q»fGµ)ÛQ<öåÜ{›UïÙÝ[ïÙ<}n÷ÿoyòîk²¾]÷)f4ŸyLÁ|rÁL#Of·'×U¦®²Ô }ÿûÑæY'»Ý“ÕëŠÒ«v7Ëù죳Ôç÷Œ£³?Û3s=g©T¯úœé¾¶ælîÛ¾¶fiÎÂÙJåyé¶ùªÀðÕý”e‘'k¿×OËN2–‰ øi™È…Ø÷{ξÝ=}(ÊE®a¬ž¾Ìzý3˜?æóÉz”Ì»©o{õÁðS}/¹zSl÷~›¦æfOÓV=ÿ©æ¶tßÿ¥»“Ç“›Üm]wiOV¦Žé‰£hÉÕ¡YÛ7ªîÕ [soî~}æÏ÷w‡b*4S*¢K%µëî’Õ¦Fæ*•RMvÈë’«9ç“xzËsüıäê)Å“ÙõìV={ªå©úÕTµºW¼^ý§ µ'Ë…b+ 3ÿûY-‹¡J76~g»ªûl×uSC;~[ÆUý©›u·gÛóÔÛmÍØYÆrQ ö_ëÝd[O&³7?¶õdVªo¥òÞoõÔ¶]2¨f’yA‘5’awo¿Uì$Ky)¦¼D}ŸÝ+Ûº\ÆîOË4™î5ïYM&ƒá35™¢>!žÁÓç[¿ú28Š¢Pó7‚ùB¿0Ì¢PçbίJý;÷[·s0|ÆòŒÃOmÛ¯~öô~êþ,?}îö®îœý›åbóÊa_¯Ì`æ©^wªWÞuWU-ôiî©*jÃÏ“áªï5¹*çlþýiVó(~ì†õ!˜ÙªB0ñkQ–ÁRª…`*0³/Lìí‡cçj‡ i!XÊabøñ®OSe0ä°¦2ÌœmX d}««û Ë +ݲ×ä«ÏŒ™·D] Ë_çfÊÕ³ý¯bû[XOMT•¡ÀüyT–†gÊ;Ûßt«üMÁ“ø ¡ï˜³˜Á¨ÃÏÿ4•Uuw¿Oß©T¡ö¨J©¬D—JÎB›Ë¾q]];°óóvŠý‘'cì§#x3xâÉ_ìƒá§ªæ?wiõ‹ý,‚âçEpÅÃo³Üuß5öݽêí©é{¶mºýö§.¿OU2²Àðšµn÷>毟ދ>ͬ0CѧzÝ0Óû”åÿo¿¿>ûû•¯›?ÅòEÑPµ*W¨‚¬“fÓ3(~åë¦#Úº9ƒã×·šá²Žûs0Ìֵˊy~¢¿§t>ÅÕNÁÕè‚*0ìéšöTDÝÝÏý]ݳ¹»oÝÏòï››L٦٫ÿeOiÙu:s‰:¥TR.••ŽŸvÿl~ÇÏ¿ì^O<Ùäj[®C>u:ñä–M}}M3ë{Õ4ƒ£WS©’««?³äª ?±äjªJYs[¡¿Y¡ž@ñû|Ê__yZråiç®é¿oa¶ÿ?)Ûýªf»ÓxÃOMwzÅOÃ(~%Wgú–3Þ¿Ø™Š`þÖòLÇ3=}§Ï5Ó|ÇÏe}'0üD·U[ÓLEpÌŸi¦ù+õê3Ó˜N3Ûš®NCÿíU§±Ÿ~nûµúšªNÇí_dùÍëÚšßöï˜ùÉKý½]¿ÿªéÞîÞ.ʶ¬?{g÷SÏéÛ,OÙ=†,žñ+ÏÏä_¯m‹fPä¿”£lk~¶Íß_QØg‡üÉ_mEå˜î_«¨ŠŠù›µèv9ÊO'ËQd…຿:¨o«<}EPÔl¹¾°O<â—î¾¢(ÁÐÕ¨8‚ùûmëî˜Fó©5:‚ù3µF=*¢_÷Y»Áðe|¶¿Fg;%‚ùÓ}ÕnÊîÏj˜É²2ªnP5äêÏîu«d(ñC‰lë~s«{5~®–qt¯òç¦ëoÛ’£û$‚â—sÞª˜=*î”øí®ìåÞÝ2¶5¿–oÌÔýKYþwêê;ý*\!¸úöÊ?ûº9ÇNŽAÕ÷}ûþf{ž<êUŸ²T`þTÏúPàéS×ÙkÛÒlO–˜òn3Yý™Û{ö\âWÆëÕ³ùÁT6]0<¹v×qŸ|=Ôå爢üÁ0§ÙMØéGðž¾Ïn®š0CPüÜÝ»^÷)‚áV9úõöÇü>¿újt‡'0<ÃœgŸK‘ma¨çìßò\‰à¢¾D•çŠ`ê+ÏÌß™eú<«OuU †Ÿ»»ºa_,Ç=ûçûëî¯rôóýU'PäÉŸï/8~Lâ×ß¿ýïC®‚*0›³›úÜ-Ôö·£Àüu}önž@Öv[sü¶Q¶¿û¹[å}ݬö'0çif•Ž&‚©ü¥¬VMÌ__[³Œ©Pnæï³Üízm]Ø)ƒ"ˆÊ°¾WŸæ-«]ÝÏÓóýÚÃy²ªnW<e0ëÚº\›Ì_ër?ªÜL»†¬PCñóûk“£ü»Ûü´¹]ý™bçfºv…¶Z–o™SŸO[·u?Wë–¬ŠŸÈêߎ«;®Àü}Ûú’«Ÿ™ýª¥ D}fP¬^÷«–bÇÏkµLÛz^ž@‘åT…`þ̲u5V¯Ÿé¼.3(~lËÿVûÚšÌk1EõÁ¼.Ço{ 3˜ÁðSK]ž>V?wÿÿšBè7žÊ0ƒáמüÓ¬þzH—¹,QcJ…µÊ.•òäô¦2˜¿ÓkûßÓ—U ØþWü\̧Ͽ-7õù~îÿ#¸Añ[×ØGâ·ÝÖüDÞý÷CPÃü™íɹéÇ“X–ÜCUÈÊ¡ø‰l›¢r˜Ob(~)ËÝ¡Ë¡þúü`¦+–\MQߪ·û}ï)0ƒã綫«{Ïã·¶bβ}¾!x?¯¶íÿNÞº'›½Êÿj¾(”mÍo(mÕ¶·?ƒ*PdyúªõÀæÏûöÓ^Í øi¯Žß ÁümW.G?íÕÁÌ“?¿UŽ¶nÿNW›Ÿöê^7ìlkòÓçÝÖ»¯ùéϵˆ ÁÑu2§5?Ïjÿ±6Äê/¨,%†`¦ÂÅTf*¯x others distros version or portable will download... maybe something from my side? -
Eddie used to choose non-US server by default. Also, if you have a particular server chosen, and for some reason it disconnects and then reconnects automatically - it does not go back to that server you were on. It again chooses a US default server. Is there any way to specify which servers you want defaulted?
-
When I open the program, I can’t access the user interface. It appears in Task Manager as a background process.
-
I have the same problem. I uninstalled it ,deleted everything and still the same. What do you mean "Enter this in Explorer and delete the default.profile." ??? -
Did you configure UFW or iptables to allow the port through?
- Last week
-
-
-
-
Hi, I am running Eddie on an Ubuntu vm with a connection to a Whonix Gateway vm which is where the connection to tor is coming from. I can connect to servers fine and and get good download speeds but there is no info in the latency column. I'm assuming this is because of eddie is using ping to check latency and UDP is dropped over tor so it cannot do this. I know the page on tor (https://airvpn.org/tor/) recommends to configure the connection mode as tor in eddie's preferences but I'm trying to keep this as simple as possible. Is it expected that the latency column won't populate under my setup? If I managed to configure eddie to use the socks port and control port on the Whonix Gateway would that give me latency data? Thanks
-
-
Greetings! I cannot get the port forwarding to work for reasons unknown. This photo shows what I have listed in the client forwarding area. Both scratched out ports are the same number. And here in SoulSeek (Well, nicotine+ client) I have the matching port number, with no typos, specified in the settings to match up with what was allocated to me from AirVPN. Port check fails miserably, and I've tried other apps like torrents instead with the same result -- port is closed. Not sure what else there is to do or what I'm doing wrong, any guidance would be great. OS is an Arch Linux variant for aarch64 devices, running KDE desktop Thanks kindly!
-
.thumb.png.8be84fd39f94c1640ac8c5456fbf3449.png)
Headless Linux - unable to connect via wireguard
Staff replied to mefflecakes's topic in Troubleshooting and Problems
Hello! We can't reproduce the problem on London servers, entry-IP address 1 and 3, port 1637. Since you have PPPoE please force WireGuard interface MTU to 1280 bytes and test again: the problem seems consistent with a too large MTU. Note that currently about 1200 active and working connection slots are operational and working through WireGuard on UK servers (most of them to port 1637, entry-IP address 3). Is anybody else experiencing this specific problem? Kind regards -
Fixed, thanks for the report.
-
What is your response to the requiring of OS-Level Age Verification in California? For companies like AirVPN, what does it even mean to indicate an age during OS Setup? Are you planning to withdraw your servers from there? -
Anyone using Bitcoin full node over Air server?
reversevpn replied to Kepler_452b's topic in Off-Topic
I've got a Monero full node + P2Pool over AirVPN server. BTC seems too difficult to mine and doesn't have the same privacy protections. -
Headless Linux - unable to connect via wireguard
torup302 replied to mefflecakes's topic in Troubleshooting and Problems
Hi, just adding another data point here. I’m experiencing very similar behaviour to what the OP describes, starting within the last 24–48 hours. WireGuard tunnel comes up normally Handshake appears to succeed transfer: X B sent, 0 B received No DNS, ICMP, or TCP traffic ever returns through the tunnel This is consistent across multiple AirVPN WireGuard endpoints (UK/London and others) and ports (including 1637). Environment: Headless Linux server WireGuard via Gluetun / wg-quick IPv4 only Same network where OpenVPN (TCP 443) connects and passes traffic immediately I’ve tried to eliminate local causes as thoroughly as possible: Multiple AirVPN servers and ports -> same result Local firewall disabled -> no change MTU adjustments ->no change Hard-coded endpoint IPs -> no change Explicit DNS (1.1.1.1) -> no change OpenVPN TCP works immediately on the same host and network I captured traffic on both LAN/VLAN and WAN (PPPoE) interfaces: Outbound UDP packets do leave my network Source IP is correctly NAT’d to my public IP Packets are sent to the AirVPN WireGuard endpoint No inbound UDP replies are ever observed on WAN This suggests the packets are leaving correctly but no return traffic is making it back, ruling out local NAT/firewall issues on my side. What stood out to me in this thread is the report that Eddie only works once “Check DNS” is disabled. While I understand WireGuard itself is not DNS-dependent, the overall failure mode (handshake established but no usable traffic) matches my setup almost exactly. At this point the behavior feels consistent with either: a WireGuard backend routing issue, or something affecting the return path for WireGuard traffic on certain networks Happy to provide redacted packet captures or server names if that would help narrow it down. -
-
Eddie Desktop Edition 2.25 beta released
Tech Jedi Alex replied to Staff's topic in News and Announcement
Can reproduce. You may build eddie-ui-git from AUR instead, this one works. -
-
Better search/filter/tools on Servers list
Tech Jedi Alex replied to airtxt's topic in General & Suggestions
You may find this useful, then.. -
-
Eddie Android edition 4.0.0 preview available
Staff replied to Staff's topic in News and Announcement
@Erquint Hello! Thank you for your tests! Beta 2 has multiple problems and it turned out to be too unstable on various Android versions. Please hold on, beta 3 is addressing the problems you experienced and coming out soon. Kind regards -
Still working on it, probably release it when it's good enough
-
Eddie Desktop Edition 2.25 beta released
harold.lewis replied to Staff's topic in News and Announcement
Not able to download the experimental version of Linux Eddie VPN Client for Arch: is returning 'Error Code: 500 Internal Server Error' -
Eddie Android edition 4.0.0 preview available
Erquint replied to Staff's topic in News and Announcement
Ouch, it seems I jumped the gun with my impression of Beta 2. It worked well the first time I launched it after updating. But now it seems very broken. Tells me I can't pick a server without logging in, despite me having done that in a previous launch to cache the internal bootstrap configs, fails to log in without manual tunnelling first, and the worst part is that it freezes and crashes all the time now while logged in. This is way unstable compared to Beta 1. Maybe a clean reinstall can remedy this, but I'm sticking to never logging in for the time being until I get to testing that. -
Headless Linux - unable to connect via wireguard
mefflecakes replied to mefflecakes's topic in Troubleshooting and Problems
Just re-enabled ipv6 on my router, PC and Eddie but still no luck 😕 I've got nothing set on the router that should block traffic. Very strange. -
Headless Linux - unable to connect via wireguard
Staff replied to mefflecakes's topic in Troubleshooting and Problems
Hello! Holy moly... If you have disabled IPv6 on your system but you kept IPv6 layer on Eddie then the IPv6 DNS and route check correctly fail. Kind regards -
Headless Linux - unable to connect via wireguard
mefflecakes replied to mefflecakes's topic in Troubleshooting and Problems
Well I've disabled IPv6, might that do it? :D -
Headless Linux - unable to connect via wireguard
Staff replied to mefflecakes's topic in Troubleshooting and Problems
Hello! On the contrary. This means that Eddie could not resolve names on the specific DNS set on the system after the connection was established. If the handshake failed there was no communication between your system WireGuard and the VPN server. If the DNS check is disabled and the connection works, then the handshake is successful and the previous DNS check failure was a false positive. On your Arch Linux machine: the handshake is successful. DNS check fails on IPv6 while it is successful over IPv4. However, on Alphecca IPv6 and DNS6 work fine (just tested). Alkaid was decommissioned in 2019, so it must not appear on Eddie and you should discard Alkaid-specific profiles. Maybe you meant a different server? Try to disable Eddie's DNS check just in case it's a false positive or it is related to IPv6 problems in your machine. On your macOS machine: the handshake fails, so DNS is not (and can not) be checked. WireGuard does not communicate with the servers at all. Any anti-malware tool that might block communications? Kind regards -
Headless Linux - unable to connect via wireguard
mefflecakes replied to mefflecakes's topic in Troubleshooting and Problems
Hello, Thank you for the quick response. To clarify, I am experiencing this specifically on the Netherlands cluster (specifically Alphecca and Alkaid), but the behavior persists across several other EU nodes. Per your request, I have attached the Eddie System Report from my macOS machine captured immediately after a failed DNS check. As requested, I confirmed that if I disable "Check DNS" in Eddie, the connection establishes and data flows normally. However, my primary concern remains my headless Arch Linux server using native wg-quick. On this machine: I am using a generated WireGuard configuration with hardcoded IP endpoints to bypass any potential airdns.org resolution issues. The handshake consistently fails (0 B received) despite the server being reachable via ICMP ping. I have verified that systemd-resolved is active, and I am manually specifying DNS = 1.1.1.1 in the interface config to ensure I am not relying on internal VPN DNS for the handshake/initialization. If the DNS is strictly local, it is unclear why the Eddie "Check DNS" toggle acts as a "kill-switch" for the entire tunnel establishment on the same network where a native WireGuard handshake is failing. Attached are the Eddie reports you requested, I'm happy to focus on just ensuring we get Eddie connecting, because if this is an issue relating to my network configuration in some way then everything else should fall in place. Arch Linux - Eddie_20260301_170720.txt ArchLinux Sysreport.txt MacBook Pro SysReport macOS - Eddie_20260301_170301.txt
.thumb.png.0acb24d52aa5119bbf3f4e3b1254873a.png){kind=tracking}
