"Well, in any sort of secure Tor implementation, such a thing should be impossible. The Tor client should be running in a router or gateway VM, and the machine

"Well, in any sort of secure Tor implementation, such a thing should be impossible. The Tor client should be running in a router or gateway VM, and the machine used for browsing should not even have a public IP address. That's easy to manage with Whonix." I would go even further and suggest that a mission critical proxy should not live on a system configured with a real (routable) IP address. As we can see in this instance, the OS is too "fussy" and the total implementation is too complex for even an expert in network security to be assured that they will not leak basic network IDs. In my own use of tools like this, not only does the proxying software live on a system whose OS has never seen a real IP but I also throw a "slug" on the network border. "Slug" is the term I use to describe an invisible, layer 2 firewall[1] that blocks ALL network activity except for the addresses/ports of the remote proxy servers. It's sort of like a condom for the network - no matter how weirdly your proxy software breaks, it could only ever talk to the VPN endpoint (and port) anyway ... EDIT: To be clear, an example network design would be: PC --> VPN_box --> slug --> modem ... and in this case, only the modem has a real IP, on the external interface. The VPN_box has non-routable addresses on both sides (and the slug has no IPs). [1] Has no IPs assigned to it - is just an invisible ethernet bridge but is running IP filter rules.