A Solid Week with the ER-4

[MichaelCG]

Your source IP is in the stack of TCP/IP headers. Every time you are routed their info is appended to your packet. So yes the VPN provider is the top source but that is true every time you are routed. So where ever you are routed they are the top source. The VPN has nothing to do with that. It is basic routing. But on every packet is the original source IP.

In an Enterprise site-to-site VPN environment, I mostly agree with you. But in an Internet VPN provider scenario, I will disagree with you. Only the VPN provider will see the original source IP. Said provider will do a NAT translation as the packet leaves their environment to the open Internet. So the remote content server will only see the source IP of the VPN provider.

I do believe the majority of us are all getting at the exact same point. Depending on who or what you are trying to hide or bypass from will determine the overall value to the person.

Lots of reasons to use a VPN service within the US.

1.) Bypassing local ISP filtering/throttling
2.) Bypassing local ISP monitoring/marketing
3.) Hostile local network (think Starbucks open public WiFi, or any other public WiFi)
- this is the work VPN scenario...I trust work way more than those listening in to the open WiFi
- I am the work VPN provider...so I do trust myself more than a random 3rd party
4.) Bypassing region restrictions on content filters

Poor reasons in the US
- thinking you are anonymous
- thinking it provides complete privacy

Some of these reasons are still valid outside of the US....although some of the priority of the reasons may shift as you move to less open countries.

 

[coxhaus]

I still believe even with a NAT translation the original source IP address is there in the packet. You just need to strip it down. How else would the VPN provider know where to return the packet?

 

[System Error Message]

I still believe even with a NAT translation the original source IP address is there in the packet. You just need to strip it down. How else would the VPN provider know where to return the packet?

it isnt, the NAT device keeps a table of connections, basically it keeps a translation. This is why NAT is way more taxing then routing. NAT detection uses another method, like fingerprinting the rest of the packet, works with TCP but not UDP. Then you have the data pf the packet itself, the software you run can expose you (like how some documents from Tor sites expose you). This is why VPN isnt an anonimity tool, it is a routing tool to route your traffic differently. VPN means virtual private network. Its a network thats not physical but private (encrypted tunnels). VPN provides a routing bypass where you cant identify traffic but does not provide anonymity to your destination.

 

[umarmung]

As an external observer, you cannot directly identify endpoint pairs for traffic in an encrypted tunnel, which is what VPN/VPS/SSL/SSH create, since the encrypted payload identifies the endpoint pairs.

External observers can loosely fingerprint types of traffic over ordinary encrypted tunnels, like being able to even "guess" traffic to specific Youtube content given enough traffic and processing, since they are designed to be reasonably efficient, not specifically for obfuscation. But that's about all they can do.

Ultimate destinations can fairly easily fingerprint all but the most sophisticated clients, just like they could over completely unencrypted traffic. From their perspective, little has changed with the client behavior except for a relatively small increase in anonymity for the source. This is partly the problem Tor tries to solve by standardizing clients as much as possible, making it much harder to fingerprint clients just by device attributes.

Tor also treats intermediate servers as untrusted, unwrapping the encryption on the payload until the exit node, hence the reason it was originally called The Onion Router. This is not how ordinary tunnels work with only one high level of encryption and requiring trust with the initial endpoints and every endpoint thereafter.

These encrypted tunnels, even without obfuscation, or Onion routing, have much value depending on your threat. To be honest, even if I were American, I wouldn't leave the house without access to an encrypted tunnel under normal circumstances. For example, with untrusted WiFi connections, not only is every single packet observable, but unencrypted traffic can be used to attack your client devices directly, trivially identify you, and easily fingerprint your behavior ...

 

[sfx2000]

I still believe even with a NAT translation the original source IP address is there in the packet. You just need to strip it down. How else would the VPN provider know where to return the packet?

Yep... lot of folks miss this one with oVPN...

 

[sfx2000]

Ultimate destinations can fairly easily fingerprint all but the most sophisticated clients, just like they could over completely unencrypted traffic. From their perspective, little has changed with the client behavior except for a relatively small increase in anonymity for the source. This is partly the problem Tor tries to solve by standardizing clients as much as possible, making it much harder to fingerprint clients just by device attributes.

Tor also treats intermediate servers as untrusted, unwrapping the encryption on the payload until the exit node, hence the reason it was originally called The Onion Router. This is not how ordinary tunnels work with only one high level of encryption and requiring trust with the initial endpoints and every endpoint thereafter.

