Leaderboard
Popular Content
Showing content with the highest reputation on 08/22/23 in all areas
-
1 pointHello! We did not want to imply that. IPsec is widespread and remains a protocol suite of paramount importance. Together with some tunneling protocol such as L2TP it also provides a variety of VPN solutions both in a host-to-host transport mode and in a network tunneling mode. Under many aspects, IPsec offers a variety of solutions which OpenVPN does not offer (WireGuard can not even be mentioned as it is too rudimentary). AirVPN does not need them, but they are very important for so many companies. Unfortunately, even nowadays, legitimate suspicions that IPsec was targeted by the Bullrun program suggest a very cautious approach to IPsec. AirVPN discarded IPsec in 2010 for legitimate suspicions which became more and more substantiated after Snowden's "revelations" (AirVPN predicting the risks of IPsec three years in advance was a mixture of careful inside considerations and luck/ability to select the correct rumors among the background noise in 2009 and 2010). See for example https://en.wikipedia.org/wiki/IPsec#Alleged_NSA_interference Kind regards
-
1 point
ios App
OpenSourcerer reacted to benfitita for a post in a topic
Let me use the search function in this forum for you... Searching for "ios app" (double quotes are needed to find exact phrases). Here's one of the most interesting results, but there are more, if you serach yourself. Here we go: One might wonder how other VPN providers manage to have iOS apps and publish their source code under GPL. I guess some nitty-gritty licensing details might be in play. Or maybe they don't care about that one perceived limitation of GPL and violate their own license? It would be interesting to go to their communities, if they have any, as ask how they manage to do this. -
1 point
ExpressVPN has invented their own new VPN protocol called "LightWay". How does AirVPN compare to their new one?
–Phase– reacted to OpenSourcerer for a post in a topic
Yes, I don't see a documentation as well. Not entirely a red flag for me, as the code is there at least. But it seems like it's expected to work with ExpressVPN clients only. Remains to be seen, give it a few months. Small remark: QUIC != HTTP/3. HTTP/3 is about to be QUIC's most prominent user, yes, but otherwise you can put other layer 7 protocols into it, e.g. DNS-over-QUIC. Unfortunately, it is bizarrely overshadowed by a CLA which grants ExpressVPN some interesting rights over your contributions. You can argue that OpenVPN does have that, too, but that exactly is a reason why AirVPN is not upstreaming OpenVPN3 changes as of now. A VPN protocol that is only usable with one company, such as NordLynx, is not really a protocol, it's a way to bind you to the company, like a gift or "membership" card. -
1 pointOy vey. First things first: I sigh every time I see a brand. new. thing. that's supposed to be hyped. Parts of commentary will be overly negative just for this reason. I will start with howtogeek In this article they have FOUR referral links to ExpressVPN. Considering ExpressVPN's ("eVPN" for short later on) business strategy, it's not surprising but it is an indicator of a conflict of interest. Two more links to their own article's to "choose a VPN", ExpressVPN pays this outlet to be on top, clearly. This is reflected in the price. Protocol's promises I do not see a technical explanation. Red flag. They are targetting an average Joe with marketing, not catering to advanced audience with technical details. Hence all the statements below are just ones we're supposed to believe. OpenVPN3 includes a new driver that's virtually instant. There's the open source 3rd party OpenVPN app for Android (iirc "OpenVPN for Android") that allows you to enable the new driver in app's settings. Try it out with AirVPN and see the difference to the old method. I've not used WireGuard myself but I suppose it's as good as anything can get, especially on a Linux machine (Android?) where it's inside the kernel. The goal to be fast on mobile is true, however that's less to do with a protocol and more about the software client. On mobile you'd want to suspend and resume (reconnect) as quickly as possible to conserve battery power and to allow quick wake ups (especially to fetch notifications). I suppose an improper setup across the stack will cause issues everywhere, since modern phones rely on TCP keep-alives and open connections to get push notifications and updates. Break that and you get delayed updates and battery power problems. I don't know what's the current state of this and I doubt they've thoroughly tested and addressed this concern. Read this as: no better than the default approach. You'd really need a definition of "reliability" here. I know on a desktop computer, OpenVPN does handle intermittent drops quite well: my connection completely drops every now and then - while connected these cause less issues than a direction connection in a game I play. Further, OpenVPN does support "floating" clients, those changing IPs, at a protocol level. Whether it's actually enabled is a valid question towards your provider and config. A good example will be Google's QUIC aka HTTP/3 that will be run over UDP (that's why 443/udp should work without ISP throttling already) and support clients with changing IPs natively. If anyone, they've made the most considerations about protocol features and quality. There really isn't much technical info to talk about so just a few comments about their blog post. There. However there's no commit history (code changes). This should raise an eyebrow. Either they will never update it again in this place (has happened before with other companies) or they don't develop using git (doubtful). Otherwise I see no reason to scrub the change history; this means this code repository is separate from their actual working project and makes it more likely to be abandoned, hence qualifying it to be yet more of a marketing stunt. Time will tell. To be honest, they do show some love to their other repositories. The license is good. The security audit is fair all along. However I did not see it testing this specifically as a network protocol. Especially the encryption part. As a verification for my statement (from the audit PDF): According to this only the code was part of the audit agreement? Also the audit mentions how the server/client they received binaries that had differing library versions. This would point to a lack of a central build system or a discrepancy in library versions there. Not optimal. The code Obviously I'm not gonna try to audit nor understand anything. At a quick glance: Buffer bloat. The never-ending topic in networking, that's just getting neglected as of late. Setting it to 15MB is just welcoming overloading and lag for clients. There's no easy answer but this ain't it. The protocol may be fast to connect but it isn't lightweight. Still considerable overhead and I'd argue (don't have hard numbers) it is heavier than OpenVPN/Wireguard. Also due to protocol overhead this piece: internal MTU currently hardcoded to 1350. This is still a hell hole of a topic for OpenVPN too, but this proves OpenVPN should have far less overhead if configured normally (not necessarily optimally). Only IPv4 support. While they may eventually tunnel IPv6 inside IPv4 and other tricks, I do not see any real consideration in the source code to suggest they even planned for real to support IPv6. This is supported by the hardcoded MTU since IPv6 has MTU path discovery (automatic configuration in other words). It's 2021 and still no IPv6 in sight. I do not see how it should be faster than OpenVPN in terms of CPU overhead. Each packet read/write is probably still doing a roundtrip through kernel/userspace. There's pretty much no escape. My overall impression: they do not have a hardcore networking guy on the team. It doesn't mean the protocol will remain like this forever, for an in-house technology they can improve in whatever direction they like. My Verdict: Nothing special at all about it. Yet more marketing buzz. OpenVPN3 but especially Wireguard should be considered, unless there were specifically cross-platform considerations in their case. Though did I not drill enough into you that you end up paying for marketing? No, they chose a paid agreement with you. ExpressVPN will pay HMD Global (today's "Nokia" smartphone manufacturer) to preinstall their app on Android phones. I don't know about you, but I hate bloat. AirVPN's anti-marketing stance was a bonus with me. ------------ While my post might've sounded overly pessimistic, view it as nothing more but a hype and marketing-stopper. Especially until they deliver on technical details, considerations and benchmark results under different conditions (reproducible). I've little doubt that speed of connection is fast, but that's the easiest part. Especially if one used the 0-RTT TLS (idk) which is not without its security implications. Yet another rabbit hole. PS: Notice how this article of howtogeek has 2 very peculiar affiliate links: (ExpressVPN) https://www.uxnzmft.com/?offer=3monthsfree&a_aid=howtogeek&data1=content&data2=221929 (TunnelBear) https://www.dpbolvw.net/click-3607085-14014041?sid=CT221929 That's going to great lengths to ensure the tracking of your marketing campaign works from start to finish (i.e. one can't bypass the referral link by just entering the domain name). The innate repulsion for mainstream stuff isn't a bad thing... I know you asked just for a protocol comparison and it ended up being more than just that. But I will also add AirVPN are working on enabling Wireguard, their early estimate for an experimental enablement was September.