ver. 380.58 Policy rules, The DNS for Local ISP Leaks VPN IP. This is a serious problem. Caution

[yorgi]

Ok so I updated to 380.58

VPN CPU order has been changed 2 4 on core 1 and 1 3 5 on core 2
VPN DNS works properly when in exclusive and policy rules
no more need for DNSfiltering
also no need to have Verb 3 in custom configuration as it now has Global Log verbosity feature in the advanced VPN client

Also new feature Auth digest
For PIA use SHA1

thumbs up for the changes

When in Local ISP with Policy rules and exclusive and the VPN client is running in the Background it shows the DNS of VPN
I still need to enable DNSfiltering to fix that only for Local ISP
When I disable the VPN client the DNS resolves to Local ISP. this was the same in previous firmware version.

Am I missing something?
I was under the impression that with the new firmware the DNS for Local ISP should show instead of the VPN DNS.

Also in WAN DNS Setting: Connect to DNS Server automatically;
if I put OpenDNS address in there, it wont make a difference if the VPN server is working in the background.
Shouldn't that work for local ISP? this only works when VPN clients are turned off.

 

[yorgi]

I don't suggest anyone use firmware 380.58 with Policy rules local ISP unless they are using DNSfiltering for the DNS.
I also don't suggest anyone making selective rules where specific IP address's go to WAN when on a VPN
Because when you are on Local ISP with Policy Rules in "Exclusive" "Accept DNS Configuration" the DNS shows as your VPN IP address.
That is a major problem that needs attention.
Here is an example I am on VPN but made a selective route rule that says
all traffic to VPN but ipleak.net goes to WAN "local ISP"
When I do a test it gives me the Local ISP address which is correct but with the DNS being my VPN IP address.The proper way should be the DNS should point that of my Local ISP and not
the VPN IP address.
Use with caution because if you leak your VPN IP address what is the use of having a VPN

 

[yorgi]

I don't suggest anyone use firmware 380.58 with Policy rules local ISP unless they are using DNSfiltering for the DNS.
I also don't suggest anyone making selective rules where specific IP address's go to WAN when on a VPN
Because when you are on Local ISP with Policy Rules in "Exclusive" "Accept DNS Configuration" the DNS shows as your VPN IP address.
That is a major problem that needs attention.
Here is an example I am on VPN but made a selective route rule that says
all traffic to VPN but ipleak.net goes to WAN "local ISP"
When I do a test it gives me the Local ISP address which is correct but with the DNS being my VPN IP address.The proper way should be the DNS should point that of my Local ISP and not
the VPN IP address.
Use with caution because if you leak your VPN IP address what is the use of having a VPN

View attachment 5872

In Policy Rules if you choose to have selected IP address's going through the VPN and all other Traffic goes to Local ISP,
when in Local ISP the DNS is the same as the VPN DNS this time you don't get the VPN's IP as your DNS. This is still leaking DNS therefore not a good thing.

Changelog 380.58