These encrypted tunnels, even without obfuscation, or Onion routing, have much value depending on your threat. To be honest, even if I were American, I wouldn't leave the house without access to an encrypted tunnel under normal circumstances. For example, with untrusted WiFi connections, not only is every single packet observable, but unencrypted traffic can be used to attack your client devices directly, trivially identify you, fingerprint your behavior ...

Interesting discussion - now that we've gone way off thread...

@umarmung makes a good point - fingerprints...

The Telco/ISP sees a lot of traffic - and yes, they do deep packet inspection so they know what is 'normal traffic' which is generally noise, and what is VPN and what is TOR...

Source and Sinks... for someone that wants to dig deep, the normal traffic is noise - folks using VPN for business use, that traffic pattern generally matches non-VPN - so someone that is trying to geo-unlock media, its shows... and if one sees a lot of VPN traffic from many sources to few sinks using OVPN, well... duh... it's world cup now, and we see this also with the cricket matches many times over...

TOR is interesting, as it really indicates that someone wants to hide something - "fingerprints" - some folks use TOR to "hide", but this gets into an interesting place - remember the Silk Road mess? With proper technical expertise, it's trivial to determine the topology of a TOR network, poison it, and grab an exit node for analysis and forensics...

Not that Telco's and ISP's do that, but state actors do, and they have the resources to make it work.

 

[umarmung]

That's where you need to be aware of your threat model and the appropriate tool to use. No one technology has perfect privacy. Not even the human mind can survive all attacks for information extraction.

A further point is that the trend of commoditization of hardware that was previously exclusively available on expensive PCs, the rapid growth of cyber threats and Internet of Things, plus growing awareness of the value and trespass on all types of privacy, especially from non-government threats, should result in the rise of encryption, VPN performance and VPNs in general.

If you can cheaply protect yourself in many kinds of situations, why would you not do so? By the time something like the next generation of 5G wireless or 2.5/10 Gigabit wired is routinely available, these trends may have resulted in residential consumer devices that can create up to 1 Gbit/s encrypted tunnels with highly secure protocols, far exceeding most broadband connections, and you're getting it for "free".

 

[coxhaus]

I agree while the packet is in the VPN tunnel the original source IP address is encrypted. But when the VPN service provider routes the packet on the regular network not encrypted then the source IP is available again.

 

[umarmung]

I agree while the packet is in the VPN tunnel the original source IP address is encrypted. But when the VPN service provider routes the packet on the regular network not encrypted then the source IP is available again.

It's available to the VPN provider, not to anyone else. All an external observer can see as endpoint pairs are:

Source IP <-> VPN customer endpoint
OR
VPN exit endpoint <-> Destination IP

Even if the same external observer could find both, the best they can do are fingerprint correlation attacks, assuming they do not have access to the VPN provider's full internal customer network.

Why are we even debating whether VPN technology works? Every business on the planet larger than some threshold uses VPNs and the principles are identical, just they are implemented a little differently for consumers.

 

[MichaelCG]

I agree while the packet is in the VPN tunnel the original source IP address is encrypted. But when the VPN service provider routes the packet on the regular network not encrypted then the source IP is available again.

You are too focused on the VPN encapsulation portion of this and ignoring the fact that any type of service provider can SNAT the traffic to force routing back to their device instead of directly to the originating client.

Think about your ISP router at your house. In the IPv4 world, it does a SNAT as it leaves your house network and transits your ISP network and the greater Internet. The Internet in general does not know your original clientIP (it can, but not from the TCP/IP headers...but possibly from an application layer header) nor does it know how to route directly to your internal client at your house. What does it see? It sees the SNAT IP as the client. The same principle applies to a VPN service provider. The VPN tunnel goes from your client (be it a PC or a router) down the VPN tunnel with original IP intact...tunnel gets terminated and original packet is un-encapsulated. So at this moment in time, yes the VPN provider can see the original client IP address. Now before the VPN provider sends that traffic out to the Internet, it does the same SNAT on the traffic flow as it passes out their Internet connection. Anything outside of the VPN provider now sees the Layer3 SNAT IP of the VPN provider as the originating client.

Now, any higher layer application headers that may contain the original client IP will still have those headers intact so you still have to be concerned about what your apps and/or clients leak out within the higher layer payloads.

Typical Home Setup
ClientIP --> Google DNS [192.168.5.25 --> 8.8.8.8]
Client Router --> Google DNS [207.xxx.xxx.54 --> 8.8.8.8]
**Client Router does a SNAT of the ClientIP behind the public IP of the router

