I was developing VPN client for one of the popular VPN provider in the past for iOS and the solution was quite simple - enable on-demand VPN for 0.0.0.0/0
In this case, iOS will always wait until connection to VPN is established before sending any packets out.
Without on-demand, VPN may leak.
If I remember correctly, leaks occurred mostly after waking from sleep but before the tunnel had chance to be set up. Or in similar situations. Anyway, on-demand option solved all of them.
do existing sessions get terminated and restarted through the VPN when you start it? Seems like that's one of the major concerns that the author is raising
I think Apple is transparent about Always on VPN (blocking traffic except over the tunnel) requiring provisioning using MDM tools. Apple Configurator is free and allows anyone to set this up.
The ProtonMail article said it only applies to pre-existing connections, because iOS doesn't force them to close when an app enables its VPN. I'd be reluctant to call that a leak, unless it contradicts Apple's documented behaviors, which as far as I can tell make no mention of a systemwide VPN except for corporate "always on" ones. Besides, is there any reason why you can't just toggle airplane after enabling a consumer VPN to kill off the old connections? Then it should probably be fine.
That's a clever thought. Do you know whether connections could be established outside the tunnel after you disable airplane mode but before the tunnel is re-established?
If that were possible then ProtonMail would have certainly said so, since that'd garner serious attention. In any case, the functionality as a whole isn't documented, so even if it works, Apple could theoretically take it away just like that. That of course doesn't mean we shouldn't rely on it, since if the only other option is a corpnet we're left with little other choice. I have the same problem with Apple because I depend on static binaries. Under the Apple regime, they too have an uncertain future and only continue to exist at Apple's pleasure. It's discomforting but not the end of the world.
Seems targeted at Enterprise customers, not your average consumer.
Kind of a big deal that likely 90%+ of iOS VPN app users assume they're private when they're not. False advertising IMO, and Apple is getting their 30%.
I use perfect privacy and they provide IPSec configs for iOS. Their guide even makes note to enable on-demand to prevent leaks.
Also, just checked Mullvad, which seems to open an IPSec server on your local device and then install a vpn config on your ios device. From the local IPSec server a connection is made to mullvad via wireguard.
On-demand is also enabled by default.
But yea, VPN were initially targeted at enterprises anyway. So I don’t mind that i actually have to install vpn profiles by hand.
I hope Wireguard makes it into iOS/macOS at some point. Still early days relative to other protocols of course but it's so much simpler and more reliable (even beyond the security benefits). I use it extensively on both platforms for access to my own networks and services nowadays.
I think the OP means so that it can be used without an app and so it can be used with Apple's "Always On VPN" setup. Right now I believe "Always On VPN" only works with the OS supported VPNs: IKEv2, L2TP, SSL VPN, and Cisco IPSEC https://support.apple.com/guide/deployment/vpn-overview-depa...
Nope, there are a ton of 3rd party SSL/other VPN clients that use the same frameworks that can be set to always on - the app just has to be written that way.
Here's one of those occasions where Linux mobile is shining, Wireguard(kernel) works OOB in Mobian, Requires custom kernel in postmarketOS due to Alpine quirk.
Considering the added benefits of taking your other desktop Linux security configuration to mobile, A Linux mobile could be a viable choice for those who need reliable transparent security.
It already is? It's been around for ages now and had a lot of eyes over it, but more importantly users. It's being used in a lot of services that are in production and turning over nicely. I think the 'early days' can be put to bed now, it's mature from a security perpective (imho).
Changes to macOS and iOS a few versions back removed third party kernel extensions. So, that’s not an issue anymore.
It used to be a huge issue, but thankfully that’s been fixed. I can’t tell you how many times my Mac crashed due to faulty “enterprise” security kexts.
Well, whatever, but maybe you might like to know that it's a protocol specification, not a .ko soley and has been implemented in the user space is several languages. If you're reading every line of kernel source you compile with better knowledge than all of LKML then fair play to you!
Ahh thanks for the clarification, I didn't know there was a difference.
Configuration profiles are however how you force DoH or disable certain privacy leaks from phoning home to Apple. There are no UI settings for some of the important ones.
> VPNs were always meant to carry internal traffic to a private network, not the public internet
This. And the idea that these so called ‘VPN’ services somehow improve your security and privacy on the internet is laughable. All they do is let you get onto the public, untrusted, internet through a different on-ramp. There is no point to them. The internet is just as untrustworthy through a VPN service as it is through any other internet connection.
> All they do is let you get onto the public, untrusted, internet through a different on-ramp. There is no point to them.
Not true, at all. There are several good reasons to use VPNs to get a different on-ramp to the otherwise untrusted internet.
- Avoid ISP tracking: Your ISP should see only traffic to and from the VPN.
- Access content intended for those in other regions: Many sites and services only show certain content to people who enter the internet from specific places.
- Limit the amount of activity linked by trackers: Visiting certain sites only from different IPs/browsers will help keep logs of that traffic isolated from the logs of your other browsing.
- Allows you to connect to sites and services that cannot connect back to you once you've disconnected: A lot of people, even those with dynamic IPs, keep their address for months or years at a time. VPNs provide a great way to cycle through IPs.
VPNs don't solve every problem, but they're a powerful tool to keep in your tookbox.
There are many many very valuable uses for VPNs some that offer privacy/security benefits and some that are just plain useful. It's wild to hear anyone say that "There is no point to them."
To support multiple sites per IP the browser has to send DNS name of the site to the web server. Moreover, since certificates that the server uses for encryption depends on the site name, the name cannot be encrypted within HTTPS. So the browser sends the name in clear when initiating the connection. This is called SNI, server-name-identification.
It is possible to encrypt SNI, but most sites do not support that as the setup is non-trivial and error-prone.
I use CloudFlare's 1.1.1.1 DNS to mitigate my ISP tracking the domains I visit. They have an iPhone app too. I don't know enough about the space to say whether it's 100% effective.
Again, due to SNI tracking sites that one visits is possible even if DNS traffic is encrypted. At the very least one needs for the site to support ESNI or encrypted-site-name-identification.
But then in practice for ESNI to be effective one needs for the site to use CDN or similar solutions to ensure that there are a lot of sites for the given IP.
I rather have my VPN track me than ISP does. For example, connection to Signal and Kakaotalk servers is used as an evidence of being a member of a terror organisation (!) in Turkey. Evidence is gathered by Ministry of Communications from the ISPs, whom they have to provide real-time connection data to the State including CGNAT records. With a VPN, it is almost impossible (depending on setup, i.e. NAT) to obtain such an evidence - especially for political purposes, even if the VPN provider willingly give logs, no way to prove that info is legit.
I guess it depends who your adversary is. If it's the Turkish government, then you are probably safe to trust a foreign mainstream VPN. If you're trying to avoid scrutiny by a five-eyes western government, you need to be somewhat more careful.
I'm not paranoid, and I have no evidence of anything at all, but it does occur to me that if I ran the US CIA/FBI, I would totally start a company like NordVPN and give them enough money to advertise widely and get sponsor spots on popular YouTube channels.
Sure, you'll probably end up facilitating a few petabytes of copyright infringing torrent traffic every day, but you'll also have a direct connection to countless people who think they're totally anonymous.
> Sure, you'll probably end up facilitating a few petabytes of copyright infringing torrent traffic every day, but you'll also have a direct connection to countless people who think they're totally anonymous.
This is the best part really. No three letter agency is going to spoil their honeypot in order to bust some kid for downloading movies and video games. They've got bigger fish to fry. The more successful they are at keeping their users safe from the copyright goons the more popular and "trustworthy" their little honeypot will seem. Your downloads will still probably earn you another black mark in your dossier, one more thing they could use against you if you ever became a problem for them, but still, free movies, music, and games! Might as well make oppression work for you.
Most people who use VPNs for privacy will readily admit that their use is based on relative trust. They know that ISPs are notorious for harvesting and granting access to browsing data, and they trust that their reputable VPN provider of choice is truthful about their logging and internal data handling policies.
> You just replaced ISP tracking with VPN tracking.
Yeah, that's the point. People have infinitely more choices for VPN providers than for ISPs. The VPN provider could be in another country. You can even run your own VPN on hosted infra.
If your hosting provider makes similar privacy guarantees to a similar VPN provider, then perhaps. For bonus points, use a hosted VM and commercial VPN in serial.
Again though, if the US Government is a potential adversary, there's still risk here. Intelligence services could have a 0-day on your linux distro, or an operative within the hosting company. If they get access, they can turn your hosted VM against you.
I think you just have to assume there's a possibility that the infrastracture can be compromised at any moment. For both of these two options. Guarantees from providers are valid until the day they are not.
Though a point has to be made about using a hosted VM for VPN purposes, you have some level of control about which specific software, configuration and encryption schemes etc. you want to use for your stack. Only downside is that currently there isn't sufficient hypervisor protection from the host kernel afaik.
However I do agree with you that either way, the risk threshold is too high if you are concerned about high level state actors. Neither commercial VPNs nor hosting providers can solve the "anonymity" problem for you.
You can choose your VPN. Your ISP, not so much. It's also possible to run your own VPN on a public cloud or VPS. You might still need to worry about your provider then, especially if a government might request who is renting the server that is sending certain traffic.
There are levels to trustworthiness. I mostly trust my ISP enough to not bother with VPN at home, but when I'm traveling I'll take my VPN provider over a hotel WiFi any day.
"Under the provisions of the Investigatory Powers (IP) Act, it is now possible for the Law Enforcement Agency (LEA) community to lawfully obtain Internet Connection Records (ICR) in support of their investigations. Following the completion of some initial trial activities, work is now underway to provision a national ICR service."
I’ve heard the idea of “competing jurisdictions” advanced here: run your own Wireguard VM in China or Russia and route traffic through that box, with the goal of essentially introducing unfriendly international borders in your traffic. Ideally your Russian VM provider would be uninterested in responding to an American subpoena.
The other concept I’ve heard put out is to add layers - your traffic hits Vultr, then Hetzner, then etc etc. Conceivably if you cross enough jurisdictions you can make it very difficult for a legal adversary to attack your traffic.
Would I bet on this for activities I needed to remain exceptionally private? No - but if I needed relatively consistently low latency traffic and a decent baseline of privacy it might just work.
In the end you have to trust someone or you might as well just stay offline forever. In the US, very few people have much choice in their ISP. If you are lucky you might have more than two options. Many ISPs are known to be untrustworthy. They outright state they will mine your internet history and sell it. If I have the choice between an ISP who I know will sell my browsing history and a VPN which might, but claims not to? Well, I know which one I'm going to pick.
If ISPs don't shut down people's accounts they'll get sued for billions in fines.
There are still open court cases against multiple ISPs for not cutting enough people off from the internet. So far, courts have agreed with the RIAA/MPA who paid good money for the laws we have.
Yes, the media industry is certainly more to blame here. Although, the current ISP oligopoly means that there are less companies to sue or otherwise bully. And it doesn't help that some major ISPs are owned by companies that also produce copyrighted content they want to protect.
Moreover, why do you imagine that the VPN is not being operated by the NSA? THere are really a few different kinds of VPN operators: intelligence services, organized criminals, and legit businesses. You have no way of determining which is which.
Thing is, if you ping experts in the privacy field (like Mike Bazzell, the former FBI OSINT guy who billionaires and celebs hire to keep their personal info off the internet), they will all say the VPNs are a very important tool to create a layer of privacy between you and the site you are visiting and also a good tool to prevent said sites from easily profiling you. No, they are not a panacea -- much like the security universe, the privacy universe requires lots of other active and passive behavioral and technological changes to properly lock things down to whatever standard you require for your threat model. But they are very much an important tool. For a small subset of people it's literally a tool that protects their life.
So yeah, it's a kinda a big deal if it leaks. (Which is why most privacy experts, were you to tell them you were sufficiently paranoid, would have you fire up a pfSense and link it permanently to a VPN service and then run a separate brand of VPN software on whatever device, so that you have two layers going through two companies.)
> who billionaires and celebs hire to keep their personal info off the internet
I also do this type of work on the side. When it matters a device level VPN is never the correct option, because every OS leaks to some extent. They get a device where the cellular components have been disabled and it can only connect to a fixed wifi AP carried by one of their EP guys that tunnels the traffic back to a datacenter.
In the UK if you download a TV show or other copyrighted material without a VPN, you can get a letter from your ISP as a warning together with a list of the content you've downloaded, and they may terminate your service if you continue.
A VPN solves this, and does protect your privacy, so your comment is just needless hyperbole.
> This. And the idea that these so called ‘VPN’ services somehow improve your security and privacy on the internet is laughable.
Actually, they do: Neither your ISP nor the government (assuming the VPN provider is in a "hostile" jurisdiction) can intercept, analyze or modify your Internet traffic when you are using a VPN to mask your Internet access. There have been multiple instances of this in the past [1][2] and ongoing (e.g. DNS [3]), and ISP "middleboxes" have been historically the biggest impediment in rolling out new features.
Ubiquitous HTTPS has shut down a lot of that shit, but until DNS-over-HTTPS becomes actual mainstream DNS (and SSL SNI!) will still leak a lot of information to entities that have a direct financial interest in collecting, packaging and selling this data to advertisers - there is a reason why ISPs oppose any legislation that turns them into "dumb pipes" after all.
Security-wise, at least if you are using any kind of untrusted network (e.g. university campus, public hotspots) a decent VPN software that uses the OS-provided firewall to completely drop any incoming and outgoing packets except for the VPN tunnel connection is also a massive benefit.
The downside of course is that you are now forced to trust the VPN provider instead of the ISP - but at least the VPN provider market is healthy and extremely competitive, which means any sort of shady bullshit would be a virtual death sentence, unlike the ISP market where you are in many cases stuck with one or two options.
Not to forget, VPNs also provide privacy on the "other end": as many providers don't cycle through IP addresses sometimes for months, advertising providers can track your movement across the Internet simply by collecting your origin IP. A good VPN provider regularly changes the origin IP visible to sites you access.
> Actually, they do: Neither your ISP nor the government (assuming the VPN provider is in a "hostile" jurisdiction) can intercept, analyze or modify your Internet traffic
No, you're just delegating those capabilities to some completely unregulated random actors instead.
> which means any sort of shady bullshit would be a virtual death sentence
This assumes that their shady bullshit is discovered by someone. I would bet good money that the vast majority of it isn't. They could be sampling traffic and selling it to other companies without modifying it and users would never be any the wiser.
Honestly, I wish we could get past this broken narrative that VPNs are a panacea.
> No, you're just delegating those capabilities to some completely unregulated random actors instead.
It's a question of trust in the end. Telco providers not just in the US but across the Western world have shown time and time again that they cannot be trusted: traffic manipulation, DNS hijacking, selling data to the highest bidder [1], engaging in open corruption to prevent competition, predatory sales tactics, fee scams, peering extortion [2], misappropriating government funds [3] - name the act and you'll find a dominant ISP having done or still doing that practice.
VPN providers generally don't have that baggage attached.
> This assumes that their shady bullshit is discovered by someone. I would bet good money that the vast majority of it isn't.
I agree, but at least the incentives are aligned completely different than with ISPs. The large ISPs can do whatever they want, even breaking the law, because their consumers have no other choice - rural ISPs will get competition from Starlink soon enough, but people in condos? They're stuck with whatever the landlord offers, and the landlord won't care even if there is competition as long as the monopoly ISP pays higher kickbacks.
> Telco providers not just in the US but across the Western world have shown time and time again that they cannot be trusted
This is true, although there's still a very large risk element here. The average person is not likely to be able to safely determine which VPN providers are trustworthy or not. They also aren't likely to understand their limitations, i.e. they don't grant you perfect anonymity, they don't grant you perfect immunity, they may or may not capture the traffic that you intended or thought.
In that case, is it really a good thing for VPN internet provider usage to be on the rise? All we're seemingly doing is handing people more guns to potentially shoot themselves in the foot with.
ISPs, for all of their transgressions, tend to be registered and regulated companies and that makes it much easier to at least find someone to target with legal action if needs be. The bar might be low but there are some standards to which they have to adhere to. Many VPN providers are nameless and faceless "organisations" with little-to-no regulation or responsibility. It's difficult to know if they take your privacy seriously, whether they are taking adequate precautions not to log, to not leak data or to adequately secure their systems.
Hell, it's entirely possible that your VPN provider is actually just an FBI honeypot on the lookout for people who are only actually using a VPN service because they have something to hide. How would you tell if they were?
I just don't really buy the argument that having different incentives means they are any less likely to be nefarious or negligent.
> Neither your ISP nor the government (assuming the VPN provider is in a "hostile" jurisdiction) can intercept, analyze or modify your Internet traffic when you are using a VPN to mask your Internet access.
This is exactly the problem with VPNs, they give you a false sense of security. When your traffic goes over the public internet, you should assume everyone and their grandmother can track it. So the traffic cannot be intercepted at your ISP, that only leaves a billion other places where it can be intercepted.
> The downside of course is that you are now forced to trust the VPN provider instead of the ISP
To be clear, is what you're saying that it is ok for VPNs to be broken (or at least less bad) because their most popular usage isn't what they were originally intended for?
i will have agree with your definition, but the issue here isn't with the nomenclature, it's with the bill of goods being sold as a service.
what people expect, and what is being sold, is an encrypted tunnel that all traffic goes through, to an endpoint. That this is called "VPN" is irrelevant.
I have a GL-iNet Mango that i have setup to provide "always on wireguard" to a computer in a datacenter i control the public IP for. I haven't tested, but i expect all data sent to and from any devices connected to that Device's SSID to be tunneled via wireguard to the computer in the DC, and therefore, to all outside observers the DC is where my device is. Obviously the ISP can see the session, but since they have no say over the DC endpoint, they have no way of knowing what the traffic is or where it's going. It could just be me doing SSH or video streaming or backups to and from the datacenter, or i could be watching netflix or youtube.
In that circumstance, an iOS device shouldn't be able to leak my local network's ostensible "public IP", since the actual transport layer is outside of the iOS device's control.
With all of this being said, i don't think there's any way to guarantee that leaks are impossible without literally air-gapping your devices and forcing all traffic through something that cannot communicate with anything but the remote endpoint - that is, if the wireguard connection fails, all pings fail, all TCP/UDP/etc traffic times out, and so on. In this manner, probably all things sold as "secure VPN" or as a service that does that are scams. This is the issue that TFA is complaining about.
in a situation where it's life and death - i would find an open wifi access point and connect a wireless bridge device (e.g. tp link TL-WR802N), with an STP ethernet cable to something similar to the gl-iNET mango, with 100% forced wireguard connectivity. I'd only consider this viable after doing tshark or tcpdump on the server i control log access to, to verify that my (local) MAC address and/or stuff like webrtc or whatever are blocked/dropped.
sorry for the length, but i didn't want to make multiple comments all over the threads.
I don't like how the word "proxy" got replaced with "VPN" either, but I think it was to create a distinction between the per-connection, often single-protocol nature of proxies (HTTP/HTTPS/SOCKS) and something that acts like a whole (virtual) network interface.
Maybe that wasn't the original intent, but it's a designed and supported configuration. Many places don't want a fleet of Windows laptops to become network bridges to their intranet. The default configuration for most VPN setups is to route all traffic. If you want to selectively route traffic, you have to specifically set up a split tunnel.
While you could only route client traffic to an intranet endpoint and prevent access to any external services, that wouldn't be very practical in most deployments so a proxy is added on top. This type of deployment is common and has been used for decades.
> You are wrong on this, the private part indicates the privacy it provides not the destination.
I remember using VPNs long before, to my knowledge, people were using them in the way you describe, and I was always under the impression that the "P" in VPN meant "connecting private networks" together over the Internet.
This document from 2001 agrees with me: https://docs.microsoft.com/en-us/previous-versions/windows/i...
"From the user’s perspective, the VPN connection is a point-to-point connection between the user’s computer and a corporate server. The nature of the intermediate internetwork is irrelevant to the user because it appears as if the data is being sent over a dedicated private link."
VPNs were used primarily by companies to allow secure access to their network from the outside. It doesn't surprise me that documents aimed at businesses running Windows servers would describe them in the context of that use case. It doesn't mean that was the entire point, or purpose. It's just one thing they were commonly used for.
At the same time that I was working at an ISP on a product that would let employees from various companies connect via dial up and VPN into their corporate networks (whose gateways were also on our network) several of my co-workers were using a VPN of their own to connect to their home networks, but not to access the resources on those home networks (although some did that too). They wanted to use the internet from their machines at home in order to hide their internet activity from our IT department.
This is basically the same thing people do with VPNs now, only instead of hiding their internet activity from IT, they hide it from their ISP.
VPNs were always used for things other than connecting someone to a corporate network, it's just that most of the general internet population at that time (and I'm guessing you're old enough to remember this) were not aware of the technology and not tech savvy enough to set it up. This is true even for the employees of the companies we had as customers. We had to build entire software products that did nothing but hand hold people through setting up a dial up networking connection. It's not surprising that corporations were the majority users of VPN technology until the rest of the public (who don't have IT staff) caught up, at which point it became increasingly more common for people to use it to hide their internet traffic.
I took it to mean a private network connecting two end points, not necessarily connecting two private networks, just that the tunnel (the network between them) was virtual and secure so the traffic exchanged couldn't be eavesdropped on, or modified, by every random node as it passed though the untrusted internet.
I might have been influenced by the product we were selling though. These were dial up users on workstations looking to access their company's LAN so the idea of connecting two discrete private networks wouldn't have fit as well. There was also a lot of focus on the insecurity of passing traffic (even encrypted traffic) over the internet. We had companies paying us a premium to sign up for the service and host their gateway on our network so that the traffic between the users who dialed in and the company's own network never left the ISPs network (never reached the internet at large). I knew at the time it was marketing and that with a well encrypted connection it shouldn't matter if the traffic ever left our "cloud", but it could have helped to shape my view of the technology.
Clients ate that up too. The internet was scary to them. Being able to say that their employee will dial directly into our equipment, and that no packet would pass through a device we didn't operate until the moment it hits your company's gateway made a lot of companies feel better about letting workers remote in.
Fair, it does seem that "privacy" VPNs are a lot older than I thought and possibly as old as the "VPN" moniker. (Assuming that your project was in the 90s, which it sounds like.)
At this point it just seems like arguing for arguing's sake, but I was rejecting the notion that VPNs were always intended for privacy (along with saying others are wrong for suggesting otherwise). It still seems to me that VPNs did not always imply "privacy", and I think in my sibling comment to this, an RFC from 1999 seems to support that (focusing on "intranets" and "extranets" in the definition of a VPN, and only mentioning encryption once as an optional component, with possibly only authentication instead, or even none).
I agree, VPNs were absolutely not always used to hide internet activity, but sometimes they were. Early on they were certainly most often used by companies to connect networks or to connect to resources on their intranet, the need (and the money) was primarily there, but I'm not surprised that using VPNs for privacy reasons got more popular as time went on. Even back then I thought it was pretty cool/useful tech and I had no LAN to speak of.
I agree with all of that, too! And yeah, I think by now the meaning of "VPN" has well shifted, likely because of the privacy enhancement getting to popular (and I think I've also noticed that terms like "Intranet" and "Extranet" have somewhat fallen out of favor, too, but maybe that's just in my environments).
It's not a question of recollection. Read the acronym carefully. It is virtual and it is a network. Not the destination but the tunnel itself is the network that is private. It was described as such from the start and in no networking context have I ever heard otherwise (correct me if wrong please).
Let's say you have an IPSec tunnel between a branch location and HQ site. The typical solution was GRE where you encapsulate it inside another IP packet that has public IPs only for the destination to decapsulate it. When VPNs came along they added privacy hence the name.
In networking you are not connecting two networks. You are interconnecting three networks! the branch would have its own subnet so would HQ but the VPN also would have its subnet all routed as separate networks. The tunnel network getting privacy because it traverses untrusted networks (back in the day it wasn't typically the interent but ATM, frame relay,T1,etc... "directly" between sites), that's where term cloud comes from FYI the untrusted magic ISP network in the sky.
This might be the most pedantic thread (on my part, too) I was ever part of. :)
The earliest reference to VPN I can find in the RFCs, RFC2547, seems to call the "destination" (the network spanned by the tunnel) the VPN, not the tunnel itself:
"If all the sites in a VPN are owned by the same enterprise, the VPN
is a corporate "intranet". If the various sites in a VPN are owned
by different enterprises, the VPN is an "extranet". A site can be in
more than one VPN; e.g., in an intranet and several extranets. We
regard both intranets and extranets as VPNs."
That same RFC has only one mention of encryption at all, in passing, and as being optional (note the "and/or"):
A security-conscious VPN user might want to ensure that some or all
of the packets which traverse the backbone are authenticated and/or
encrypted.
It does not seem to me that privacy was implied.
I still think that VPNs were invented to connect smaller private networks to a larger private network together, where private != privacy. (But rather related to authorities, such as using "private IP addresses" in e.g. 10.0.0.0/8, instead of publicly routable ones.)
Privacy was a (good, likely popular) option, but just not part of the strict definition of what a VPN is (much unlike today).
Yes, too bad about the downvotes but let me add on that and ask those who disagree what P stands for in WEP and WPA? lol. Wep is wired equivalent privacy.
A connection that does not provide privacy like a GRE tunnel for example is called a tunnel never a VPN or more and GRE specifically connects networks which are typically private.
You can also have VPN between two ASes on on the internet which are public networks. Wrong is wrong. Give me another argument to shoot down against VPNs lol.
The correct term for both private and non-private network tunnels is an overlay network (includes stuff like 6-in-4).
The P in WPA stands for Protection, the P in WEP stands for Privacy, the P in VPN stands for Private. Private and privacy don't have the same meaning, and one does not imply the other. I've cited an RFC from 1999 (RFC2547) in another reply to you that strongly suggests (to my reading, at least) that privacy was not necessarily implied in the notion of "private" (although of course a VPN could provide privacy). "Private IP addresses" in the form of "not publicly routable", but not necessarily with any privacy-providing encryption in the mix, seem closer in meaning in this case, and were often (but not always) part of it.
The same RFC also pretty clearly calls the network spanned by the tunnel, not the tunnel itself, a VPN.
By now, the meaning has shifted.
That being said, I think this is my last message on the topic, since, well... it's quite a lot of wasted time on pedantry (which is totally my fault).
> Private and privacy don't have the same meaning, and one does not imply the other.
These two words have the same root and etymology. The adjective "private" is transformed into a noun using the abstract noun suffix, "cy," to become "privacy." These two words have the same word root dressed as different parts of speech.
Of course they have the same root and etymology. Of course they do not have the same meaning, look them up in the dictionary. A private parking spot is not a privacy parking spot.
They are strongly associated, and the definitions are related. One can not have a private conversation without privacy, and when seeking privacy it is exclusively to do something in private. Contrary to previous claims, one implies the other.
The argument that privacy doesn't mean private, and vice versa, in regards to the meaning any of the letters in acronyms is specious, such as, the word private in VPN does not mean that you will have privacy, because, in fact, any transfer of data between the VPN nodes will be kept private from the Internet at large, thus the transfer is in privacy.
The fallacy you and OP committed (if you are not OP, didn't check) is known as the appeal to definition.
> One can not have a private conversation without privacy, and when seeking privacy it is exclusively to do something in private.
One can have a private parking spot without privacy, though. Or a private pilot license.
> any transfer of data between the VPN nodes will be kept private from the Internet at large, thus the transfer is in privacy
Not if your VPN is not encrypted, which exists, although it isn't very common anymore, for obvious reasons.
The IP address "10.1.1.1" is still part of IANA's private IP address space, no matter whether it is transported in a way (say using an unecrypted tunnel over the public Internet) that provides privacy or not.
> One can have a private parking spot without privacy, though. Or a private pilot license.
This is equivocating between two distinct and separate definitions of "private." You are mixing these homonyms.
In the sense you're using in the quote I pulled from your comment, it means intended for or restricted to the use of a particular person, group, or class, but in the sense that it is used in Virtual Private Network, it means something else, namely not known or intended to be known publicly; secret.
Settling that question was the entire discussion you butted into. I quoted an RFC from the late 90s that shows what meaning of "private" was originally intended, while you seem to a priori assume what "private" means here.
> in the sense that it is used in Virtual Private Network, it means something else, namely not known or intended to be known publicly; secret.
Great. Present some evidence or stop wasting time. My evidence that it actually does not mean that is RFC2547.
> My evidence that it actually does not mean that is RFC2547.
RFC2547 does not support your claim... anywhere.
I'll use Webster's definitions for my evidence. Also, every explanation of what VPN is everywhere on the Internet speaks of anonymity and privacy. This means the P in VPN could only mean free from public attention, secret and NOT for the use of a particular person or group, as in private parking.
a private computer network that functions over a public network
A private network at the time was defined according to RFC1918. It also provides the motivation for private networks/the private IP address space, which was growth, not privacy/secrecy.
It's a happy coincidence that you can sell a "Virtual Private Network" to endusers as a privacy-enhancing machination, given that it already contains the word "Private", even if that was meant as in private parking space, not private conversation.
This reminds me of the people who think public companies (traded on the stock market) are publicly owned (part of the government) and so want the First Amendment to apply to getting banned from Facebook.
> You are wrong on this, the private part indicates the privacy it provides not the destination.
Sorry - that's just not the case, you're retconning VPN terminology. VPNs were originally implemented to replace dedicated WANs and dial-in access to private networks - they were not originally designed to provide privacy for individual access to the Internet. Heck, even the RFC for VPN terminology makes that clear (RFC 2764 is over 20 years old).
Oh, and this:
> There have always been client-access VPNs
If your first exposure to VPNs was from shady privacy-snake-oil salesmen, I can see how you'd think this, but take it from the people who were there before client based VPN access was even a thing: Site-to-Site VPN was the original use case for VPN, and you didn't waste tunnel bandwidth (encryption chips were slow and expensive back in the day) routing general internet traffic over your tunnel...
> Heck, even the RFC for VPN terminology makes that clear (RFC 2764 is over 20 years old).
What it actually says is:
The widespread deployment of VPNs has been hampered, however, by the lack of interoperable implementations, which, in turn, derives from the lack of general agreement on the definition and scope of VPNs and confusion over the wide variety of solutions that are all described by the term VPN.
Some people's ideas of the definition and scope of "VPN" might have involved the requirement that it terminate on a private network, but others would not.
No one ever called GRE or 6-in-4 a VPN, why is that!? Let me copy paste my other comment:
Read the acronym carefully. It is virtual and it is a network. Not the destination but the tunnel itself is the network that is private. It was described as such from the start and in no networking context have I ever heard otherwise (correct me if wrong please).
Let's say you have an IPSec tunnel between a branch location and HQ site. The typical solution was GRE where you encapsulate it inside another IP packet that has public IPs only for the destination to decapsulate it. When VPNs came along they added privacy hence the name.
In networking you are not connecting two networks. You are interconnecting three networks! the branch would have its own subnet so would HQ but the VPN also would have its subnet all routed as separate networks. The tunnel network getting privacy because it traverses untrusted networks (back in the day it wasn't typically the interent but ATM, frame relay,T1,etc... "directly" between sites), that's where term cloud comes from FYI the untrusted magic ISP network in the sky.
> the private part indicates the privacy it provides not the destination.
I wouldn't entirely agree with that (although out of context I do agree).
It's a Virtual Private Network connection, you create a Virtual (not physical) Private Network (between your device and another device/server) there's no real difference between a site-to-site VPN and a client-access VPN other than if the devices at each end route more than just the partner traffic over the private network.
If I connect a "site-to-site VPN" between my computer and your computer, if I add a route to send all traffic for a particular network to your computer as the next hop, that makes it "client-access" for that particular network, if I add a default route it then sends any internet request I make to your device as the next hop.
If your device decides to forward the packets (and probably NAT them) then I now have some privacy for my internet traffic.
VPNs were originally designed to replace dial-up modem connections since the internet was becoming more ubiquitous and it would be far cheaper for someone to connect to their local ISP then use a VPN to connect to their remote network (either personally or usually between sites), than dial directly to their other site (also it was usually far cheaper for one internet connection than a bank of modems and ISDN lines (if you wanted 56.6Kbps or 64Kbps connections)
> It's a Virtual Private Network connection, you create a Virtual (not physical) Private Network (between your device and another device/server) there's no real difference between a site-to-site VPN and a client-access VPN other than if the devices at each end route more than just the partner traffic over the private network.
The difference is one end is not a network but an endpoint part of a network. Multiple client access VPNs can be part of the same subnet.
> If I connect a "site-to-site VPN" between my computer and your computer, if I add a route to send all traffic for a particular network to your computer as the next hop, that makes it "client-access" for that particular network, if I add a default route it then sends any internet request I make to your device as the next hop.
In site-to-site VPN, your computer would need to route a separate site network as would the remote end. With client access only the remote end routes a sparate network. Windows for example cannot be used (unless server versions) to provide site-to-site connectivity because it does not route between NICs. Your tunnel IP is used for connectivity with client access but with site-to-site the remote end expects you to adverise a route or have a separate config for a static route back to some other network on your end which is what it will route (won't work otherwise). Hope that is more clear. You can turn your nix box to a s2s vpn terminator but in every VPN type this requires different config which is why the different terms exist.
You are technically correct that we have a bad naming thing going on here, but I"m reminded of legal principles similar if not identical to "implied warranty of merchantability."
What are VPN services SOLD AS? If they promise something and do not do that thing, then this is a problem. They should be sued or regulated or similar, and they shouldn't be able to get around that, even based on techinical definitions.
They are not proxies because they don't well... proxy your request as in make a second connection on your behalf which is what proxy means. Those VPN services are the equivalent of moving your ISP gateway to someone's datacenter somewhere . They are internet gateway VPNs.
I see no deception or nothing misleading about the service they provide. The fact that you need to trust them more than your ISP and country's network is not unclear to anyone, they even advertise "no log" because obviously they can log if they choose to.
It is preposterous that you call them snake oil when there are so many discoveries about ISPs doing mitm on their own behalf or governments and even in the US/west it is a default that they will sale your location and address along other things as a service. You have no choice in the matter because they are monopolies. It is a simple risk calculation that if I trusr some rando vpn provider over my last-mile or country/locality network I can pay to use them to move my trust boundary to their servers. Now marketers and other hostile parties can buy my metadata from a myriad of VPN providers who all risk to lose their whole business if that deal was ever exposed (unlike ISPs).
I fully understand everything you're saying and you have very good technical points, but (and I would draw this out to a LOT of things in IT) these aren't taken away by MOST USERS. Most users, who are novices in tech, read the "label" of the VPN and presume that they are covered, when we know they are not.
SOMEONE should be punished for this because it's effectively a lie. This is the only way we will actually improve the bad situation you're talking about.
That's the Apple Way though isn't it? Apple says "Do it exactly how we tell you" and you shouldn't expect anything to work if you deviate from the One True Path that Apple has laid out for you. "Think Different, Do As You're Told"
True. I’ve used VPN on iOS to play a second account on some online game. Worked like a charm, so it was definitely NOT a scam. If I wanted to hide my activity / identity from more serious people - I would never use iOS in the first place.
But it’s good to know that there are leaks, anyway.
PS. And I guess all VPNs use the same base VPN functionality provided by iOS, so “is” looks a bit more appropriate than “scam”.
If only you could easily print out the routing table and/or modify it so you could direct the traffic exactly where you want it (i.e. stuff it all through the VPN tunnel)...
...and that's when you realise that trying to configure a device to which you do not actually have full control of is a futile endeavour.
As such, in agreement with many of the others here, I don't consider this much of a bug nor a "scam". It's merely an effect of what VPNs are (an additional network interface) and how routing works, combined with a device whose manufacturer deliberately does not want to put users in full control of the routing table.
The fact that Apple OSes leak your true IP (and thus city-level location) to Apple around your VPN is not an issue to Apple; it may even be intentionally preserved this way to aid investigations.
iOS devices create lot of weird traffic on local network. And the only meanigful-ish other packet trace seems like APNS subscription update and some kind of iCloud traffic, there is probably zero reason why would you want that to go through “VPN” tunnel.
There are times when it might be useful to separate out different types of traffic to separate interfaces. I kind of wish there was an easy way to set rules like "Anything I do over these applications should go through the VPN, some of the random traffic my OS constantly spews in the background should be sent through the unsecured connection, but anything going out to these networks should just be blackholed" but I haven't come across one.
are you saying that a packet leaving iOS and hitting the router's logs, without going through the "VPN" does not leak either your IP to the destination or your destination to your ISP?
I think he’s saying that any sort of network analysis done by someone that doesn’t understand basics of TCP is kinda suspect and may be more prone to errors in the analysis methodology or interpretation of results.
I tend to agree. My only takeaway after seeing that was “if I ever need a 100% leak free tunnel on iOS, validate it”. I certainly won’t be taking any of this at face value without replicating it.
Typically, but it does not summarize this content. The author repeatedly says he doesn’t know much about most of all the things but he also knows he can test things out by just watching the activity in his router logs. And, it’s not good.
the local router shouldn't see any other connections inbound or outbound from the device other than the "VPN" ip you are connected to. I submit that it doesn't take an expert to come to that conclusion. Other comments in this thread explain that the iOS/MacOS kernel keep old established routing tables intact under some circumstances, and that's (one) issue. Another appears to be the unreliability or inconsistency of "airplane mode" and invalid assumptions about that.
> I submit that it doesn't take an expert to come to that conclusion.
Probably not, but if, in the middle of trying to diagnose my car, someone pointed to the muffler and said "I'm not sure what this thing's for." I probably would look for a second opinion on their diagnosis especially if it was "there is a major manufacturing defect in this model of automobile". It doesn't matter if the problem looked like it was staring us in the face.
Obviously I can't spot any major flaws with what the writer put together after a single read or I'd be pointing them out. I'm not calling it wrong. I'm just saying I'd want more verification from someone that has a better understanding of networking concepts to make it less likely that basic mistakes impacted the outcome.
If the write-up has given you enough confidence, all the power to you.
That seems like expected behavior, or at least one worth testing with an IP checker or something on the tethered device. I would be pretty surprised if I connected to a VPN on my mobile device, then tethered to it, and my traffic went over the VPN tunnel. I would just establish a VPN tunnel on the tethered device if I wanted that.
Airplane Mode used to be a true “all wireless disabled” mode, but Apple have relaxed it a bit over time, possibly because it's so frequently used and there are so many services provided by WiFi and Bluetooth now that aren't related to the Internet (e.g. connecting to AirPods or an Apple Watch). They also relaxed what turning off WiFi and Bluetooth in the Control Center (separately from Airplane Mode) do, so that things like AirDrop still work. But I think the options in the Settings app are still meant to truly turn off wireless, rather than just mostly?
Also: if Settings says you're connected to a WiFi network, but you don't see a WiFi icon at the top of the screen, I think that means there's no working Internet connection.
I think airplane mode is intended to comply with the rules for using the device on an airplane. That used to be no radios whatsoever (and device turned off during takeoff and landing).
The rules on aircraft changed, so the feature was updated.
I suspect they wanted the feature changed because it gives them better data when tracking you and other nearby devices and that once the rules for airlines changed they figured they could get away with giving users a false sense of security, which is why the feature is still called "airplane mode" which the public understands to mean everything is disconnected even though that's no longer the case.
I think of it more as cynicism. I don't assume corporations act with our best interests in mind. I assume they will do whatever makes them the most money. Companies make a lot of money using the radios in our devices to track us.
I’m pretty sure “the public” knows that the giant blue (not gray) wifi icon and bluetooth icon in control center means wifi and bluetooth are still working when you press the airplane icon.
> Also: if Settings says you're connected to a WiFi network, but you don't see a WiFi icon at the top of the screen, I think that means there's no working Internet connection.
I wonder if the author tried using an On Demand VPN rule for the default route. That's always what I've done when setting this stuff up. Correct me if I'm wrong, but you don't need a device management profile to enable an on-demand VPN for all traffic. Then, reboot your phone and all application traffic, or traffic that isn't something system (APNS) or management/link-local (dhcp, mdns, etc.) will use the tunnel.
APNS client cert is linked to your hardware serial, so by linking all your non-VPN client IPs together by serial, Apple gets your travel history due to city-level client IP geolocation.
Enough points (APNS is always connected, so whenever your phone is on) and this uniquely identifies you (even if the serial number wasn’t bought with your own credit card).
Then they have to give it to DHS/ICE/FBI/CIA without a warrant on demand, thanks to FAA702.
They, of course, already have all of the cell tower association records, as well as all of the Secure Flight program data from the TSA. It’s not a difficult query to figure out which serial numbers are which IMEIs are which humans.
No I agree on the it's not good that APNS is an exception. I suspect that it's something technical like in order to receive push data in low power states, since the kernel isn't awake, userspace VPN is not involved. In an ideal world you'd be able to choose whether you wanted to spend a little extra battery to bump into a higher power state so that this information didn't leak.
Device-level VPNs are very useful for bypassing geographic restrictions, but I wouldn’t rely on them for hiding traffic from ISPs, unless you are in control of 100% of what your device does.
mac/iOS still needs to do subnet local stuff like renew the DHCP lease and discover other link-local devices using mDNS/Bonjour. The system also periodically makes sure interfaces are “up” so it can seamlessly route traffic between cell and wifi. I would not assume that the presence of traffic where DST != VPN tunnel endpoint means that application traffic is leaking over the VPN. I only skimmed the article so someone correct me if there was a case of that observed. The “bug” where existing connections aren't terminated when you bring a VPN up sounds annoying but I can also see why the system wouldn't force terminate existing connections. The connection to the router’s public IP sounds like a hairpin. I also wouldn't be surprised if user-space VPN is outside of the scope of the APNS connection that the system maintains through sleep states.
Ad blocking is entirely possible. Safari supports ad blocking natively. OS-level blocking can be achieved via a DNS filter which can be run on-device. I use AdGuard Pro to do both:
I use this setup to get mobile adblock while on Verizon (iOS sadly has never let you override the default DNS server for cellular, just wifi). It works more or less perfectly, albeit with a noticeable hit to device battery life... so much so my wife who otherwise loves PiHole on the home network refuses to use it on her iPhone.
Using iOS's built in support for browser adblockers is largely as effective and doesn't come with the battery life hit.
Im assuming this is using a custom iOS device provisioning profile to let you set your DNS for cellular in a way the UI does not? If so, interesting solution!
No, that is one advantage of the PiHole/Tailscale setup, although PiHole wont prevent ads particularly well if at all in major apps like Twitter/FB/youtube etc.
Most of what you see is probably Apple bypassing all VPNs to talk to their own servers.
There are more serious problems though, with any app being able to bypass VPN simply by prohibiting Wi-Fi interface and iOS gladly letting all traffic via LTE, unfiltered. That's been described in https://blog.disconnect.me/ios-vpn-leak-advisory/.
It's well known and pretty sad that these issues go unaddressed for years. VPN developers have little power to change that given that VPN apps run in a walled garden of Apple in a sandboxed environment. Hence the the best effort at this point with a hope that this can addressed in the coming updates.
It would be great if more of these pop up on Apple forums and Apple Feedback with people demanding improvements on transparency and privacy from the company.
So far reading your blog post looks like a recollection of what's been going on.
I really wanna throw an analogy of a bear waking up from hibernation. This is not sensational and just reiterates what's been said before you, yet the title throws a shadow at VPNs just to sound like it.
Would be nice if someone who actually knows what he’s doing looked into this. This guy might be on to something or he might be creating a whole lot of drama about nothing.
For sure. I appreciate when someone admits they don't know something, because that is honest. But OTOH, there was a fair amount of "I don't know why this does what it does" in this blog post. I'd like to see this same topic worked up by someone with more knowledge.
Agreed with most comments here, the implementation is leaky as heck. It’s a ‘best efforts’ VPN service at best and you can tell this especially when in a mall and there’s a walled garden in place. I use iVPN and regularly have to disable wireguard to pass the walled garden to then also regenerate a certificate. Enabling VPN through the iVPN app is hit and miss, likely because Apple have decided to do their own thing and implement ‘Private relay’ instead.
Yeh… Apple, Five Eyes, Privacy is all pretty much an illusion when you have this many devices in this many pockets.
Whatever it is, vpn’s or end to end encryption, it’s all really only as secure as the touch screen controller telemetry logs.
To be clear, I mean the big VPNs that advertise themselves as helping with privacy are actually a scam.
There are obviously some situations and use-cases where using a VPN makes sense (e.g. geo-shifting), but as a general solution for privacy on the internet they make no sense.
Until browsers become more fingerprint resistant, there is zero privacy online. Firefox is making good strides but even with all settings turned to the max (including the about:config settings for fingerprint resisting) it is still able to be fingerprinted by the tools online used to check for this.
"Data is leaving my iPad and not traveling through the VPN tunnel."
It is is interesting how the iPad purchaser refers to "my iPad". He owns the computer. But how much control does he have over it. He runs an OS controlled by a HW manufacturer turned trillion dollar tracking and data collection company. (Apple computers are extremely chatty on any network and phone home 24/7. Apple is fervent about its need to collect and store data from purchasers.^1) As such, he cannot find the problem in the iOS source code, remove the phone home "features", re-compile and reinstall it. The best he can do is complain to the internet.
I have owned various Apple computers over the years, including an iPad. However I never used any Apple computer with an Apple OS for internet use.^1 I only connect them to the LAN. I just think there are better OS, namely ones I can edit, to use for internet-facing computers. For internet usage, I like OS where I can control the routing table. Since I started keeping these computers running "consumer OS" off the internet in the 2000s, the internet has become a vector for pervasive surveillance. I treat computers running Windows the same way. No direct internet access.
In the 1990s/2000s I can recall the "experts" advising against leaving computers connected to the internet when not in use. Today, "tech" companies try to compel people to leave their computers connected 24/7. Not to mention "experts" who believe this is justified because "automatic updates". Granting 24h remote access to unknown people to install software on computers that do not belong to them. Some people call this a "botnet". I do not care for broken software that continually needs fixing. But as the author alludes to when he quotes Steve Gibson, iOS is never broken, it just has not been fixed yet.
1. Today's Apple computers require some connection in the beginning to "sign-up", "register", download "approved" software, etc.
2. Apple computers owned by employers excluded. Also excluded are older Apple computers on which I ran NetBSD.
> In the 1990s/2000s I can recall the "experts" advising against leaving computers connected to the internet when not in use. Today, "tech" companies try to compel people to leave their computers connected 24/7.
There is a lot of wisdom we've thrown away from those days. Software phoning home was viewed as malicious and there were lists of applications that did it to shame companies and warn others to stay away. Pretty much every OS and major application today would rightly have been considered Spyware.
If we'd kept "Never use your real name/info on the internet" the world would be a better place. The rule allowed for E-commerce so we'd still have amazon, but facebook and all its problems wouldn't exist.
Pop-ups were considered evil, and we fought to stamp them out but today the same annoyance is commonplace and accepted, they just show up as modal windows and cookie banner notices.
This comment is a gish-gallop RMS-y soapboxing which is largely irrelevant-to-the-article points: that iPads (possibly all iOS devices) only pass some of their traffic over a VPN connection.
> Today's Apple computers require some connection in the beginning to "sign-up", "register", download "approved" software, etc.
I believe that is not the case. It is strongly suggested during the sign-up process, and some functionality depends on it, but it is not required, as far as I know.
Trying to read through the whole thing, I can't tell if if this is claiming:
a) When a VPN is activated, pre-existing connections will continue communicating outside the VPN, but all new connections happen via the VPN
b) Apple services like the app store and/or certain other apps leak outside the VPN because of a) more than you would expect
c) Apple services like the app store and/or certain other apps leak outside the VPN for other reasons totally unrelated to a)
The author's tl;dr just says "data leaks" but I really just can't follow what that actually means.
It seems like a) is not entirely unexpected or necessarily a problem -- you probably turn on a VPN before initiating activities/apps you want routed through the VPN, so not usually problematic? But b) means it might be more serious than that, while c) would be even scarier?
> I am not a fan of making a VPN connection on your only router, but suggest having a second router dedicated to VPN connections. When you need a VPN, connect to the second router (Wi-Fi or Ethernet), when you don't need a VPN, connect to your main router.
Aka, don't use a device with two network sockets if it is critically important to avoid using one of them.
...and then there is the Apple Watch which doesn't support VPN's as far as i know.
So, when apps can communicate from iPhone->Watch, even with a perfectly functioning VPN on the iPhone your public IP can leak via the Watch (if the app is also installed on the Watch.)
Need to give the article author a lot of slack! If you are here, please read some more about networking :-).
Networking is dynamic it takes many sequential steps to configure. There is no ZAP, it is done. I don't know of an OS that locks out "user programs" until configuration is complete. Yeah, since networking is dynamic that could never work -- "user programs" would be locked out forever!
At the start of the First Test there are packets going to non-tunnel locations at the same time the VPN is being set up, not a surprise. Packet ordering / routing at this time granularity is also not surprising.
Need to take a moment to review the "drop everything" when a VPN is up standpoint. OS Networking stacks don't really understand what a VPN is, it is just an endpoint to route packets. A TCP connection has internal state that is bound to the addresses that were used when it was set up - which is tied to the state of the routing table. A new point-to-point endpoint, like a VPN would invalidate that state. Most (many?) TCP/IP stacks keep a cache of the initial route on the socket. As long as that is still valid (or updated), that is where the packets go. Killing TCP connections for every (temporary) network flap would make a lot more people MAD.
The "DNS" to NextDNS with DoH connection is interesting. This 100% isn't coming from iOS itself. It doesn't support it. So it must be coming from an App. But what app and how? There is a NextDNS app which up front claims "Encrypt all DNS queries on all networks with the official NextDNS app for iOS". The author does appear to have configured the router to use NextDNS, perhaps they also have that App installed as well and it is also hijacking networking to do DNS? A dunno.
The "flood stuff" is interesting, but I think it might just be an attempt to perform STUN to make sure UPD traffic can be transported - to Apple endpoints. I think "second test" is the same thing happening again.
So what is left is the traffic being sent to apple endpoints. Now I wonder how the VPNs the author is using are implemented. The Big Sur VPN brouhaha was because apps were trying to implement a VPN using NEFilterDataProvider instead of a "tun" interface and routing. I wonder if this is just the same issue but on iOS.
Not related, but I do wonder what these VPN services offer in terms of "Firewall" protection or if when you use them ALL ports are forwarded to your device. This would make all of their endpoints a "great target" for continuous scanning for getting inside a network if the VPN user had something misconfigured, like say an experimental Apache, Nginx, PHP, Rails, Django, MySQL project. Doh. Methinks I should spend some currency and experiment. Sadly black-hats are probably already doing this.
I think the analysis has some good points, but the author is lacking a bit of networking skills, so I’m not sure how trustworthy this can be. Two yellow flags:
* vpn gateway address can be different from public vpn exit address. What is the surprising part?
* I don’t know what pings your “uncloaked” public ip address, but still, when using a vpn, you’re using your own ip address to connect to the gateway. So, there’s no real leak - it would be a leak if some packets went _through the vpn_ to 99.99.99.99, because an observer could spot the strange ip and determine it’s the uncloaked source address.
Anyway: who can tell what an iphone or ipad can do? You probably have an associated apple account, et cetera. If you trust such a device for total anonymity, you’re doing it wrong from the start. Pick a Linux laptop for that.
This how routing behavior has been on Mac OS for about 15 years now.
Mac OS route selection always takes into account the source address of the IP packet in addition to the routes in the routing table.
If a socket binds to a particular address, the Mac OS kernel will choose routes associated with the interface that address is on and ignore the others.
thankfully Windows does not do this. if i set interface metrics manually, and a lower metric interface becomes connected, all external traffic will immediately go through the new interface. Likewise, if i switch between wifi and cellular on an android device, all existing connections stop and must be refreshed. to wit, on both windows and android, youtube videos will continue to play, but things like HN or reddit will stop loading until whichever connection takes precedence comes fully up.
I would argue that's the only "sane" way to do it, but then again i'm no network engineer. I just rely on my devices to work this way so i don't saturate the wrong links or get poor upload speeds when i need them.
> Likewise, if i switch between wifi and cellular on an android device...
On an Android (like on iOS), both WiFi and Cellular interfaces can be active at once. Apps (with appropriate permission) are free to bind to either.
> ...all existing connections stop and must be refreshed.
On network changes (in particular address changes), TCP connectivity may break. SCTP / QUIC / UDP (and UDP-based protocols like WireGuard and MoSH) should continue to work just fine.
I remember recently using Cloudflare Warp and using one of those webpages that tell you your IP address and it showed my real IP address. It was a bit weird.
Warp is not designed to hide your address. If website is behind cloudflare, it'll know your IP address. If website is not behind cloudflare, your address will not be available.
> WARP was built on the philosophy that even people who don’t know what “VPN” stands for should be able to still easily get the protection a VPN offers.
> From a technical perspective, WARP is a VPN. But it is designed for a very different audience than a traditional VPN. WARP is not designed to allow you to access geo-restricted content when you’re traveling. It will not hide your IP address from the websites you visit. If you’re looking for that kind of high-security protection then a traditional VPN or a service like Tor are likely better choices for you.
So it's a VPN but it doesn't do anything that you expect from a VPN? It doesn't let me access devices in a LAN, it doesn't hide my IP, it doesn't change my country... then what is Warp good for?
If you have the paid version you get anonymous IP, otherwise it uses you own IP.
I use their own speed test page to check my IP and location of the cloudflare server I'm using.
https://speed.cloudflare.com/
There was some communication (forum,discord) that this would change in the future. Apparently the plan was or is to hide the IP from pages on Cloudflare as well.
But no idea if that’s implemented yet.
In this case, iOS will always wait until connection to VPN is established before sending any packets out.
Without on-demand, VPN may leak.
If I remember correctly, leaks occurred mostly after waking from sleep but before the tunnel had chance to be set up. Or in similar situations. Anyway, on-demand option solved all of them.