"- CHANGED: if you set an OpenVPN client DNS mode to "Exclusive"
and you enable policy-based routing, then those policies
will also determine which DNS to use (the tunnel's or
the ISP's). This is based on DNSFilter's technology.
You no longer need to use DNSFilter to control the DNS used by your OpenVPN clients."

Still not resolving properly. I tested it on 2 different 87U and a AC66U same problem.
Is this a bug?

 

[RMerlin]

all traffic to VPN but ipleak.net goes to WAN "local ISP"
When I do a test it gives me the Local ISP address which is correct but with the DNS being my VPN IP address.

This is perfectly normal. The DNS query is done before you try to access that website, under the global "all traffic to VPN" rule, therefore the DNS used is the VPN's.

The proper way should be the DNS should point that of my Local ISP and not
the VPN IP address.

That is not possible. Routing is done at connection time, not at name resolution time. The router cannot "guess" that you are going to try to resolve an IP that will be ultimately routed through the VPN - name resolution and packet routing are two totally separate concept.

 

[yorgi]

This is perfectly normal. The DNS query is done before you try to access that website, under the global "all traffic to VPN" rule, therefore the DNS used is the VPN's.FW

I didn't mean it that way. You misunderstood the "All traffic" as in Redirect Internet traffic option.
I am referring to "POLICY RULES"

192.168.1.80/28 0.0.0.0 VPN
0.0.0.0 54.164.36.190 WAN ------- 54.164.36.190 is www.ipleak.net

My PC is on VPN IP 192.168.1.91 where all my traffic goes through the Tunnel and the policy rule 54.164.36.190 ipleak.net goes to WAN local ISP

This way I can do a test and see what my DNS is resolving to because traceroute didn't do the job as you suggested.

I did a DNS leak Test and I got the Local ISP address which is right and a VPN IP address for the DNS which is not right.

Basically It's leaking the VPN IP address as the DNS for the local ISP

example: these are fictitious IP's
66.123.123.54 IP From ISP
172.123.15.5 DNS From PIA

"172.123.15.5" is the VPN address not the DNS which is 209.222.18.222 from PIA

Basically if I go with a selective route where I am on the VPN and I send email through SMTP via WAN rule I will be showing my IP of Local ISP and my IP of the VPN as the DNS to the SMTP server.
That's leaking DNS

I can understand if I am on a VPN where the DNS should be the same as the VPN IP address which was fixed in the New FW
but showing the VPN IP for VPN DNS on Local ISP is a leak.
Anytime a packet is sent through Local ISP via a policy rule the DNS should be that of the Local ISP and not an IP from a VPN or DNS of a VPN

I am not challenging you I am just bringing up a very scary point from this

 

[sfx2000]

The risk one runs with VPN's is that either one runs all traffic thru the VPN, or they don't...

The use case you quoted above - unexpected vector - WebRTC...

There is no privacy at the lower layers with VPN's...

 

[yorgi]

The risk one runs with VPN's is that either one runs all traffic thru the VPN, or they don't...

The use case you quoted above - unexpected vector - WebRTC...

There is no privacy at the lower layers with VPN's...

I agree but why make firmware's that support selective routing and they don't work right?
Whoever uses them should know that they are taking a risk and from what I understand, this forum
is to help others but also bring forward issues so they can be fixed.

 

[yorgi]

This is perfectly normal. The DNS query is done before you try to access that website, under the global "all traffic to VPN" rule, therefore the DNS used is the VPN's.



That is not possible. Routing is done at connection time, not at name resolution time. The router cannot "guess" that you are going to try to resolve an IP that will be ultimately routed through the VPN - name resolution and packet routing are two totally separate concept.

This is from your documentation.
"- CHANGED: if you set an OpenVPN client DNS mode to "Exclusive"
and you enable policy-based routing, then those policies
will also determine which DNS to use (the tunnel's or
the ISP's)"

When I read that it says the the
DNS will be determined by the Tunnel's ;
which is VPN PIA DNS 209.222.18.222
OR
the ISP's
My ISP DNS 24.201.245.77

This is not what I am getting.

Policy Rules

192.168.1.80/28 0.0.0.0 VPN
0.0.0.0 54.164.36.190 WAN

54.164.36.190 is ipleak.dns

when I do a test in iplkeak.dns I am suppose to get My ISP IP address and 24.201.245.77 DNS of my ISP
instead I get My ISP IP address and VPN IP address for DNS

if your changelog is right then the results I am getting are not the same.

At least if I leave it in Strict instead of Exclusive the VPN's DNS shows when in Local ISP
that's better then an actual IP address showing in DNS.
I will leave it in Strict until this is resolved

 

[RMerlin]

Network-wise, this is what you are doing in your test:

1) Start the browser
2) Type www.ipleaks.net in your browser
3) The browser connects to the router's IP, asking it to resolve www.ipleaks.net
6) The kernel's routing database is queried. There is a request to connect FROM 192.168.1.91 TO 192.168.1.1. This matches the first policy rule, so the connection is forwarded to the VPN's DNS server.
7) The DNS server responds to the request, with "54.164.36.190"
8) The router gives that answer to the browser
9) The browser tries to do a TCP connection to 54.164.36.190
10) This matches your second policy rule, so that request gets routed through the VPN tunnel

The part that is confusing you is the fact that when connecting to a website, you are NOT connecting to a DNS server. These are two separate connections, so they hit both rules separately.

From 192.168.1.91 to 192.168.1.1: matches the VPN rule
From 192.168.1.91 to 54.164.36.190: matches the second, WAN rule

The web connection matches your VPN rule, and the DNS connection matches your WAN rule.

In summary: the router's routing database can only redirect a DNS query if the SOURCE IP matches. It's impossible to match based on the DESTINATION IP, as the connection to the DNS is to a totally different IP.

