What's new

What happens if you have openvpn configured on router AND have vpn app running on computer?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I'm still getting DNS leaks connecting to the majority of servers I've tried with this configuration - which is the same result I was getting with a prior configuration on 386.3 that had "Accept DNS configuration" to "strict", and no route entries in the custom config field.

As I understand it, when running a leak test the ISP should match the one displayed at the top of nord's homepage, and the IP address displayed in the leak test should closely match the IP displayed on nord's homepage (typically the last digit will be different when the ISPs are the same).

Therefore, I am describing a leak as when nord's homepage shows a protected status, and a leak test shows a different ISP and IP address.

I'm baffled at how, with identical configuration settings such as those eibgrad recommended for 386.4, some servers can be connected to without DNS leaks, while most others cannot.

You're still getting DNS leaks, as measured by what?

The point of that particular configuration if to bind your DNS to CloudFlare (1.1.1.1 and 1.0.0.1). If the OpenVPN client is NOT active, your DNS access is over the WAN. If the OpenVPN client is active, and you have the routing set to "Yes (all)", then your DNS will be directed over the VPN. So no matter the circumstances, your DNS access is always through CloudFlare, and all that differs is whether its over the WAN or VPN.

How does any of the above have anything to do w/ the NordVPN DNS servers? What difference does it make what the NordVPN webpage says? As I say all the time, *other* DNS leak testing tools routinely provide incorrect information. You can't rely on them. That's why you only need to concern yourself w/ what YOU can control, which means determining w/ local DNS monitoring, what DNS is being used, and where it's being directed. Once it leaves the router, all bets are off as to what happens to that DNS traffic since at that point you do NOT control it.
 
I don't trust that server
Gotta pick the right provider based in a country that doesn't support surveillance by your home country. I have some servers that when downloading things display several endpoints being used as a source. If it's truly masquerading is a different story. The idea is to have multiple sources using the same endpoint to make it hard to track which packets are sourced from what machine / IP. If you setup your own VPN on a single IP in a hosted rack that's static.... well... it defeats the purpose but, does keep your traffic secure.

The problem of keeping traffic 100% anonymous is the TCP sessions need to use the same path they originate from. UDP doesn't and when you use services using Wire Guard or whatever they rebrand it as you have a slight edge over sticking with OVPN connections. Also, with WG you can hit wire speed where OVPN typically maxes out at 500mbps due to the overhead and clunkiness of the protocol.

Ideally someone will come up with something that masquerades on a per stream basis and then funnels it back to you w/o any issues. Putting a load balancer on the server side and provisioning several IP's to it would do the job but, I don't think providers really want the added cost / complexity of doing so.
 
You're still getting DNS leaks, as measured by what?
The point of that particular configuration if to bind your DNS to CloudFlare (1.1.1.1 and 1.0.0.1). If the OpenVPN client is NOT active, your DNS access is over the WAN. If the OpenVPN client is active, and you have the routing set to "Yes (all)", then your DNS will be directed over the VPN. So no matter the circumstances, your DNS access is always through CloudFlare, and all that differs is whether its over the WAN or VPN.

How does any of the above have anything to do w/ the NordVPN DNS servers? What difference does it make what the NordVPN webpage says? As I say all the time, *other* DNS leak testing tools routinely provide incorrect information. You can't rely on them. That's why you only need to concern yourself w/ what YOU can control, which means determining w/ local DNS monitoring, what DNS is being used, and where it's being directed. Once it leaves the router, all bets are off as to what happens to that DNS traffic since at that point you do NOT control it.
A VPN CS agent had previously indicated that the VPN & DNS IP address should be almost matching (perhaps the last 1 or 2 digits off being ok) if no DNS leaks are present. I decided to double-check that today and I was informed that non-matching VPN and DNS IP addresses and ISP names on DNSleaktest results doesn't necessarily indicate a DNS leak. Further, I was informed that submitting the DNS server IP address to VPN CS, they can confirm if they own the DNS server in question or not.

Do you happen to know if the configuration you recommended in post #20 to help prevent DNS leaks on 386.4 is still advised on the newest release of Merlin?
 
Do you happen to know if the configuration you recommended in post #20 to help prevent DNS leaks on 386.4 is still advised on the newest release of Merlin?

I don't know of anything that has changed since 386.4 (when I made that recommendation) that would warrant a change to that recommendation.
 
My issue? I don't trust that server isn't bought/paid for by whoever is wanting to track me or anyone else. No point using it at all if that question isn't answered satisfactorily to me (and the only correct answer is I own and manage it, myself).

Bingo...

