This is NOT intended to educate myself or others on carrying out illegal activities. I am interested in security topics and as a craftsman I pride myself on continued education. THAT SAID:


It is often said that things such as VPNs, proxy servers etc. mask your identity on the internets. The more I research how the TCP/IP framework actually works though, I question this theory more and more.

Conventional knowledge says that if you punch up a VPN, then you can torrent files or look at embarrassing porn without worry of being identified. I believe this to be true if there is someone sitting between me and my VPN because that's an encrypted tunnel (hopefully). I don't believe this could be said though for systems beyond my VPN tunnel. Based on my limited research, datagrams contain not only the target IP address but also the source IP address. Even though networks such as tor bounce your traffic around the world, in the end, it has to find its way back to you.

I guess in short I am asking, what is stopping the FBI NSA or anyone for that matter from setting up a script that logs headers of datagrams and also the targeted content of these requests? It seems as if there is truly no way to mask one's identity unless you submitted your request from a public location with a spoofed MAC address.

To be clear, I am specifically asking... Is it reasonable to say, any server that I request data from, regardless if I am behind tor, VPN, ect, can in fact, find my source IP contained within the header of the Datagram, and thus, know the true origin of the request. Which can then be logged along with whatever content is requested and then handed over to whomever may request it.



How TCP/IP works

