Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Standard non working IPv6 issue with some OpenVZ/SolusVM hosts
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Standard non working IPv6 issue with some OpenVZ/SolusVM hosts

SpiritSpirit Member
edited April 2012 in Providers

Every now and then I get OpenVZ/SolusVM vps with native IPv6 where host try to convience me that IPv6 works because he can ping6 it even when it's evidently to me that it don't work. Most hosts fix it after extensive ticketing which can be exhausting every time... and as it seems it's always same issue. So I am wondering what's wrong with this default IPv6 setup where I can't curl/lynx/irssi/anything... with IPv6. Could be some overrided ip6tables rule by solusvM maybe or...?
Some of you which run IPv6 connected OpenVZ/SolusVM nodes may be familiar with the issue so I thought to ask here for future references.. as it's really annoying to send out so many ticket always for same thing.

root@lowendbox:~# curl ipv6.google.com
curl: (7) couldn't connect to host

If i recall correctly this happened to some solusVM openvz VPSs everytime they rebooted host node.

Comments

  • Maybe it's not IPv6 connectivity but DNS resolution?

    Try this (if you have bind-utils installed): dig -6 -t AAAA ipv6.google.com

    Thanked by 1Spirit
  • SpiritSpirit Member
    edited April 2012

    Thank you for guessing but it's not DNS resolution. I experienced same thing in past with atleast 4 known openvz/solusvm LEB hosts and all of them resolved issue after some ticketing.
    Problem is that some tech support guys believe that IPv6 works properly just because they can ping it. With some hosts (ie. nordicvps) it took days of explanations before they found out what's wrong and with some more competent (ie. fanaticalvps) some minute or two. Whatever it is, it seems like default solusVM issue which can be resolved.

    dig -6 -t AAAA ipv6.google.com

    ; <<>> DiG 9.7.3 <<>> -6 -t AAAA ipv6.google.com
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38212
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 0
    ;; QUESTION SECTION:
    ;ipv6.google.com. IN AAAA
    ;; ANSWER SECTION:
    ipv6.google.com. 604800 IN CNAME ipv6.l.google.com.
    ipv6.l.google.com. 300 IN AAAA 2a00:1450:4010:c00::93
    ;; AUTHORITY SECTION:
    google.com. 172800 IN NS ns4.google.com.
    google.com. 172800 IN NS ns3.google.com.
    google.com. 172800 IN NS ns1.google.com.
    google.com. 172800 IN NS ns2.google.com.
    ;; Query time: 244 msec
    ;; SERVER: ::1#53(::1)
    ;; WHEN: Sun Apr 22 04:00:47 2012
    ;; MSG SIZE rcvd: 154

    Thanked by 1trewq
  • JacobJacob Member

    Not sure, I had a few issues getting IPv6 to work originally but I got them sorted.
    I still have 2 nodes that IPv6 Just doesn't work at all on, It is still quite buggy but majority of that is proberly down to SolusVM.

    Thanked by 1Spirit
  • AnthonySmithAnthonySmith Member, Patron Provider

    It is most likely (OpenVZ wise) because of the failure in CentOS 5.x to add the default routes properly on boot requiring the host to manually ip -6 route add dev eth0 and the via ::/0

    This is not required on centos6 and I assume the hosts you dont have this issue with have added that as a start up script

    On Xen if you have a centos5 VPS you may also have to do this yourself if you reboot, it seems to be a 2.6.18 centos5 issue, I dont think it is solusvm.

    Thanked by 1Spirit
  • @AnthonySmith said: It is most likely (OpenVZ wise) because of the failure in CentOS 5.x to add the default routes properly on boot requiring the host to manually ip -6 route add dev eth0 and the via ::/0

    I've never had this, but basic networking is pretty easy, still a good place to check.

    I've had nodes that do present this issue as all my OpenVZ nodes are still EL5 and is fixed by adding proper entries in /etc/sysclt.conf on the node.

    Thanked by 1Spirit
  • When ip6tables is installed on the CentOS based OpenVZ node it by default installs some stupid rules that break all connectivity for the containers. These rules must be removed, or as you experienced - only icmp will pass.

    Thanked by 1Spirit
  • prometeusprometeus Member, Host Rep

    I think that, as said it's the provider forgotting to adjust / disable ip6tables or to update sysctl.conf with the few required settings.

    Thanked by 1Spirit
  • SpiritSpirit Member
    edited April 2012

    @rds100 and @prometeus was right in this last case and as I thought from beginning there was unexpected default ip6table rules not added by admin. Once again host was working with me and found issue: "For future reference, yes, ip6table is the main issue.
    There is -by default- a rule that blocks traffic to newly added VM's...have NO idea why, this is the rule i have deleted, and now its working just fine."

    I will bookmark this thread and hopefully save some time from explanations with some other future host with same issue. I really get this "I can ping it so it works" often... :) Thanks to everyone for participation in this thread.

Sign In or Register to comment.