Hacker News new | past | comments | ask | show | jobs | submit login

I used the NordVPN CLI client version 3.4.0-1 from a Debian bullseye PC

EDIT: package from https://repo.nordvpn.com/deb/nordvpn/debian/pool/main/




Thanks.

So far, using the stock openvpn package in Debian, it doesn't look like the Disney+ circumvention is happening for NordVPN's US servers.

I'm guessing that the NordVPN client must do it.

And if that's the case, it may merely route traffic directly through the residential proxy, and not first through a NordVPN server. Which wouldn't be good, because someone investigating the residential proxy would see the users IP address, rather than the exit IP address of the VPN server.


Well, I had only little time to dig further but I can confirm your findings that OpenVPN alone behaves as it should while the NordVPN client acts differently. However, wireshark says I am only communicating with the NordVPN server when connected through their client. I would love to know where the difference in configuration is. I always assumed NordVPN would just call OpenVPN with the public ovpn configs. They call the OpenVPN client with a config that is shortly deleted after OpenVPN starts but can be extracted when swapping the openvpn binary. It looks unsuspicious. A management unix socket is opened to control the OpenVPN client. I would like to know how the communication is configured.


I'm also testing now with NordVPN CLI v3.4.0-1 in a Debian 10.1.0 x64 VM with standard Gnome desktop.

I used the default settings. In particular, I didn't enable "obfuscate", which I gather uses two hops.

I'm using a crude infinite while script.[0]

And so far, I haven't come across any servers with unexpected "akamai-x-get-client-ip" for Disney.

But then, there are well over 1000 US server IPs.

So did you enable "obfuscate"? Or "CyberSec"? Or other options?

It would also help if you could share which servers showed unexpected "akamai-x-get-client-ip" for Disney.

0) https://pastebin.com/hz5due96


Damn, I can be such a dumbass.

I was testing "www.disney.com", not "www.disneyplus.com".

Now I always see residential proxies for US servers. Or SSL certificate failures, occasionally.

Edit: That's using either the Windows GUI client, or the Linux terminal client in Debian. Not using "Obfuscate", "CyberSec", or other non-default options. But residential proxies aren't used for "www.disney.com" or "paypal.com".

Also, with the stock openvpn in Debian, I don't see residential proxies being used for "www.disneyplus.com".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: