A "slug" is a layer-2 bridge, with no IP address configured, that still enforces a TCP/IP whitelist. So it does not "use" a hop on the network route, and you can't see the device, but as it bridges traffic it enforces a (very simple) ruleset.
In my case, I use my own VPN hosts that transact over TCP22 ... and so my network "slug" allows only tcp port 22 traffic. Everything else is blocked.
This means that no matter how badly behaved (or buggy) my VPN software is (I use sshuttle[1]) the bad behavior is blocked by the slug.
The slug itself has almost zero attack surface as it is a BSD based system that has no IP address configured and runs no network services.
I keep meaning to write up a blog entry about this ...
I haven't heard "slug" before, is that your own phrase? It sounds like you've implemented what's known as a stateless transparent firewall if I'm understanding what you've said correctly. Stateless because it's just plain ACLs, transparent because it's not a routed hop/isn't detectable by the client (outside traffic being dropped), and firewall because it's filtering unauthorized traffic. Most people just call it "ACLs" for short though since "stateless transparent firewall" is a bit of a mouthful and "firewall" by itself often implies a routed mode stateful firewall.
Things like this work great for your own network, but you often want a VPN specifically because the network you're connected to isn't yours, especially for iOS (or Android) devices because they're mobile.
I may have a VPN box that only allows traffic to one IP via IP tables/nftables. VPN breaks, no traffic. Simple. It’s useful for more than just piracy though. It’s a nice way to shut down all sorts of ISP crap and guarantee no leakage. Run the household DNS though it as well.
This, but if your op-sec is strict enough, have unique DNS servers per security domain; possibly just a simple local caching server that is forced to work through the intended public face.
I just use iptables, and allow only output via eth0/enp0s1 to the VPN server, so everything else must use tun0. Or I use pfSense VMs as VPN gateways, with outbound NAT and analogous rules.
But TFA is about iOS, where none of that is possible. Or at least, I'm not aware that it is.
Another thing. Although most people do work with and without VPNs on a given device, that's extremely iffy. Ideally, you want a device to have never hit the Internet directly, but only through the VPN or whatever that you're using. And using pfSense VPN-gateway VMs, that's very easy to do.
What would be the WiFi equivalent of this? Think a scenario where a road warrior is in need of connecting his or her devices to a public network. It seems my simple OpenVPN setup on each individual device isn’t enough.
It's really not related to Tor, or how Tor works at all ...
However you could use it with Tor in just the same way - your Tor-networked device should be talking on only specific network ports and any other "chatter" should be considered a leak ... so you would configure the "slug" to only allow the Tor-generated traffic on the expected ports.
I do not use Tor and don't have specific ports/protocols information on it ...
In my opinion, it's best to use Whonix for Tor, because the Tor process and userland are in separate VMs, or separate Qubes AppVMs. There is no forwarding at all between the Whonix workstation VM and the Internet, via the gateway VM. The workstation VM just uses Tor SocksPorts exposed on the gateway VM, through a private network link.
Where leaving no traces on a device is key, Tails is better, because it runs in RAM and wipes everything during shutdown.
Great, this website bans access from datacenter IP address ranges. In other words, I cannot read this blog while connected to my VPN provider...
> Error 1005
> The owner of this website (www.bleepingcomputer.com) has banned the autonomous system number (ASN) your IP address is in (xxxxx) from accessing this website.
This is trivial to verify. I’ll save you two minutes and say that yes indeed it’s accessible through Tor. Tor doesn’t have a static number of exit nodes and due to the variable nature of the network it’s difficult to block.
> due to the variable nature of the network it’s difficult to block.
Due to the fact that the Tor project provides a variety of lookup tools to determine whether an IP is an exit node -- including a DNS-based lookup -- it's trivial to block Tor users.
It's treated like a country, with country code "T1". Site operators can create rules which apply special handling to visitors from the exotic country of Torlandia. ;)
But blocking has become so common that user pressure to prevent it can no longer be ignored. If they don't act, they risk being replaced.
I typically get around it by routing a VPN service, or a private VPN, through Tor. That also enables apps that require UDP. There is the risk of deanonymization, if VPN connections last too long and pin Tor circuits. Or if users don't adequately anonymize payment for VPN services or VPS used for private VPNs.
I started playing with a set of bash scripts that creates multiple VPN connections, with each using a different Tor circuit, and tests them. It periodically switches from one to another, and kills the old one. So both Tor circuit and VPN exit IPv4 change periodically. A script ongoingly starts and tests new VPN connections, to maintain availability. It's basically a crude hack of Tor's approach to circuit management.
I believe that you can make a new APN entry, copying the provided settings, without the second tethering-only APN, if you want, which gets around it too.
AFAICT the reason for this second APN is to allow providers to discriminate between phone-originated data and tethering for charging purposes. And they seem to have persuaded google not to allow people to edit it :/
> While connections made after connecting to a VPN on your iOS device are not affected by this bug, all previously established connections will remain outside the [VPN]...
Is it a bypass or working by design? If you’re relying on the VPN for security then the fact they were established before it means the horse has already bolted.
I don't think it is a case of deliberately "circumventing" the routing table, but rather that the operating system most likely performed source address selection based on the routing table at connection setup. The fact that the routing table has since changed is likely irrelevant after that depending on how the source address is used when calculating the outbound interface. That behaviour is different across different operating systems but this is correct and functioning as expected for Darwin.
No, you can’t move the TCP connection but a decent expectation would be to interrupt all of the existing TCP connections and let the clients retry and resume the session using a session identifier.
Mobile apps should already be used to IP changes interrupting connections due to WiFi->cellular transitions.
I'm not sure I like that. Every site that successfully resumes via a session identifier after the VPN is turned on can now use the session identifier and their logs to match up my real IP address and my VPN IP address.
Obviously, I don't care if those particular sites know my real IP address since I was using them without a VPN before.
But I might not want the sites that I only visit via VPN to know my real address. If I go around giving both to whatever random sites I happened to be using before starting the VPN, there is the risk that one of those sites will give/sell the data to one of the sites that I want to only know my VPN address.
If there are some sites that I do not want to have find my real IP address when I'm on a VPN to them, not letting any sites find out both (except for the VPN provider) is a good idea.
This might be hard to do. Many higher level protocols do not use persistent TCP connections. They connect, process data for a while, and then disconnect when they go idle. Those will end up moving to the VPN (and leaking non-VPN/VPN IP information into the server's logs).
Maybe if it worked at the process level? Processes launched before the VPN starts would not use the VPN unless you explicitly told the system to do so. Still probably has holes.
If you really are trying to seriously use the VPN for privacy, I think you might need a setup where things that use the VPN and things that do not are kept separate, including separate things like cookies and other storage. On a desktop, something like running the things using the VPN in a VM or a container. On phones, though? I don't think you can do that.
> Every site that successfully resumes via a session identifier after the VPN is turned on can now use the session identifier and their logs to match up my real IP address and my VPN IP address.
This would already be the case if the sites had disconnected clean instead of abruptly, since the session can still be resumed in that case.
Really what you want if you're worried about those sorts of correlations is to simply never send any traffic without the VPN. Have no default route via the physical interface at all so that if the VPN is disconnected the internet is unreachable.
This isn't all that surprising because this is exactly how networking is expected to work. If it is desired to kill all active connections, then it should be explicitly done at the time of VPN connection.
I'm not sure if the temporary workaround they propose is a fix or the problem itself. I've noticed when I turn my phone off airplane mode in the mornings, I do not have working VPN connection -- all traffic is blocked. Perhaps this is Wireguard and its particular configuration, or perhaps Wireguard getting a faster start than the operating system reconnecting to my network. In any case, the VPN appears to be blocking traffic. The only workaround I have for that is to disconnect, which takes some time, or switch servers (faster) and reconnect -- and then I guess I'm in the same boat of possible IP leaks.
That's a post from April 2019 showing a very similar issue with IKEv2 VPNs leaking traffic on iOS. I wonder if the two issues are related. Back then, Apple was made aware under responsible disclosure but apparently nothing was done about it.
I've noticed this before with DNS, too. I have internal names that always get resolved externally despite my VPN. Hoping this all gets fixed eventually :(
In case you aren't making a joke, Apple does not have to "EARN" anything as they don't host the VPN service (excluding Apple internal VPNs intended for employees).
This has been standard Mac OS X behavior for a long time: on a machine with multiple IP addresses, connections will use the default gateway associated with the interface providing that address.
As a Linux admin, I am thoroughly confused. Are you saying that MacOS maintains a separate routing table for each interface?
Typically, a system has only one default route. You can have many interfaces and many routes, but only one default. Otherwise you don't know which default gateway to send a packet to.
If you bind to a specific interface it will use that default gateway:
fenrir:~ $ traceroute -ni en0 google.com
traceroute to google.com (216.58.194.142), 64 hops max, 52 byte packets
1 172.16.22.254 0.565 ms 0.340 ms 0.300 ms
2 172.16.25.60 0.893 ms 0.727 ms 0.721 ms
3 172.16.25.0 0.954 ms 0.819 ms 0.815 ms
4 108.218.244.1 7.422 ms 1.908 ms 3.617 ms
5 *^C
fenrir:~ $ traceroute -ni en2 google.com
traceroute to google.com (216.58.194.142), 64 hops max, 52 byte packets
1 192.168.88.1 12.399 ms 3.768 ms 0.811 ms
2 192.168.80.1 1.950 ms 8.322 ms 1.702 ms
3 172.26.96.161 30.448 ms 393.449 ms 46.537 ms
4 107.72.199.60 182.826 ms
107.72.199.36 34.835 ms
107.72.199.60 50.557 ms
5 12.83.186.101 52.178 ms 32.536 ms 33.431 ms
6 12.83.186.85 38.516 ms 51.138 ms 61.687 ms
7 12.122.5.190 48.626 ms 251.733 ms 38.487 ms
8 12.122.2.197 58.184 ms 82.183 ms^C
You can also also do this do this by IP address
fenrir:~ $ traceroute -ns 192.168.88.243 google.com
traceroute to google.com (216.58.194.142) from 192.168.88.243, 64 hops max, 52 byte packets
1 192.168.88.1 4.658 ms 10.498 ms 3.633 ms
2 192.168.80.1 4.264 ms 58.660 ms 7.153 ms
3 172.26.96.161 105.557 ms 41.207 ms 32.243 ms
4 107.72.199.60 66.562 ms
Which interface is used when IP address / interface is not specified is selected by the Service Order setting in the Network control panel.
??? you don’t need to commit software upstream to use it, audit it, or publish obvious vulnerabilities and improvements. Right now consumers have a feudal arrangement with Apple: accept the software at any conditions or not have land on which to work.
The implication is that they would have more if they were not open source, not that open source software is bug free. How could you interpret it like that in good faith? You can’t.
We do, but modern smartphones (if you are not talking about regular phones with no ability to run third-party software) are so complex that it would require a Linux-level _centralized_ effort to pull off. And it's really hard to imagine any centralized effort in this field given the current competition.
So, for the folks that consider this a security issue.
Do you really want the OS to break all your existing connections when you start the VPN?
Do you think this is what most people expect to happen?
I would say that the great majority of VPN users use the VPN to gain access to services behind a firewall, not to disguise their location from the world.
I would guess they'd be pretty annoyed to have a file transfer interrupted that has nothing to do with the resources behind the VPN.
A "slug" is a layer-2 bridge, with no IP address configured, that still enforces a TCP/IP whitelist. So it does not "use" a hop on the network route, and you can't see the device, but as it bridges traffic it enforces a (very simple) ruleset.
In my case, I use my own VPN hosts that transact over TCP22 ... and so my network "slug" allows only tcp port 22 traffic. Everything else is blocked.
This means that no matter how badly behaved (or buggy) my VPN software is (I use sshuttle[1]) the bad behavior is blocked by the slug.
The slug itself has almost zero attack surface as it is a BSD based system that has no IP address configured and runs no network services.
I keep meaning to write up a blog entry about this ...
[1] https://sshuttle.readthedocs.io/en/stable/