(and just because I know someone will argue it's not conventional knowledge that VPN providers assert they provide anonymity http://btguard.com/ )

  • 1
    The relevant question is: "mask your identity from whom?" Governments can simply ask the VPN provider for their logs, for instance.
    – schroeder
    Commented May 26, 2015 at 23:09
  • @schroeder Okay, well let's assume I use Nord VPN and I route traffic through a server in Singapore or Sweden or Chile. The US government wouldn't get logs from them. Let's focus in on what question I really asked please. It's hypothetical so "whom" isn't relevant. Commented May 26, 2015 at 23:13
  • 1
    ok - so your focus is on networking only, that's helpful to address your question
    – schroeder
    Commented May 26, 2015 at 23:15
  • 2
    You may wish to read about browser fingerprinting and other tricks to trace you spectrum.ieee.org/computing/software/… Commented May 26, 2015 at 23:59
  • 1
    @AnthonyRussell: Actually, Neil's answer of "the VPN provider/server handles that" is also high level info that doesn't really tell you anything. How they handle it is that each packet contains 3 things: source IP, destination IP and ID. The VPN server keeps track of which ID is mapped to which machine (private or secret IP) on the internal network and rewrites the source/destination IP before sending the packet in or out.
    – slebetman
    Commented May 27, 2015 at 2:39

5 Answers 5


Is it reasonable to say, any server that I request data from, regardless if I am behind tor, VPN, ect, can in fact, find my source IP contained within the header of the Datagram, and thus, know the true origin of the request.

No on IPv4. A virtual private network works by connecting, between you and the VPN provider, a tunnel such that you can route through a private network - one of the, or address spaces. This is why it is a "private network". The virtual bit comes from the fact you are actually routing over the public internet.

Your access to the internet is then "proxied" like a home router i.e. network address translation. Since there is no route to a private IP address, unlike a public one, the public facing router must take responsibility for both forwarding packets out to the internet and tracking where the replies should go to.

One way to do this is via source ports, but it is not the only way. In this case the source port of the packet and hence the port on which replies are received tells the router which private network host to send the packet to.

As such, you will "appear" to have the IP of the exit gateway of the VPN to servers that see your requests.

Tor circuits, simplified, are like the gateway process times 3. Each step knows who to send on to and who to return to, but not anything else, with each taking responsibility for routing. So, between you and the internet you have a tor entry server, a relay server and a tor exit node. The relay server for example knows to relay packets from the entry server to the exit node, but no more - it does not know the eventual destination of the packet which only the exit will know, or the source, which only the entry knows.

This is completely opposed to conventional routing, which on the public internet explcitly has a source and destination IP. Routers do not re-write this, instead they simply try to calculate the most efficient "next hop" (directly connected hardware to which they can send the packet). Multiple such steps happen in a typical internet communication (see traceroute) and since tor nodes are internet communications tor nodes packets will also hop over multiple nodes taking varied routes through the internet with known source and destination (which are crucially only the relays).

I've written a lot of text, so perhaps it's worth recapping with steps what happens to a packet in the VPN scenario. Let's say I'm sending a HTTP get request.

  1. I connect to VPN. The process of doing this preserves my route for VPN traffic but otherwise creates a default route via the VPN gateway and makes me part of their private network. Examples from my VPN provider:

    $ ifconfig
    tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet  netmask  destination
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 48  bytes 23132 (22.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 55  bytes 12215 (11.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
    $ ip -4 route via dev tun0 
    default via dev wlp2s0  proto static  metric 1024 dev wlp2s0  proto kernel  scope link  src via dev tun0 dev tun0  proto kernel  scope link  src 
    notareal.ip.200.165 via dev wlp2s0 via dev tun0 

    if you look at this carefully you'll notice some strangeness. The default route remeains in place but has its metric set high (low priority) whereas and - comprising all IPv4 except the notareal.ip line - are sent via tun0. That line exists so that VPN traffic can still go via the proper original interface.

  2. I craft a packet and send it. According to my above mentioned scheme, when I say I want to send this packet to stackexchange.com my routing table instructs me to forward it to the VPN gateway because that's the highest priority matching route.

  3. Internally, the VPN software does its crypto thing and writes a packet to the VPN gateway. This too is looked up in the routing table and goes via the actual network. It is unwrapped at the other end.
  4. At the other end, the packet hits the gateway and is NAT'd, or proxied, or whatever scheme your provider uses. They then leave for the public internet.
  5. When a reply comes in over an established TCP connection, the reverse process happens.
  6. UDP is connectionless anyway; inbound UDP and outside initiated TCP connections are not possible because there's no public routes to me.

In essence, this is quite like your home network NAT, except virtual.

I am using OpenVPN in this case; what you see if you try these steps depends on your provider, VPN software etc and are essentially the same.

Now to answer your question "do VPNs really mask your identity?" - well, there are a lot of ifs and buts and ummms to that, but here's the simplest breakdown I can think of:

  1. If you are an server operator and someone is using a VPN, it's unlikely you'll be able to identify them. You'll see traffic from the VPN provider easily enough, but you won't know who it came from originally unless:
  2. You are a server operator with some kind of authentication mechanism or the ability to store persistent "tracking" cookies on the target. In the former case, you might even know who they are; in the latter case you know they are a unique individual and you won't know exactly who. However:
  3. The VPN provider sees all - the DNS requests you make, where your packets are going etc. In this sense they are now your ISP. Even if you paid them anonymously and gave them details to a completely segregated persona, they still know where your packets come from. The upshot of this is that there is a link to your true identity, or at least whoeever pays the internet bill.

Thus, if you give law enforcement sufficient motive, they'll find you easily enough.

IPv6 is an interesting area. I don't know many people who routinely route ipv6 over VPN mostly because the only person I can name with IPv6 connectivity is me... but, it can be done. IPv6 does not have the concept of private address spaces (slight lie, they do exist) as everything is supposed to be world-routable. Indeed some people believe that NAT breaks the original conceptual design of the internet as a single globally routable network.

Anyway, you can read more about it here - you get IPv6 routable blocks assigned to you instead of private ranges.

If you're wondering, though, publicly routable doesn't necessarily mean packets will be accepted, it just means they could be directed there. There can still be firewalls blocking all incoming connections.

Edit: as an interesting educational exercise, try listening for traffic with wireshark on the VPN interface (in my case tun0) versus the actual hardware interface :)

  • 1
    Bro.... wow... publish this as an article haha. Very nice answer Commented May 27, 2015 at 2:58
  • 1
    @AnthonyRussell Glad it helped :)
    – user70990
    Commented May 27, 2015 at 18:50

VPNs do not mask your identity and even BTGuard doesn't suggest that it does. VPNs encrypt your traffic to them. This hides the content of your traffic along that link only. This is good and it is one brick in the wall.

A proxy is the other important factor. BTGuard, for instance, offers a proxy service for anonymity. A proxy takes your traffic and re-transmits it to the destination. One of the ways it can do this is to resend the traffic with itself as the source and changing the source port. It maintains an internal table of your connection along with the new source port. This way, all traffic on the other side of the proxy can only conclude that it is the proxy who is the originator. The proxy receives traffic from the destination, and retransmits to you on the original source port.

Both technologies are important and can be effective out-of-the-box. What you have not asked (and has been tackled on this site in various ways) is how can this effective 1-2 punch be defeated by tracking mechanisms, misconfiguration, and errors.

  • If I understand this correctly the proxy functions to anonymize the user from the VPN provider? What other benefits are there to use proxy with a non-logging vpn provider?
    – Manumit
    Commented May 27, 2015 at 1:15

You are correct saying you can be identified.

Please have a check at the FREAK vulnerability : http://en.wikipedia.org/wiki/FREAK

I would say it's possible to get caught doing something bad / confidential even with a VPN. A couple other backdoor may still be present, or introduced in encryption technologies.

  • 1
    how does FREAK affect VPNs?
    – schroeder
    Commented May 27, 2015 at 16:44

If the VPN doesn't alter the headers of your browser requests, then it's possible to identify your browser because of its fingerprint (you can test it with Panopticlick) or supercookies. Your personal identity is not revealed, but it's theoretically possible to find which pages you (more precisely your computer) visited by looking at the server logs. It can be a way to differentiate 2 users connecting from the same VPN with the same IP address. It's possible to modify headers sent by the browser in order to mimic more frequent fingerprints.


You are right, with enough resources and tracking capabilities you could track someone using a VPN to the user's location.

This does require government level of resources since you would need to tap all packages and then re-match the packers coming through the VPN. This does not mean they can read the contents yet, but that's to always needed for governments use.

The main reason they probably are not doing this for everyone is the sheer computing power it would require. And using it on a limited set is much more effective. Than again they could be and we simply do not know about it.

  • 1
    it looks like the OP isn't concerned with the content, but the attribution - if so, the computing power reduces significantly
    – schroeder
    Commented May 26, 2015 at 23:22
  • True. But to use this level of packet inspection you need massive bandwidth. More than a casual researcher normally has.
    – LvB
    Commented May 26, 2015 at 23:30
  • If you've got government-level resources, you don't need to do packet tracking. You simply get a court order telling the VPN company to turn over the appropriate subscriber records.
    – Mark
    Commented May 26, 2015 at 23:46
  • That is if you want the Vpn to know. You use tracking when you don't want them to know.
    – LvB
    Commented May 26, 2015 at 23:48
  • 2
    Where are court orders going to lead with non-logging VPN companies?
    – Manumit
    Commented May 27, 2015 at 1:00

Not the answer you're looking for? Browse other questions tagged .