5 ms·

> 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 t

> 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.

nomel 7y ago
Even if it's not by design, is it even possible to move existing connections to another IP address? Or is the "expected" behavior to sever all connections and let whatever reconnect mechanism work through the VPN?
- blattimwind 7y ago
  > Even if it's not by design, is it even possible to move existing connections to another IP address? 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)
  - nomel 7y ago
    I've been hearing about multipath TCP for the last 15 years and didn't know if maybe it was finally in use.
    - garblegarble 7y ago
      Multipath TCP has been in use on iOS since 2013(!), a lot of the Apple apps use it and since 2017 other apps can as well, which is pretty neat
- kortilla 7y ago
  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.
  - tzs 7y ago
    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.
    - zrm 7y ago
      > 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.
- dahfizz 7y ago
  The expected behavior is that your OS works correctly. 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.
  - neilalexander 7y ago
    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.

nomel 7y ago

Even if it's not by design, is it even possible to move existing connections to another IP address? Or is the "expected" behavior to sever all connections and let whatever reconnect mechanism work through the VPN?

blattimwind 7y ago
> Even if it's not by design, is it even possible to move existing connections to another IP address? 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)
- nomel 7y ago
  I've been hearing about multipath TCP for the last 15 years and didn't know if maybe it was finally in use.
  - garblegarble 7y ago
    Multipath TCP has been in use on iOS since 2013(!), a lot of the Apple apps use it and since 2017 other apps can as well, which is pretty neat
kortilla 7y ago
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.
- tzs 7y ago
  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.
  - zrm 7y ago
    > 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.
dahfizz 7y ago
The expected behavior is that your OS works correctly. 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.
- neilalexander 7y ago
  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.