Using NordVPN Proxies With Powershell Invoke-WebRequest

I recently found out my NordVPN subscription provides proxies in addition to the normal VPN functionality.

This can be incredibly useful as it means we don’t need to route all of our traffic through the VPN, rather we can configure an application, browser, or in this case, a PowerShell cmdlet to use one of the proxy servers to masquerade our traffic.

It’s worth noting that while this guide is specific to NordVPN, I would suspect other VPN providers would offer the same functionality. It’s also important to understand that this doesn’t offer the same protection as a full VPN - if privacy is your primary concern, your ISP will be able to see the sites you connect to using this method.

Let’s start with a simple test, we can use a service such as ifconfig.me to echo back our WAN IP, and then we’ll route the request through the proxy to confirm the returned IP has changed.

PS C:\> (Invoke-WebRequest https://ifconfig.me/ip).Content
119.73.91.183

Now, to use the proxy server we need to specify the proxy address and authentication details.

PS C:\> $ProxyCreds = Get-Credential
PS C:\> (Invoke-WebRequest https://ifconfig.me/ip -Proxy "http://au477.nordvpn.com" -ProxyCredential $ProxyCreds).Content
116.90.72.76

There we have it, we’ve successfully proxied our traffic through NordVPN severs and hidden our IP, but lets dig a little deeper into the details.

One thing you may have noticed is that the site we’re hitting is using HTTPS, but the proxy is HTTP. While NordVPN does provide HTTPS proxies, the underlying .NET functionality on which Invoke-WebRequest is built does not. Let’s see what happens when we try to use the HTTPS proxy.

PS C:\> (Invoke-WebRequest https://ifconfig.me/ip -Proxy "https://au477.nordvpn.com" -ProxyCredential $ProxyCreds).Content

Invoke-WebRequest : The ServicePointManager does not support proxies with the https scheme.
At line:1 char:1
+ Invoke-WebRequest https://ifconfig.me/ip -Proxy "https://au477.nordvp ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotImplemented: (:) [Invoke-WebRequest], NotSupportedException
    + FullyQualifiedErrorId : WebCmdletIEDomNotSupportedException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Does this mean that all of the traffic between us and and the proxy server is being sent unencrypted? Not quite - the HTTPS traffic is simply tunneled through the HTTP proxy, let’s confirm this in Wireshark.

We’ve got a filter applied to only show traffic to or from 2 IPs

• 116.90.72.75: The NordVPN Proxy IP
• 216.239.32.21: The ifconfig.me server

There are a few things to note here, the first is the HTTP CONNECT packet, this asks the proxy server to make the connection on our behalf, and then stream all further TCP traffic between us and the ifconfig.me server. You’ll notice we only ever establish a TCP connection (3-way handshake) with the with the proxy server, but are able to communicate with the ifconfig.me server without doing so - this is because the proxy server is making the connection on our behalf.

The second thing we can see is that at no point do we actually directly talk to the ifconfig.me server - there are no packets that reference the 216.239.32.21 IP address.

Lastly, we can see the TLS negotiation taking place within the tunnel, our HTTPS connection to the ifconfig.me server is encrypted and the data being transferred is effectively hidden. The proxy server can see the encrypted data, but without the private keys (which are never sent across the wire) it is not able to decrypt anything.

We do however send our proxy authentication details in plaintext, this is embedded within the HTTP CONNECT packet.

This means you may not wish to use this method on public Wi-Fi networks where traffic can easily be sniffed and your VPN credentials leaked as basic authentication uses easily reversible Base64 encoding on the username and password pair.