I totally agree that if one doesn't own/control both end-points of a VPN tunnel, assume there is zero privacy...

If a provider does business in the United States - CALEA is something they have to support. If they ignore a court order, people get cited with contempt and go to jail until the warrant is satisfied.

They may claim that they don't save logs, etc... that's not true - they do absolutely collect logs, as they need this for their own internal purposes to ensure that resources are properly sized, resolve issues, and ensure platform security.

Don't forget that the first-hop provider also collects logs, so if there's a shedload of traffic going to a known VPN provider, well...

If I were a three-letter agency, I would set something like a VPN provider up as a front...

Not sure if everyone caught this across their newsfeeds...


just saying...

Much like Bitcoin doesn't provide privacy either...
 
What happens if you have openvpn configured on router AND have vpn app running on computer? Let's say you have NordVPN setup on AX88U through openvpn as client running Merlin 386.4 AND have Nordlynx running on a network computer.

Couple of things I should add with VPN "inception"

<insert BWONG sound>

when nesting VPN packets, you can run into addtional latency, esp if running TCP vs. UDP for openVPN, as TCP requires acks, UDP doesn't. Also one can run into packet fragmentation with VPN frames inside of VPN frames - sooner or later runs exceeds the MaxMTU size, so the packets will get broken up.
 
Sort of a side note - you are wasting a lot of bandwidth by adding double IPSEC overhead. You are also likely causing a lot of fragmented packets which can increase latency and decrease throughput as well. It is a very inefficient setup.

Also in the past there were protocols that didn't like being encrypted. IPSEC within IPSEC is fine, as is TLS within IPSEC (technically you do that every time you visit an HTTPS site within a VPN tunnel). Some of the older VPN protocols didn't like it though.

As far as things that could leak, seems DNS is probably one of the least worrisome.....
 
Couple of things I should add with VPN "inception"

<insert BWONG sound>

when nesting VPN packets, you can run into addtional latency, esp if running TCP vs. UDP for openVPN, as TCP requires acks, UDP doesn't. Also one can run into packet fragmentation with VPN frames inside of VPN frames - sooner or later runs exceeds the MaxMTU size, so the packets will get broken up.

Sorry didn't see your post before making the same points. With a single VPN tunnel, hopefully PMTUD (Path MTU Discovery) will tell your client to limit their packet size to 1460 or less (however not all hardware or providers support PMTUD). However tunnel within a tunnel is almost certain to fragment nearly every packet on a file download and that is really going to cause some noticeable impact.

On private networks like the one I work on, we are able to use oversized packets, 1640 bytes, so a full size encrypted packet will get through without fragmentation. But that is not going to be the case on the internet.
 
Bingo...

I totally agree that if one doesn't own/control both end-points of a VPN tunnel, assume there is zero privacy...

If a provider does business in the United States - CALEA is something they have to support. If they ignore a court order, people get cited with contempt and go to jail until the warrant is satisfied.

They may claim that they don't save logs, etc... that's not true - they do absolutely collect logs, as they need this for their own internal purposes to ensure that resources are properly sized, resolve issues, and ensure platform security.

Don't forget that the first-hop provider also collects logs, so if there's a shedload of traffic going to a known VPN provider, well...

If I were a three-letter agency, I would set something like a VPN provider up as a front...

Not sure if everyone caught this across their newsfeeds...


just saying...

Much like Bitcoin doesn't provide privacy either...

Plus, beyond the VPN provider, the website you're going to is tracking and logging you and seeing all your activity. Sure, your IP is masked, but there's lots of yummy cookies to track anything and everything. VPN is mostly for getting around some countries blocking of sites, or for avoiding DMCA notices when torrenting. As far as security, there are numerous reasons it isn't providing what they claim it is. They're mostly profiting off fear mongering.
 
1653724656541.png
1653735618776.png


DHCP advert

1653724735970.png


VPN director

1653726055402.png



This will solve your DNS leak (check with ipleak.net), unless your browser is overriding your system DNS settings. Check your browser settings! If you allow your browser to override or use its own proxy, then you may wish to create a rule for it. In the example above, I force my Cloudflare choice through the VPN tunnel. If you're not a fan of Cloudflare, choose your own poison, but using your own ISP's DNS is better for them than it is for you.

I set the VPN DNS to relaxed. Prefer not to specify Nord's DNS. They're slower and sometimes they have load balancing and availability issues. Play around with this setting between disabled to strict to suit yourself.

If you use internal DNS servers, point your DNS server(s) forwarder to your router's internal GW address and specify your internal DNS server(s) IP instead of blank in your DHCP assignment.
 
Last edited:

Similar threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top