Home Setup with OpenVPN at the Router
ClientIP --> Google DNS [192.168.5.25 --> 8.8.8.8]
**client PC initiates a connection outbound to Google Public DNS
**when packet leaves Client, source IP is client's real IP and destination is that of Google

Client Router --> OpenVPN Provider [207.xxx.xxx.54 --> 109.xxx.xxx.98]
-- encapsulated (207.xxx.xxx.54 --> 8.8.8.8)
**client router does a SNAT of clientIP to RouterIP (207.xxx.xxx.54)
**client router encapsulates packet into VPN and sends to VPN provider
**Layer3 information now has source of Client Router (207.xxx.xxx.54) and destination of VPN provider (109.xxx.xxx.98)
**encapsulated payload IP info is still the Client Router SNAT IP (207.xxx.xxx.54) and Google (8.8.8.8)

OpenVPN Provider --> Google DNS [109.xxx.xxx.98 --> 8.8.8.8]
**encrypted packet arrives at VPN provider and is un-encapsulated
**Layer3 IP is still a source of Client Router (207.xxx.xxx.54) with a destination of Google (8.8.8.8)
**VPN provider then does a SNAT of the traffic to send to Internet
**Layer3 IP is now a source of VPN Provider (109.xxx.xxx.98) with a destination of Google (8.8.8.8)
**Google does not know the ClientIP nor the Client Router IP, it only knows that the VPN Provider IP sent it a request

 

[coxhaus]

I agree while the packet is in the VPN tunnel the original source IP address is encrypted. But when the VPN service provider routes the packet on the regular network not encrypted then the source IP is available again.

I want to strike this from the record. I drank too much last night. And it is nonsense on what I stated. Not to be hard on myself.

I still believe even with a VPN provider's header and trailer on the packet the original source IP is there. It is deeper down.

 

[System Error Message]

I want to strike this from the record. I drank too much last night.

I still believe even with a VPN provider's header and trailer on the packet the original source IP is there. It is deeper down.

Its not in the header though, its in the packet because of the software used over VPN. However i've been on some VPNs, mikrotik makes it very easy for networking so i've seen many of them even with the privacy org recommendation leaks info to other VPN users, so all one had to do to get your info is to connect to the same VPN as you and they'll see all the users on. Many VPN providers dont properly configure their VPNs.

You can only get the destination IP from a VPN packet after you strip it. To understand this, say i wanted to visit google via VPN, the browser would send a request to google.com (packet created with destination IP, source IP optional as its up to the NIC to add that and it may add the VPN gateway as source instead), that packet gets encapsulated and sent to the VPN, so on layer 3 you'll see the source IP being you and destination IP being VPN. However you cant pry out that google.com destination IP from the encapsulated packet without first cracking its encryption or being on the network if the network is illconfigured. If one was monitoring the VPN node than for sure you'd get the destination there and linking it to the source isnt easy, the VPN server keeps a table so that it knows that particular packet/connection belongs to a particular host because google would send back in reply via layer 3 the VPN provider as destination with no encapsulation.

So to actually figure out which destination to which source ip with a VPN is very difficult, you'd need analytics and access to both the source and destination (like being the ISP of both) which is what broke TOR's privacy. The destination however sees the VPN provider as the source and your computer as the computer that requested it (NAT madness) but the source can trick your PC into replying to it directly without using the VPN gateway. To the destination, your IP doesnt matter because it can see what you do at the destination, and in information gathering, IP addresses arent what they want to know, what they want to know are whos the owner of the IP (or basically the computer/guy behind that IP) and what they do. So a VPN does bypass ISP level filtering and monitoring, but if an agency was monitoring globally (like country govs working together and sharing data), then if your VPN exit node is in any of those countries if it originated in it, then that VPN is useless for you.

a lot of VPNs are in china not because of demand but because of law and non cooperation of intelligence resources, but the chinese are far more interested in you than the US is, and are pressured to submit data on you to the CCP, so you do not want to use a VPN from china either as you dont want the CCP having any leverage over you or knowing what you do and using it against you which is far worse than what the US would do to you.

@coxhaus you gotta learn to math/logic drunk.

 

[bodean]

Does this model suffer from the same issues my edgerouter X suffers with Comcast gigabit service (IPv6 is broke Ben hwnat is on).
About ready to sell this erx