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) 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 ...
Yes, although I've been using it for several years when discussing a safety device like this ...
I first discussed a transparent, stateless firewall in 2001 when I wrote a HOWTO for the FreeBSD project:
... although that is hopelessly out of date. Like I said, I keep meaning to do a blog post on this ...
Popular with pirates because having torrent activity leaked to your ISP is not great.
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.
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 ...
Where leaving no traces on a device is key, Tails is better, because it runs in RAM and wipes everything during shutdown.
> 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.
Update: By vps i mean ip from digitalocean,linode, vultr etc.
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.
> Tor doesn’t have a static number of exit nodes and due to the variable nature of the network it’s difficult to block.
And yes, there could be blocking by ranges.
And while I doubt that Tor would ever do it, one could use residential IPs via "free" smartphone apps. Some VPN services may be doing that.
No one could not use residential IPs that way.
But I don't see anything in https://trac.torproject.org/projects/tor/ticket/26646 about listing the IPv6 addresses. And using random addresses from multiple /48, that'd be an extremely long list.
I was wrong about not reusing IPv6. But even so, using the same IPv6 would be very rare, given the number available.
You say that no one could use residential IPs that way. But I know for a fact that it's already being done. For example, see https://luminati.io/proxy-networks/residential-ips.
Handful of blocked ranges yes...
It's obvious that this isn't a goal of Tor.
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 see 377 starting with 2001:.
Start wifi tethering. Connect your VPN, assume traffic is going over it.... nope.
There is a shadow APN configured for your network provider that you can't edit, and all tethered traffic goes over that, not the VPN'd connection.
The VPN only protects traffic originating from the phone.
But variety of applications can install their cert (with ofc user permission via dialog) and snoop traffic. At least unencrypted.
The way they do it is installing vpn and reading stuff in-between
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 :/
Turns out that the phone VPN client only covers phone traffic.
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.
Or is the "expected" behavior to sever all connections and let whatever reconnect mechanism work through the VPN?
If a VPN adds a 0.0.0.0/0 route, that route should be respected. Your OS should not circumvent your routing table for some packets and not others.
Mobile apps should already be used to IP changes interrupting connections due to WiFi->cellular transitions.
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.
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.
Computer Networks 101 Exam
Question 31.) What identifies a TCP connection?
[ ] Peer IP address
[ ] Peer IP and Port
[x] The four-tuple (peer IP, peer port, local IP, local port)
and Pine phone https://www.pine64.org/pinephone/
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.
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.
fenrir:~ $ uname -a
Darwin fenrir 18.7.0 Darwin Kernel Version 18.7.0: Tue Aug 20 16:57:14 PDT 2019; root:xnu-4903.271.2~2/RELEASE_X86_64 x86_64
fenrir:~ $ netstat -rn |head
Destination Gateway Flags Refs Use Netif Expire
default 172.16.22.254 UGSc 85 732 en0
default 192.168.88.1 UGScI 2 49 en2
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 1 3806 lo0
169.254 link#6 UCS 2 0 en0 !
169.254 link#8 UCSI 0 0 en2 !
fenrir:~ $ traceroute -ni en0 google.com
traceroute to google.com (126.96.36.199), 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 188.8.131.52 7.422 ms 1.908 ms 3.617 ms
fenrir:~ $ traceroute -ni en2 google.com
traceroute to google.com (184.108.40.206), 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 220.127.116.11 182.826 ms
18.104.22.168 34.835 ms
22.214.171.124 50.557 ms
5 126.96.36.199 52.178 ms 32.536 ms 33.431 ms
6 188.8.131.52 38.516 ms 51.138 ms 61.687 ms
7 184.108.40.206 48.626 ms 251.733 ms 38.487 ms
8 220.127.116.11 58.184 ms 82.183 ms^C
fenrir:~ $ traceroute -ns 192.168.88.243 google.com
traceroute to google.com (18.104.22.168) 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 22.214.171.124 66.562 ms
Easy to setup with netplan and systemd-networkd, a little more complex to do manually.
Giant letters: "It's designed to be secure. And to protect your privacy."
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.
Seems bizarre to call this a "bug"
Yes, just like when I connect to WiFi while having LTE enabled and active.