What I understand is that when you connect to a VPN, all your Internet traffic goes through something like a tunnel, and your VPN provider can see everything you do, but your ISP only sees that you are connected to a VPN. What happens at the VPN provider's side? Do they not need to connect to an ISP themselves, or are they connected to the Internet backbone or something like that?

2 Answers 2


Your VPN provider can, technically, "see" your traffic, and so can their ISP after it has been "laundered" through the VPN itself.

In this example, I am going to talk about OpenVPN because I am most familiar with it, and most VPNs use it. I am also going to assume we're talking about non-https traffic (like regular HTTP or SMTP mail). When your VPN traffic leaves your computer via the VPN adapter, it is encrypted - i.e., your data is turned into pseudorandom noise, and then a wrapper is placed on it so your ISP can properly route the traffic. The packets have to be routable to the VPN, which means your ISP has to have some information

So, your ISP sees that you have data (that looks like unintelligble garbage). Your ISP sees that you are sending traffic, but has no idea what it is or where its ultimate destination is. It just knows "I have to send this to x.y.z.a" which is the VPN provider.

Once the packet arrives at the VPN provider, they can decrypt the packet with their private key. At this point, they could cache it, log it, keep it, examine it, etc... But, a reputable VPN would be doing themselves a disservice to do this since it violates the customer trust and such a revelation would put them out of business. Additionally, most of them want the ability to tell a government authority "we can't help you because we don't have logs."

Now, once they decrypt the traffic you sent them, they then forward the traffic on to wherever it is destined to go. At THIS POINT, the traffic is visible to by standers.

But, because you are "emerging" onto the internet from the VPN provider's IP address instead of your own, we have effectively "laundered" your traffic by concealing its source IP address through the VPN provider. Third parties, including the remote webserver, do not know the original source of the traffic. When they reply, they send it back to the VPN, the VPN then re-encrypts it and relays it back to you. So, you now the remote party, but the remote party doesn't know you.

So, assuming that the VPN server at the provider has a big, fat fiber connection, the ISP cannot read inbound packets from you, but can fully read outbound packets that are destined for the remote server. (Later, on the return trip, it can read "inbound" packets from the webserver to the VPN provider, but cannot read "outbound" packets from the VPN provider to you).

So, it looks like this:

You < ---- Encrypted --- > VPN Provider < --- in the clear --- > webserver

Now, if you are visiting an HTTPS site (SSL / TLS) it looks like this:

you < === double encrypted === > VPN provider < --- single encrypted --- >

Because the HTTPS session encrypts your data end-to-end. So, wrapping it in the VPN encrypts the encrypted data while it is en-route from you to the VPN provider. When the VPN provider unwraps it to re-forward it, the payloads it sees are encrypted blobs of data that are useless to them. Only the remote computer can decrypt that data.

So, with https (SSL / TLS) your ISP can't see the data irrespective of the VPN's presence; however, the VPN double encrypting the data conceals where it's going to them and conceals who you are to the remote server. So, there is still added protection here.

A note on DNS

Your VPN connection also should be configured to provide you additional protection for your DNS. The VPN should encrypt the DNS requests to the VPN provider and allow your DNS lookup to take place either at the VPN provider or from the vpn provider giving you plausible deniability that you ever even looked up the site you visited.

  • 1
    So, assuming that the VPN server at the provider has a big, fat fiber connection, the ISP cannot read inbound packets, but can fully read outbound packets. Wrong. The VPN's ISP cannot read outbound packets being sent to the user and can read inbound packets from the Internet servers users are requesting pages from.
    – WBT
    Commented Aug 12, 2017 at 3:48
  • I see what you did there. :-) Your comment was valid in that the sentence you reference had no point of reference. I was relying on the diagram below it, but have clarified the sentence in light of your comment above. The point of reference is important.
    – DrDamnit
    Commented Aug 12, 2017 at 14:04
  • Much better.
    – WBT
    Commented Aug 12, 2017 at 15:15
  • Thanks for your answer! Very well explained! I just need some clarification here, in the first example, the VPN's ISP would not be able to tell where I am sending and receiving data from, but it would be able to get my personal information since there is no encryption on the traffic that goes from the VPN to the web server, right?
    – user156521
    Commented Aug 25, 2017 at 3:19
  • Not how I would phrase it. The VPN's ISP can see the content of your requests and the web server responses. That may or may not have personal information in it.
    – DrDamnit
    Commented Aug 25, 2017 at 8:36

You are right, your VPN provider does need to connect to an ISP. But no, they aren't connected to the internet backbone.

That said, by using the VPN you are using their IP address to cloak your traffic.

So, your VPN provider's ISP can see all packets transmitted across their service - but they cannot see the source IP of the packets.

If you are interested, one way to visualise this would be to run a traceroute from your local machine against a target IP, with and without your VPN connection enabled.

On windows systems it is tracert <targetip>

And on 'nix based systems it is traceroute <targetip>

Hope this helps!

You must log in to answer this question.