OpenVPN dnleak Merlin fw 386.3.2 rt ax56u

[pattox]

I've just finished installing and manually configuring this new router and installing Merlin from factory default settings.

I set up a vpn client with an ovpn configuration file, and policy rules to redirect vpn traffic.
The Accept dns configuration is set to "exclusive" which I understand should force all vpn traffic to use only the vpn service dns.

It all works perfectly except for one thing. When I perform an ip leak test I see not only the vpn service ip address and the vpn service dns, but also a huge number of other dns servers not related to the vpn service provider.

I'm not sure why this is happening?

 

[pattox]

I've just finished installing and manually configuring this new router and installing Merlin from factory default settings.

I set up a vpn client with an ovpn configuration file, and policy rules to redirect vpn traffic.
The Accept dns configuration is set to "exclusive" which I understand should force all vpn traffic to use only the vpn service dns.

It all works perfectly except for one thing. When I perform an ip leak test I see not only the vpn service ip address and the vpn service dns, but also a huge number of other dns servers not related to the vpn service provider.

I'm not sure why this is happening?

Have done some further tests with different value of accept dns config

DISABLED
Flooded with dn servers 40+, no vpn service dns server

RELAXED
vpn dns +6 others

STRICT
vpn dns +5 others

EXCLUSIVE
no vpn dns +34 others

Now even more puzzled

 

[chongnt]

After making the changes, have you flush DNS cache from your client before perform ip leak test?

 

[pattox]

After making the changes, have you flush DNS cache from your client before perform ip leak test?

Yes, many times

 

[octopus]

After making the changes, have you flush DNS cache from your client before perform ip leak test?

What setting have you under VPN Director???

 

[pattox]

What setting have you under VPN Director???

Disconnected now, obviously was connected when the problems occurred. Was set up to tunnel one ip address just for testing.

• 
  
• Rules can be individually enabled or disabled by clicking on the first column

OpenVPN clients status
OVPN1: Switzerland	Disconnected	VPN Director	Start Client
OVPN2: Client 2	Disconnected	No Internet traffic	Start Client
OVPN3: Client 3	Disconnected	No Internet traffic	Start Client
OVPN4: Client 4	Disconnected	No Internet traffic	Start Client
OVPN5: Client 5	Disconnected	No Internet traffic	Start Client

Add new rule ( Max Limit : 199 )

Enable	Description	Local IP	Remote IP	Iface	Edit

group vpn

182.168.2.70

0.0.0.0

OVPN1

 

[eibgrad]

As I've mentioned several times in prior threads, you can't trust the results of these online leak testing tools when it comes to the router.

None of your clients are directly configured w/ *public* DNS servers. If you specify "Exclusive" on the OpenVPN client, and specify "Yes (all)" on the routing, then DNSMasq (acting as a local DNS proxy) will be reconfigured to *exclusively* use the DNS server(s) push'd by the OpenVPN server. OTOH, if you specify "VPN Director" on the routing, then one or more redirects are created in the firewall to route all port 53 DNS traffic from those bound to the VPN to one of the DNS servers push'd by the OpenVPN provider. Notice the client itself is never directly configured w/ the OpenVPN DNS server(s). Given that fact, I can't see how online leak testing tools can reliably determine which DNS servers are available to and/or accessed by the client. It's a completely different situation when the client is *directly* configured (i.e., on the client itself) w/ these DNS servers. And presumably the latter is the situation most expected from these online leak testing tools.

You determine the DNS server(s) push'd to the router's OpenVPN client by either (in the case of "Yes (all)" routing) checking the contents of /tmp/resolv.dnsmasq, or (in the case of "VPN Director" routing), checking the DNSVPN1 (or DNSVPN2, DNSVPN3, etc., as the case may be) chain in the NAT table.

iptables -t nat -vnL DNSVPN1

In my own case, that's 10.191.0.1.

 admin@lab-merlin1:/tmp/home/root# iptables -t nat -vnL DNSVPN1
