Peplink's caching dns resolver leaking bytes across pay-per-byte networks

[breathevalue]

The peplink’s caching dns resolver is leaking bytes across one of our pay-per-byte networks … We want to keep this network as an ‘active backup’ not a cold spare as we selectively move only very specific traffic over this link under some circumstances. There doesn’t seem to be a way to prevent the peplink dns resolver from resolving dns via this link whenever it so chooses though … We are running 6.1.2 build 3071 on a balance 580.

I’ve found Network -> Default Connection Priority and Network -> Lan -> DNS Proxy -> Advanced. The options under DNS Proxy -> Advanced aren’t explained very well – but its my guess from testing that the ‘Preferred Connections’ checkbox relates to the settings in Network -> Default Connection Priority – and there is no way to uncheck the ‘Preferred Connections’ box (it doesn’t uncheck when clicked).

My guess of how this is working is that when the higher priority WAN becomes very slow to resolve DNS (which happens all the time in our environment which consists of slow congested satellite links), peplink starts resolving dns via the ‘preferred connections’ policy. I would rather that DNS is always resolved based on the result of the health-check evaluation. As long as the congestion on my higher priority WAN is insufficient to cause my health check to fail, the peplink will keep attempting to resolve DNS via the higher priority WAN – and only after health check has failed will it start resolving DNS by the lower priority WAN.

I’ve been capturing traffic using https://rr-peplink-gw/cgi-bin/MANGA/support.cgi and analyzing the pcap file for the ‘expensive’ WAN – this is the easy way to observe the undesirable DNS activity on that WAN – note that I’m completely certain the activity I’m observing on the lower priority WAN is not DNS health check activity but rather normal dns resolution being performed on behalf of hosts on my network pointed at the peplink’s dns resolver … This is 100% confirmed by disabling dns health check on that WAN.

Am I missing some way to better control the behavior of the peplink dns resolver?

[sitloongs]

Hi,

We are aware of this issue and it will be fix in firmware version 6.2. Tentatively firmware 6.2 will be release in a month time.

[sitloongs]

Hi,

Pleas provide the below info for us to further understand your issue:

1. How many WAN link are connected for your Balance device?
2. What is the WAN ‘connection type’ set for all the connected WANs ? ( ‘Always-on’ or ‘Backup Priority’)
3. If you are using ‘Mobile Internet’ WAN with ‘connection type’ ‘Backup Priority’ set, what is the ‘Standby State’ set for the WAN ?
4. What is the DNS server set for all clients PC at your network ?
5. What are the outbound policy set to forward network traffics to the ‘expensive’ WAN.
6. Please clarify also the ‘expensive’ WAN is configure under which WAN connection and connection method (Satellite or Mobile Cellular or Wired WAN or other)

Regarding to your guessing for DNS resolver, we will discuss it after we further understand your setting.

For more info regrading to the Balance settings ‘connection type’ & ‘Standby State’, please refer to the below screenshots.

[breathevalue]

@sitloongs

Hi,

Pleas provide the below info for us to further understand your issue:

1. How many WAN link are connected for your Balance device?

5 – but in this typical case only 2 of the 5 are online – the other 3 are offline continuously for days or months (not flapping).

2. What is the WAN ‘connection type’ set for all the connected WANs ? ( ‘Always-on’ or ‘Backup Priority’)

Always on

3. If you are using ‘Mobile Internet’ WAN with ‘connection type’ ‘Backup Priority’ set, what is the ‘Standby State’ set for the

Neither of the two available WANS are ‘Mobile Internet’

4. What is the DNS server set for all clients PC at your network ?

A caching-forwarding (non-recursive) dns server on our LAN which forwards all dns requests to the peplink caching resolver.

5. What are the outbound policy set to forward network traffics to the ‘expensive’ WAN.

This question is not well formed. ‘Priority’ rules exist which route traffic over the less expensive wan before routing over the more expensive WAN – this means that when the less expensive WAN is available it is used

In some circumstances, a rule is turned on which routes traffic from a specific src ip via the more expensive WAN. We also sometimes will route traffic destined for a specific port over the more expensive WAN rather than the less expensive WAN.

6. Please clarify also the ‘expensive’ WAN is configure under which WAN connection and connection method (Satellite or Mobile Cellular or Wired WAN or other)

Both the expensive and non-expensive WAN are satellite internet systems connected to the wired interfaces of the peplink with ping health tests.

Re-stating the issue again:

During a period of time when non-expensive WAN passes health check, the peplink dns resolver sends some dns traffic via the expensive WAN. There doesn’t seem to be a way to control the peplink dns resolver so that the dns traffic doesn’t go over the more-expensive WAN when the less-expensive WAN is available.

[TK_Liew]

Hi,

Thank you for your explanation. This is a known issue on v6.1.2 and has been rectified in v6.2 GA. Tentatively v6.2 GA will be available on Q1 2015.

For workaround, you may forward DNS request from your DNS server to public DNS then use outbound policy to divert to desired WAN.