Question : Remote Access Connections Binding Order for VPN Access fails

Hello everyone,

Summary
==========
I am experiencing slowness while browsing on the Internet via the VPN connection to the office internal network with IE7/Vista.
The slowness is not encountered with win2000/IE6.
The VPN connection problem might actually be related to the DNS server used by Vista:
Network capture shows that the windows 2000 station is most of the time using the DNS server with an IP address 10.68.161.3.
Network capture shows that the windows vista computer is most of the time using the DNS server with an IP address 194.51.3.56 to finally contact the DNS server 10.68.161.3.

The 194.51.3.56 DNS server is the one related to Orange operator and is configured on the Ipass VPN connection.
I checked the VPN connection configuration on both a windows vista computer and on a windows 2000 computer and both are configured to use the Orange DNS server with the address 194.51.3.56.

The main difference between the two situations is that IE7/Vista gives precedence to the External Orange DNS server for name resolution when the IE6/2000 directly uses the DNS server configured on the LAN private interface.

When performing an NSLOOKUP on the Vista computer:
- On the windows vista / IE8 computer the DNS server used by the utility is 194.51.3.56
- On the windows 2000 / IE6  computer the DNS server used by the utility is 10.68.161.3

I thought that the precedence between the DNS servers used for name resolution was defined on the basis of the precedence between connections. Therefore I checked and changed the priorities between the connections in order to have the remote access (VPN) connection set as primary connection in the connection list.

I kind of improved the situation by changing the content of the proxy.pac by added the following modification to the proxy .pac file:
Before:
if ( isResolvable("http.internetpsa") ) return true;
After:
if ( isResolvable("http.internetpsa.inetpsa.com") ) return true;
As well the specified that if a netbios name is queried then the query is directly sent to the private network through the VPN network thanks to the syntax:
if ( (isPlainHostName(host)) ) return EnDirect;
The customer has difficulties to obtain information about the script but it seems logical to consider that it works like that:
- if the name is a netbios name then the query is transferred to the internal proxy
- if the name is an FQDN ending by internetpsa.inetpsa.com and if the DNS server can resolve it then then the query may be sent to the internal network.

In this situation the question is: which DNS server is queried by the script. I think it is the Orange proxy server.

I tried to resolve the suffix nternetpsa.inetpsa.com on the internet and this is not a publicly know domain suffix. I could not directly query the Orange DNS: it refused my queries so I cannot go further in the investigation.

I specified in the proxy.pac script the DNS suffix inetpsa.com for both machines detected as connected to the VPN connection.
In this case the problem might be related to the fact that the DNS resolution is slow down by the fact that the DNS suffix is not specified in the PPP VPN connection.

Basically both computer with IE6 and IE7 are relying on the same script so unless there are differently interpreting the script we may consider that the script is not the main reason for the problem: nslookup utility use a different proxy on both computers Vista and XP and I do not think that this is related to the script.

How to resolve the problem?
Would it be necessary to configure the client Vista computer to use the LAN connection internal DNS as the primary server instead of the Orange DNS server?

Many thanks for any input that may help,

Kind regards

Trevor

Answer : Remote Access Connections Binding Order for VPN Access fails

When it comes to DNS for Directory services:
- Never publish this info in public DNS servers
- Your LAN machines will AWLAYS need to use Internal DNS for resolution.  You can also configure the internal DNS with forwarders.

Posted via EE Mobile