What you are trying to do with that specific setup you did is impossible. You can only force a device to a specific DNS based on the source IP - you cannot do it based on the destination IP.

 

[RMerlin]

BTW, the "strict" option is broken inside dnsmasq, according to the dnsmasq author. All it does is tell dnsmasq to query the nameserver in the same order they are specified. But since dnsmasq will stick to the first dns server that properly responds to requests, it means that the other servers will simply never get used.

There's a chance I might remove the strict option since it's not doing what people think it should do, and the dnsmasq author himself recommends not using it.

 

[yorgi]

Network-wise, this is what you are doing in your test:

1) Start the browser
2) Type www.ipleaks.net in your browser
3) The browser connects to the router's IP, asking it to resolve www.ipleaks.net
6) The kernel's routing database is queried. There is a request to connect FROM 192.168.1.91 TO 192.168.1.1. This matches the first policy rule, so the connection is forwarded to the VPN's DNS server.
7) The DNS server responds to the request, with "54.164.36.190"
8) The router gives that answer to the browser
9) The browser tries to do a TCP connection to 54.164.36.190
10) This matches your second policy rule, so that request gets routed through the VPN tunnel

The part that is confusing you is the fact that when connecting to a website, you are NOT connecting to a DNS server. These are two separate connections, so they hit both rules separately.

From 192.168.1.91 to 192.168.1.1: matches the VPN rule
From 192.168.1.91 to 54.164.36.190: matches the second, WAN rule

The web connection matches your VPN rule, and the DNS connection matches your WAN rule.

In summary: the router's routing database can only redirect a DNS query if the SOURCE IP matches. It's impossible to match based on the DESTINATION IP, as the connection to the DNS is to a totally different IP.

What you are trying to do with that specific setup you did is impossible. You can only force a device to a specific DNS based on the source IP - you cannot do it based on the destination IP.

What threw me of was the following;
"then those policies will also determine which DNS to use"
This to me, sounds like the router can choose which DNS to use according to the policy rule from a specific IP.
I appreciate the detailed answer and it makes sense.

My only concern at this point is when I am connected to a VPN server and I am sending data with special rules, where certain IP address's will go through ISP, for those packets going through the ISP being Comcast as an example,

isn't it dangerous showing the VPN IP as the DNS?
Wouldn't it be better if it showed the VPN actual DNS instead?

at least with the previous firmware it did exactly that when in exclusive or strict.
regardless of which service you where using either VPN or Local ISP from a policy rules
it would always give you in my case PIA VPN DNS which is 209.222.18.222,

I personally don't mind if the DNS shows that of the VPN but when it shows the actual IP of the VPN can't I be traced?

Just a suggestion,
Depending on the answer you give, would it be possible to put Exclusive's DNS back to where it gave the VPN DNS instead of VPN IP
I personally feel more comfortable sending Local ISP data through a VPN DNS then a VPN IP address.
What is your view on this?

 

[yorgi]

Network-wise, this is what you are doing in your test:


10) This matches your second policy rule, so that request gets routed through the VPN tunnel

You mean Local ISP because my rule was saying when you see this IP 54.164.36.190 is ipleak.dns go to WAN which is local isp not VPN tunnel
so I can see what DNS it resolved when sending data to local ISP from a policy rule

 

[RMerlin]

Just a suggestion,
Depending on the answer you give, would it be possible to put Exclusive's DNS back to where it gave the VPN DNS instead of VPN IP
I personally feel more comfortable sending Local ISP data through a VPN DNS then a VPN IP address.
What is your view on this?

That breaks Internet access for the other clients that still use WAN, as some VPN provider's DNS do not work outside of the tunnel.

Your issue lies in the fact that you are trying to have a client have a mixture of both routed and non-routed VPN access. If you want to prevent any leak for a client, you have to configure it so that ALL of its traffic is routed through the tunnel. Otherwise, if you are really worried about it, any website that isn't routed through the tunnel could "leak" your information, if you are so worried about it. You won't be able to manually "plug all the holes". Either route all of that client's traffic through the VPN tunnel, or expect part of its traffic to go to "the wrong places".

 

[yorgi]

ok that is the way i did it in the past.
thanks for all the information

 

[yorgi]

Either route all of that client's traffic through the VPN tunnel, or expect part of its traffic to go to "the wrong places".

In the example you use in your readme-merlin you show this example for
ISP's SMTP server going through WAN which bypass's the VPN