Chain DNSVPN1 (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       all  --  *      *       192.168.1.7          0.0.0.0/0            to:10.191.0.1

With that information in hand, the only way I've found to know w/ 100% accuracy what DNS servers are being used, and via which network interface, is to dump the port 53 traffic in connection tracking.

cat /proc/net/nf_conntrack | grep 'dport=53 '

When the client is actively generating DNS requests, you should see port 53 connections to the DNS server's IP address (in my case, 10.191.0.1). And you can verify it's using the VPN's network interface based on the second pair of src/dst IP addresses; the dst (destination) IP will be the OpenVPN client's assigned IP on the tunnel (iow, the reply is expected back over the tunnel since that's where the request was originally sent).

If you monitor connection tracking over time, that's the only DNS traffic you should see for those devices bound to the VPN. And you can safely ignore anything these online leak testing tools are telling you. Because connection tracking is *definitive* when it comes to this matter, regardless what anything else may be telling you to the contrary.

Is the above a rather tedious process? Yes. But imo it's far better for your peace of mind to investigate and understand the local operations of your router, then depend on the guesswork of some remote online testing tool. As far as I'm concerned, the latter is worthless.

 

[ColinTaylor]

group vpn

182.168.2.70

0.0.0.0

OVPN1

182.168.2.70 is not a valid private IP address. I'm guessing that's a typo and meant to be 192.168.2.70?

 

[pattox]

As I've mentioned several times in prior threads, you can't trust the results of these online leak testing tools when it comes to the router.

None of your clients are directly configured w/ *public* DNS servers. If you specify "Exclusive" on the OpenVPN client, and specify "Yes (all)" on the routing, then DNSMasq (acting as a local DNS proxy) will be reconfigured to *exclusively* use the DNS server(s) push'd by the OpenVPN server. OTOH, if you specify "VPN Director" on the routing, then one or more redirects are created in the firewall to route all port 53 DNS traffic from those bound to the VPN to one of the DNS servers push'd by the OpenVPN provider. Notice the client itself is never directly configured w/ the OpenVPN DNS server(s). Given that fact, I can't see how online leak testing tools can reliably determine which DNS servers are available to and/or accessed by the client. It's a completely different situation when the client is *directly* configured (i.e., on the client itself) w/ these DNS servers. And presumably the latter is the situation most expected from these online leak testing tools.

You determine the DNS server(s) push'd to the router's OpenVPN client by either (in the case of "Yes (all)" routing) checking the contents of /tmp/resolv.dnsmasq, or (in the case of "VPN Director" routing), checking the DNSVPN1 (or DNSVPN2, DNSVPN3, etc., as the case may be) chain in the NAT table.

iptables -t nat -vnL DNSVPN1

In my own case, that's 10.191.0.1.

 admin@lab-merlin1:/tmp/home/root# iptables -t nat -vnL DNSVPN1
Chain DNSVPN1 (2 references)
pkts bytes target     prot opt in     out     source               destination        
    0     0 DNAT       all  --  *      *       192.168.1.7          0.0.0.0/0            to:10.191.0.1

With that information in hand, the only way I've found to know w/ 100% accuracy what DNS servers are being used, and via which network interface, is to dump the port 53 traffic in connection tracking.

cat /proc/net/nf_conntrack | grep 'dport=53 '

When the client is actively generating DNS requests, you should see port 53 connections to the DNS server's IP address (in my case, 10.191.0.1). And you can verify it's using the VPN's network interface based on the second pair of src/dst IP addresses; the dst (destination) IP will be the OpenVPN client's assigned IP on the tunnel (iow, the reply is expected back over the tunnel since that's where the request was originally sent).

If you monitor connection tracking over time, that's the only DNS traffic you should see for those devices bound to the VPN. And you can safely ignore anything these online leak testing tools are telling you. Because connection tracking is *definitive* when it comes to this matter, regardless what anything else may be telling you to the contrary.

Is the above a rather tedious process? Yes. But imo it's far better for your peace of mind to investigate and understand the local operations of your router, then depend on the guesswork of some remote online testing tool. As far as I'm concerned, the latter is worthless.

Thank you. I realise that I have much to learn about all of this.

Looking at this from a different more simplistic perspective, checking using ipleak.net

If I:

1. use openvpn on my ipad, I see only my vpn service ip address and one dns belonging to the vpn service.

2. use a windows pc using my vpn service provider app I also see only my vpn service ip address and one dns belonging to the vpn service.

3. use openvpn on my windows pc I see my vpn service ip address and one dns belonging to the vpn service and 33 other dns. None of the dns belong to my isp so I guess strictly speaking its not a dns leak.

So options 1 or 2 seem "comfortable", "safe" and "predictable" to me compared to using the router. At least I think I feel I know what is happening. Unfortunately not using the router means one can't connect a group of ips to the vpn.

As I said, lot to learn...thanks again

 

[pattox]

182.168.2.70 is not a valid private IP address. I'm guessing that's a typo and meant to be 192.168.2.70?

No, not a typo. I hesitate to admit that I didn't know it was an invalid address. As it happens my original router was 192.168.2.10 but for various reasons I needed to change this to something different. I chose 182 at random and spent quite some time readjusting the network.

What should should I do now? If I don't change what will happen?

Sorry...

 

[RMerlin]

No, not a typo. I hesitate to admit that I didn't know it was an invalid address. As it happens my original router was 192.168.2.10 but for various reasons I needed to change this to something different. I chose 182 at random and spent quite some time readjusting the network.

What should should I do now? If I don't change what will happen?

Sorry...

If you want a different subnet, then change the third number (192.168.XXX.y)

Everything will need to be changed to that new subnet.

 

[pattox]

If you want a different subnet, then change the third number (192.168.XXX.y)

Everything will need to be changed to that new subnet.

Thank you. I've done that now. Second time around I was able to make all the changes quickly.

I inadvertently found that one the consequences of an invalid private ip address was difficulty in casting from Chrome to the chromecast. Initially Chrome would would not see the c/cast because of its invalid private ip address.

In the end I managed to connect by using the Chrome "flags" option to tell Chrome to recognise all ip addresses, not just the valid private ones. At the time I wondered why I had to do that because I'd never had any difficulty previously. Now I know why!