4 min read
People use Virtual Private Networks (VPNs) for a number of reasons, mostly for enterprise work where it’s necessary to be connected to a company’s network resources when working remotely. Others use them to ensure their network activity is private, using a secure connection to a VPN service. In the latter case, however, a misconfigured VPN setup can cause certain information to remain unsecured, allowing an observer to learn a user’s public and private IP addresses and witness its DNS requests.
Usually VPN client software will use a configuration file that describes how the VPN is set up and what routing decisions the host should make when using the VPN. This includes gateway information, unique settings, and which applications should route the VPN (or not). If the configuration doesn’t include any DNS server information, the host will likely still use its existing DNS servers - meaning that DNS requests won’t be sent through the VPN and won’t be secured.
Here’s an example. In this first capture we see traffic being sent without a VPN in use. The DNS requests are going to the hosts’ existing DNS server. In this example the DNS server IP is located in the user’s private network (hence its 172. address range), but regardless, DNS requests are probably being sent to the ISP’s DNS servers.
How did we take these captures? The VPN client we're using here is the tunnelblick client on Mac OSX. This creates an additional interface for the operating system, and using tcpdump or dumpcap on that interface gives you the packets before they're encapsulated and sent over the VPN. The captures you see with the VPN encapsulated packets were taking using a network tap between our Mac OSX system and the next interface.
https://www.cloudshark.org/captures/02b67d5282d9
Let’s say the user wants to keep their activity private, so they connect to a VPN service. However, the VPN service configuration didn’t include any instructions on what to do with DNS. You can see in this capture that although most of the traffic is transported over the secure OpenVPN link, the DNS requests are still sent in the clear. This means that anyone able to monitor the traffic (and the DNS owners themselves) can still witness DNS lookup activity.
https://www.cloudshark.org/captures/fe53fe55c8f7
With a properly configured VPN that is set to route DNS to the VPN service, you can see that all of the user’s traffic is secured:
https://www.cloudshark.org/captures/e8b0479edaab
Often talked of in the context of VPN leaks, the WebRTC protocol is used by the largest communications platforms out there, including Google Hangouts, Facebook Messenger, and Discord. It’s on by default in many browsers, but a documented vulnerability can be used to learn a user’s private and public IP address during the STUN (Session Traversal Utilities for NAT) request used to set up a connection through Network Address Translation (NAT).
You can see an example of the STUN request in this capture, which we took before sending data through a VPN:
https://www.cloudshark.org/captures/46763d07311a?filter=stun
That may not sound like a big deal, but with a combination of both your public and private IP addresses, a would be attacker can learn an awful lot about your network, especially if you were hoping to be secured through a VPN.
Here is a link with instructions on how to disable this in various browsers.
With a properly configured VPN and disabled WebRTC, we should have dodged these vulnerabilities for now. Here’s a decrypted capture of our traffic, that shows the DNS requests going to the VPN service’s DNS, and that WebRTC is no longer making STUN requests.
https://www.cloudshark.org/captures/243d2b136fef
Easy to fix, but also easy to miss. Staying secure in networking is difficult - you have to go down to the packet level to know you’re not leaking anything you didn’t intend.