PC1 192.168.1.100 0.0.0.0 VPN
PC1-bypass 192.168.1.100 10.10.10.10 WAN

could you give me a good reason why anyone would do that if they are leaking VPN IP?

 

[RMerlin]

In the example you use in your readme-merlin you show this example for
ISP's SMTP server going through WAN which bypass's the VPN

PC1 192.168.1.100 0.0.0.0 VPN
PC1-bypass 192.168.1.100 10.10.10.10 WAN

could you give me a good reason why anyone would do that if they are leaking VPN IP?

Not everyone uses a VPN to hide themselves... VPNs are primarily used to connect two separate networks together. Since SMTP servers usually reject connections coming from an IP that's from a different ISP, you will most definitely want your local email client to keep routing itself through your local ISP for outbound email while you are connected to a remote VPN server. Otherwise, your email will most likely get rejected due to "relaying denied".

 

[yorgi]

Not everyone uses a VPN to hide themselves... VPNs are primarily used to connect two separate networks together. Since SMTP servers usually reject connections coming from an IP that's from a different ISP, you will most definitely want your local email client to keep routing itself through your local ISP for outbound email while you are connected to a remote VPN server. Otherwise, your email will most likely get rejected due to "relaying denied".

Fair enough. sorry for all the questions but I think this is a good topic and there are many people thinking along the same line.

As it is now I can have selected IP address's reserved for VPN and all other IP address go to Local ISP
For the Local ISP I use DNS filtering and assign Norton DNS to all my devices and it works perfect.
VPN has its DNS from the tunnel and Local ISP has Nortons DNS.

Would it be possible to add an option in DNSfiltering for "POLICY RULE" traffic to the "WAN" which can be filtered to another DNS other then the VPN's? As in the previous example so it can use Norton DNS?

 

[yorgi]

Not everyone uses a VPN to hide themselves... VPNs are primarily used to connect two separate networks together. Since SMTP servers usually reject connections coming from an IP that's from a different ISP, you will most definitely want your local email client to keep routing itself through your local ISP for outbound email while you are connected to a remote VPN server. Otherwise, your email will most likely get rejected due to "relaying denied".

I know am being a pain in the butt but can you please read this, you wrote it;

"If you enable Policy-based routing for a VPN client and you set the Accept DNS Configuration to "Exclusive", then the router will "AUTOMATICALLY" configure firewall rules that will force VPN clients to use the DNS server from your OpenVPN tunnel providers, and leave the non-VPN clients on your router's usual (typically your ISP's) DNS servers. This is implemented in a similar way that DNSFilter works, so those of you using DNSFilter to force VPN clients to specific DNS servers can now remove those DNSFilter rules."

"and leave the non-VPN clients on your router's usual (typically your ISP's) DNS servers. "
My ISP DNS server is 24.201.245.77 not VPN DNS as I am getting.
If your documentation is right then this firmware has a serious issue and it needs attention.

this is what I have been trying to explain all this time,
my problem is VPN traffic shows the proper DNS
But the ISP traffic should show ISP DNS instead its showing VPN IP

I am only making this point because I am sure others will read that and think the same.
I totally understood everything you explained in previous reply's this reply on my end is to simply clear this matter once and for all

Please make this clear in the documentation because as it is you are contradicting yourself.
nothing personal.

And this is referring to Policy based routing!

 

[Cake]

Yogi, give dnscrypt a try. After setting up optware/entware you can force all clients to use it with a couple lines in a script.
This way you won't need to worry about that setting because port 53 gets intercepted by the router, dns request gets encrypted, then sent out to a dns server of your choice(s) on a different port that your isp doesnt sniff/block/attach a tracker/etc.

I wish this was include in RMerlins code because I think most of Asus buyers bought these routers either for the AC, or for the VPN. I am in the latter camp (just look at all topics and posts on openvpn. The optware/entware way is fine however doing power failures sometimes my sdcard corrupts. I would prefer a solution that does not involve using sdcard. I also think dnscrypt is going to be around a while.

 

[yorgi]

The optware/entware way is fine however doing power failures sometimes my sdcard corrupts. I would prefer a solution that does not involve using sdcard. I also think dnscrypt is going to be around a while.

Instead of SDCARD put a Hard drive on there or a USB srick. You should never have a problem using entware this way.
I had entware in the past for selective routing and I never had a problem it worked perfect all the time. Power off or not