pulse secure client auto connect connects to wrong location

Also, take note that a different ISP is used for the VPN clients and the central connection to the ISA server. What was interesting was that only some VPN users were affected although they all use the same configuration, except the type of sharing device connecting their workstation to the cable/dsl modem.

So, that old VPN name resolving issue was cropping up again and this time it was really breaking things. It was not difficult to determine that the failing internal services were those defined in the external DNS server too. When I started to publish some internal services and set up a well designed split DNS infrastructure to support it, I immediately got some complaints from some VPN users that some internal services were no longer reachable. Because it didn't seem to break anything in the configuration I work with, at most I could see a small slow down in name resolving, I didn't bother to fix that problem. However, in practice we didn't see that behavior consistently, even if we manually placed the RRAS adapter to the top of the connections list in the Advanced Settings dialog box of the Network and Dial-up Connections tool. As you probably know, the adapter order plays an important role in the DNS resolving process because the DNS servers associated with the adapter that has the highest binding order in the adapter list are tried first. Everybody seems to agree that when the VPN client connects, we expect that the RRAS adapter will automatically be placed on the top of the adapter list.

A couple of years ago I had some good discussions with different people, including a guy from Microsoft Networking Support, about how the name resolution for VPN clients was supposed to work.

Pulse secure client auto connect connects to wrong location