Two suggestions related to this.
* IPv4 vs IPv6, DNS and resolver affinity: If running a with an openvpn client configuration that has a "server" line with a FQDN (fully-qualified-domain-name) that can resolve to IPv6 and IPv4 addresses, check to see if the OpenVPN server you are trying to connect to provides service for IPv4 and IPv6 clients. Many resolvers in OS have an affinity to resolve DNS AAAA records over A or CNAME, and will tend to favor IPv6 addresses being resolved for a name to IP if there are both IPv4 and IPv6 addresses available.
* Domains that support DNSSec : many ISP are moving to apply rules of DNSSec with name-to-IP lookups n the DNS Servers *they* run for their customers. If another domain name is poorly configured with DNSSec, or has expired keys, properly enforcing DNS Servers completing your query against DNS that have DNSSec configured will NOT pass on any IP addresses to their customers because the results can't be validated. Some ISP have experimented with partial DNSSec support, or a kludgy redirection to a web page that tells the *web* client that the attempt to resolve the name to an IP resulted in DNSSec problems. Such a web page would not be visible to "you" if your OpenVPN client is being redirected to a different IP than what is expected.
I know Comcast was early to experiment with DNSSec and adopt use of IPv6. Would anyone that encounters the problem described in this thread please check to see if any of these above items are the source of troubles? Some suggested methods to test are listed below:
DNS lookups, IPv4 vs IPv6 or some other DNS issue: If you have a linux shell with "dig" installed...
In these examples, I am using "8.8.8.8" (google's public DNS Server's IPv4 IP address) and 2001:4860:4860::8888 (google's public DNS Server's IPv6 IP address.)
The "-4" says, use my IPv4 IP address and connect to the IPv4 address of the server (useful if you use names instead of IP addresses for which DNS Server you want to use) and the "-6" says use an IPv6 IP address on my machine to talk to a DNS running with an IPv6 address. (Using an IPv4 address for DNS after the "@" already requests IPv4 implicitly, but including in case you replace the value after the "@" with a name.)
The "A" is conventionally a record for name to IPv4 address.
The "AAAA" is a record for name to IPv6 address.
Query Google's IPv6 DNS Server, and ask for an AAAA record (IPv6 address, if any) for the host name "
www.google.com":
Code: Select all
$ dig +short @2001:4860:4860::8888 -6 -t AAAA www.google.com
2607:f8b0:4005:807::2004
Query Google's IPv4 DNS Server, and ask for an A record (IPv4 address, if any) for the host name "
www.google.com":
Code: Select all
dig +short @8.8.8.8 -4 -t A www.google.com
216.58.195.68
An example using a case where CNAME record is used instead of A record:
Code: Select all
dig +short @8.8.8.8 -4 -t CNAME www.microsoft.com
www.microsoft.com-c-2.edgekey.net.
In this case, a CNAME resolves to a name, which you could then resolve, and follow until you find the IP address.
If any of the intermediate CNAME in the chain to your final IP address use DNSSec, then those domains may also need to be investigated for proper configuration.
Replace "
www.google.com" or "
www.microsoft.com" with the fully-qualified-domain-name in your client's "server ...." config line. See what results you find.
Next, try the same against your ISP's provided DNS servers and replace the valued after the "@" with your ISP's DNS Server IP. Do you get the same results?
If the results do not match what you see from google's DNS, how are they different? Does one resolve to an IP while the other does not? Do they resolve to different IP? If different, who owns the netblock of the IP address that is an unexpected result?
Next, tools for DNSSec checks... less likely as a cause, but possible:
Online, here 2 useful tools for this:
*
http://dnsviz.net/ (A cached example with google.com:
http://dnsviz.net/d/google.com/dnssec/ and an example for comcast.net:
http://dnsviz.net/d/comcast.net/dnssec/ )
*
http://dnssec-debugger.verisignlabs.com/ (An example with google.com:
http://dnssec-debugger.verisignlabs.com/google.com and an example with comcast.net:
http://dnssec-debugger.verisignlabs.com/comcast.net )
If your domain uses delegation with sub-domains, then you may need to check your domain name, *and* sub-domains for proper DNSSec configurations, all the way up to, but not including a hostname for each sub-domain delegation with DNSSec.
For organizations that run things other than VPN, they probably have a HOSTname.domain.TLD for their client's "server ..." config lines. Dedicated VPN service providers may not. When you complete your DNSSec checks you want to stop off the "HOSTname" (of any) from the "server ..." config line when submitting it to those two DNSSec example tools. (So, if google had an openvpn server and client config lines that looked like "server openvpn.google.com" then the domain to check with these tools would be "google.com" and almost certainly not "openvpn.google.com")
If you find that CNAME were uses to other names in the top step, you will want to check the DNSSec status of those domains and/or sub-domains until you finally reach an IP address.
If you find that the problems you are encountering are not related to these two issues (IPv6 address resolved vs IPv4 address resolved, OR DNSSec validation/configuration issues) please follow-up saying so.
If you find that one or both are the source of trouble, please also post that information.
Knowing what the source of the problem is would help to know if this is a bug or not, and if not, how to fix it or side-step it.
I have not had any problems with client resolution on Comcast or Verizon, or Sprint, or AT&T when I used them, but I use properly configured domains using DNSSec for my domains to validate hosts, support dual-stack IPv4/IPv6 with service for both for each server name and port.