I figured it out: Both online-dns
servers (customer.com
and mysite.com
) had wildcard records setup, i.e. a A-record
like *.mysite.com
Therefore, when the ad.customer.com
internal DNS was queried for a fqdn on ad.mysite.com
, it was forwarded to OUR online-dns, the online-DNS responsible for mysite.com
answered with the primary IP due to it's wildcard-A-record:
I cannot change the Domain-Records for the customer, but i can change ours. So, I configured the metrics in order that the remote
connection is used first, but for our tld, I disabled the wildcard-record, leaving only valid
hostnames to be answered.
So, if a VPN-Connection is established now, Windows will start to query the customers local dns, even for internal hostnames, but then no longer receives a wrong answer (due to forwarding to the online-dns) but nothing.
NOW Windows seems to query the dns servers of the secondary connection (local one, higher metric), which then works and leads to the correct result:
Knowing the cause, another - maybe better - solution was easy to find:
While Solution 1 would always query the customers local DNS first, this one works with querying our local dns first:
First, ofc. Metrics of the two connections have been changed, so that the local connection is used first.
Inside our local DNS-Server I setup a Primary-Zone, matching the customers domain: customer.com
- and left it empty.
Now, our local DNS will answer with not found
rather than forwarding the query to the customers wildcard-using-online-dns-server. (Which cannot resolve their internal names)
My PC will now use the second (remote) connection, where the query for internal names can be resolved.
Drawback: Without an established VPN-Connection, I can no longer access the customers website, because our local dns is no longer forwarding these queries.
If I would need that as well, I could setup A-records in the "Fake-primary-Zone" ofc.
Best Answer
I found the same problem, it looks like a bug on iPhone's handling of PPTP. It works if you configure PPTP to assign DNS servers which are globally reachable (eg: Google's 8.8.8.8), but not if the DNS are within the VPN themselves.
A workaround is to setup an address like 8.8.8.8, and then intercept and redirect the traffic on the server side (in my case, with iptables).