Hi,
we have a strange issue with a not that special setup.
we have customers that run basically an IPv6-only infrastructure with some ipv4 reverse proxies in front of the services that need to be publicly available. Some of these internal services can be accessed using a VPN. The VPN connection will provide a static IPv6 address for the client and a route to the ipv6 only servers will be pushed so traffic goes through the VPN.
In chrome the above does not work if the client has no global IPv6 access (i.e. an IPv6 default route). It just does not resolve AAAA records as it seems, because access with literals (such as http://%5B2001:db8::1]) works.
Does anybody know if there is a knob to alter this behavior? Other tested browsers are Firefox, Opera, Midori and Lynx which seem to work fine.
PS: sorry I could not come up with a better subject :-)
Regards André
On 2014-07-16 15:40, Andre Keller wrote:
Hi,
we have a strange issue with a not that special setup.
we have customers that run basically an IPv6-only infrastructure with some ipv4 reverse proxies in front of the services that need to be publicly available. Some of these internal services can be accessed using a VPN. The VPN connection will provide a static IPv6 address for the client and a route to the ipv6 only servers will be pushed so traffic goes through the VPN.
Are they in effect on the client and does the application actually use them? Which OS is this on? Due to "Happy Eyeballs" you can have a lot of fun side-effects of IPv6 not being chosen for instance. (Split horizon, be that of IP or DNS tends to be a bad idea...)
In chrome the above does not work if the client has no global IPv6 access (i.e. an IPv6 default route).
That is more likely related to the OS in question.
It just does not resolve AAAA records as it seems, because access with literals (such as http://%5B2001:db8::1]) works.
Sounds like you are using Windows. There is a regedit option to solve that problem:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Dnscache\Parameters
DWORD AddrConfigControl = 0
google for that and you'll find more details.
Though note that Chrome does some kind of probing to "determine that you have working IPv4 IPv6 connectivity" (read: google like it when you contact them once in a while so they can better "understand" where you are")
Does anybody know if there is a knob to alter this behavior? Other tested browsers are Firefox, Opera, Midori and Lynx which seem to work fine.
PS: sorry I could not come up with a better subject :-)
Depends on the platform. While browsers do their own thing, the OS typically has a lot to say in it.
Note that when you are on OSX there is a lot of nonsense happening regarding address selection/ordering based on historical stats on latency/throughput and that stuff cannot be turned off.
Greets, Jeroen
❦ 16 juillet 2014 15:40 +0200, Andre Keller ak@list.ak.cx :
we have customers that run basically an IPv6-only infrastructure with some ipv4 reverse proxies in front of the services that need to be publicly available. Some of these internal services can be accessed using a VPN. The VPN connection will provide a static IPv6 address for the client and a route to the ipv6 only servers will be pushed so traffic goes through the VPN.
In chrome the above does not work if the client has no global IPv6 access (i.e. an IPv6 default route). It just does not resolve AAAA records as it seems, because access with literals (such as http://%5B2001:db8::1]) works.
Does anybody know if there is a knob to alter this behavior? Other tested browsers are Firefox, Opera, Midori and Lynx which seem to work fine.
Hi Andre!
There is a flag "--enable-ipv6": http://peter.sh/experiments/chromium-command-line-switches/
You can also check by visiting: chrome://net-internals/#dns
Chrome is testing if there is a functional IPv6 functionality. With only a partial connectivity, the test is failing. Maybe you could also advertise two default routes 0::/1 and 8000::/1 through the VPN to fix that (and routes the IPv6 probes that Chrome tries to send).
Hi Jeroen,
On 16.07.2014 15:58, Jeroen Massar wrote:
Are they in effect on the client and does the application actually use them?
yes, telnet to port 80 works, as do other browsers. Tcpdump on both ends indicates traffic takes to correct route.
Which OS is this on?
Ubuntu Linux 12.04 and Ubuntu Linux 14.04, probably others
It just does not resolve AAAA records as it seems, because access with literals (such as http://%5B2001:db8::1]) works.
Sounds like you are using Windows.
Nope.
Regards André
On 2014-07-16 16:07, Andre Keller wrote:
Hi Jeroen,
On 16.07.2014 15:58, Jeroen Massar wrote:
Are they in effect on the client and does the application actually use them?
yes, telnet to port 80 works, as do other browsers. Tcpdump on both ends indicates traffic takes to correct route.
Which OS is this on?
Ubuntu Linux 12.04 and Ubuntu Linux 14.04, probably others
There is a big variety in the glibc code bases, though in the case of browsers they typically avoid them.
You'll have to force enable IPv6 in Chrome it seems.
Greets, Jeroen
-
Andre Keller -
Jeroen Massar -
Vincent Bernat