Skip to main content

linux - Ping to IPv4 works but IPv6 does not

I have a hosted VPS running on arch linux. I'm trying to
make outgoing connections from this server, but all of them fail. After a little bit of
debugging, I figured that the reason for failed connections is that my server cannot
access IPv6 addresses. Ping to IPv4 addresses work, but not to IPv6. Here is a
sample.




[root@li863-18
            /]# nslookup google.com
Server: 103.3.60.20
Address:
            103.3.60.20#53

Non-authoritative answer:
Name:
            google.com
Address: 74.125.68.100
Name:
            google.com
Address: 74.125.68.102

Name:
            google.com
Address: 74.125.68.113
Name:
            google.com
Address: 74.125.68.139
Name:
            google.com
Address: 74.125.68.138
Name:
            google.com
Address: 74.125.68.101
Name:
            google.com
Address:
            2404:6800:4003:c02::8a


[root@li863-18 /]# ping
            74.125.68.100
PING 74.125.68.100 (74.125.68.100) 56(84) bytes of
            data.
64 bytes from 74.125.68.100: icmp_seq=1 ttl=50 time=1.20 ms
64
            bytes from 74.125.68.100: icmp_seq=2 ttl=50 time=1.32 ms
64 bytes from
            74.125.68.100: icmp_seq=3 ttl=50 time=1.41 ms
^C
--- 74.125.68.100
            ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time
            2003ms
rtt min/avg/max/mdev = 1.200/1.311/1.414/0.097
            ms

[root@li863-18 /]# 
[root@li863-18 /]# ping
            2404:6800:4003:c02::8a
PING 2404:6800:4003:c02::8a(2404:6800:4003:c02::8a) 56
            data bytes
^C
--- 2404:6800:4003:c02::8a ping statistics
            ---
7 packets transmitted, 0 received, 100% packet loss, time
            6070ms


My networking
configuration. I've run the commands ip a s, ip -6
r s and cat
/etc/resolv.conf:




[root@li863-18
            /]# ip a s
1: lo:  mtu 65536 qdisc noqueue state
            UNKNOWN group default qlen 1
 link/loopback 00:00:00:00:00:00 brd
            00:00:00:00:00:00
 inet 127.0.0.1/8 scope host lo
 valid_lft forever
            preferred_lft forever
 inet6 ::1/128 scope host 
 valid_lft forever
            preferred_lft forever
2: dummy0:  mtu 1500
            qdisc noqueue state UNKNOWN group default qlen 1000
 link/ether
            ea:46:ac:25:5b:a3 brd ff:ff:ff:ff:ff:ff
 inet6 fe80::99c7:bfde:3127:700c/64
            scope link 

 valid_lft forever preferred_lft forever
3:
            ens4:  mtu 1500 qdisc fq_codel state UP group
            default qlen 1000
 link/ether f2:3c:91:e4:50:68 brd
            ff:ff:ff:ff:ff:ff
 inet 139.162.21.18/24 brd 139.162.21.255 scope global
            ens4
 valid_lft forever preferred_lft forever
 inet6
            2400:8901::f914:4433:e826:6f2a/64 scope global mngtmpaddr noprefixroute dynamic
            
 valid_lft 2592000sec preferred_lft 604800sec
 inet6
            fe80::f03c:91ff:fee4:5068/64 scope link 
 valid_lft forever preferred_lft
            forever
4: teql0:  mtu 1500 qdisc noop state DOWN group default
            qlen 100

 link/void 
5: tunl0@NONE:  mtu
            1480 qdisc noop state DOWN group default qlen 1
 link/ipip 0.0.0.0 brd
            0.0.0.0
6: gre0@NONE:  mtu 1476 qdisc noop state DOWN group
            default qlen 1
 link/gre 0.0.0.0 brd 0.0.0.0
7: gretap0@NONE:
             mtu 1462 qdisc noop state DOWN group default qlen
            1000
 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
8:
            ip_vti0@NONE:  mtu 1428 qdisc noop state DOWN group default qlen
            1
 link/ipip 0.0.0.0 brd 0.0.0.0
9: ip6_vti0@NONE:  mtu
            1500 qdisc noop state DOWN group default qlen 1

 link/tunnel6 ::
            brd ::
10: sit0@NONE:  mtu 1480 qdisc noop state DOWN group
            default qlen 1
 link/sit 0.0.0.0 brd 0.0.0.0
11: ip6tnl0@NONE:
             mtu 1452 qdisc noop state DOWN group default qlen 1

            link/tunnel6 :: brd ::
12: ip6gre0@NONE:  mtu 1448 qdisc noop
            state DOWN group default qlen 1
 link/gre6
            00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 brd
            00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[root@li863-18 /]# ip -6 r
            s
2400:8901::/64 dev ens4 proto kernel metric 203 mtu 1500 pref
            medium
fe80::/64 dev ens4 proto kernel metric 256 pref
            medium

fe80::/64 dev dummy0 proto kernel metric 256 pref
            medium
default via fe80::1 dev ens4 metric 203 mtu 1500 pref
            medium
[root@li863-18 /]# cat /etc/resolv.conf
# Generated by
            resolvconf
domain members.linode.com
nameserver
            103.3.60.20
nameserver 139.162.11.5
nameserver
            139.162.13.5



Adding
traceroute info.



[root@li863-18
            /]# traceroute google.com
traceroute to google.com (74.125.68.138), 30 hops
            max, 60 byte packets
 1 103.3.60.3 (103.3.60.3) 0.711 ms 0.936 ms 1.085
            ms
 2 139.162.0.9 (139.162.0.9) 0.638 ms 0.654 ms 139.162.0.13 (139.162.0.13)
            0.606 ms
 3 15169.sgw.equinix.com (27.111.228.30) 0.827 ms 0.826 ms 0.820
            ms
 4 108.170.242.66 (108.170.242.66) 1.074 ms 108.170.243.19 (108.170.243.19)
            1.122 ms 108.170.240.226 (108.170.240.226) 1.107 ms
 5 209.85.243.215
            (209.85.243.215) 1.440 ms 209.85.243.241 (209.85.243.241) 20.269 ms 108.170.240.173
            (108.170.240.173) 1.702 ms
 6 209.85.255.217 (209.85.255.217) 7.835 ms
            216.239.51.61 (216.239.51.61) 1.884 ms 209.85.243.209 (209.85.243.209) 1.532
            ms

 7 216.239.48.73 (216.239.48.73) 4.784 ms 216.239.51.61
            (216.239.51.61) 2.075 ms *
 8 * * *
 9 * * *
10 * *
            *
11 * * *
12 * * *
13 * * *
14 * *
            *
15 * sc-in-f138.1e100.net (74.125.68.138) 1.490 ms 1.653
            ms
[root@li863-18 /]# traceroute 74.125.68.138

traceroute
            to 74.125.68.138 (74.125.68.138), 30 hops max, 60 byte packets
 1 103.3.60.3
            (103.3.60.3) 0.889 ms 0.868 ms 1.311 ms
 2 139.162.0.9 (139.162.0.9) 0.709 ms
            139.162.0.13 (139.162.0.13) 0.650 ms 139.162.0.9 (139.162.0.9) 0.687 ms
 3
            139.162.0.18 (139.162.0.18) 0.658 ms 15169.sgw.equinix.com (27.111.228.30) 0.727 ms
            139.162.0.18 (139.162.0.18) 0.625 ms
 4 15169.sgw.equinix.com (27.111.228.30)
            0.715 ms 108.170.240.226 (108.170.240.226) 1.488 ms 108.170.240.162 (108.170.240.162)
            6.201 ms
 5 108.170.240.236 (108.170.240.236) 1.202 ms 108.170.242.71
            (108.170.242.71) 1.114 ms 216.239.42.47 (216.239.42.47) 1.688 ms
 6
            209.85.255.80 (209.85.255.80) 3.119 ms 209.85.243.241 (209.85.243.241) 2.212 ms
            209.85.242.221 (209.85.242.221) 1.597 ms
 7 209.85.255.80 (209.85.255.80)
            7.597 ms 1.422 ms 72.14.236.130 (72.14.236.130) 10.235 ms
 8 * * *

            9 * * *

10 * * *
11 * * *
12 * * *
13
            * * *
14 * * *
15 * sc-in-f138.1e100.net (74.125.68.138) 1.869 ms
            1.878 ms
[root@li863-18 /]# traceroute
            2404:6800:4003:c02::64
traceroute to 2404:6800:4003:c02::64
            (2404:6800:4003:c02::64), 30 hops max, 80 byte packets
 1 * * *
 2 *
            * *

 3 * * *
 4 * * *
 5 * * *
 6 * *
            *
 7 * * *
 8 * * *
 9 * * *
10 * *
            *
11 * * *
12 * * *

13 * * *
14 * *
            *
15 * * *
16 * * *
17 * * *
18 * *
            *
19 * * *
20 * * *
21 * * *
22 * *
            *

23 * * *
24 * * *
25 * * *
26 * *
            *
27 * * *
28 * * *
29 * * *
30 * *
            *



Any
pointer as to why this is the case. I would not want to disable IPv6 addresses through
kernel unless absolutely necessary.

Comments

Post a Comment

Popular posts from this blog

linux - iDRAC6 Virtual Media native library cannot be loaded

When attempting to mount Virtual Media on a iDRAC6 IP KVM session I get the following error: I'm using Ubuntu 9.04 and: $ javaws -version Java(TM) Web Start 1.6.0_16 $ uname -a Linux aud22419-linux 2.6.28-15-generic #51-Ubuntu SMP Mon Aug 31 13:39:06 UTC 2009 x86_64 GNU/Linux $ firefox -version Mozilla Firefox 3.0.14, Copyright (c) 1998 - 2009 mozilla.org On Windows + IE it (unsurprisingly) works. I've just gotten off the phone with the Dell tech support and I was told it is known to work on Linux + Firefox, albeit Ubuntu is not supported (by Dell, that is). Has anyone out there managed to mount virtual media in the same scenario?
Post a Comment
Read more

hp proliant - Smart Array P822 with HBA Mode?

We get an HP DL360 G8 with an Smart Array P822 controller. On that controller will come a HP StorageWorks D2700 . Does anybody know, that it is possible to run the Smart Array P822 in HBA mode? I found only information about the P410i, who can run HBA. If this is not supported, what you think about the LSI 9207-8e controller? Will this fit good in that setup? The Hardware we get is used but all original from HP. The StorageWorks has 25 x 900 GB SAS 10K disks. Because the disks are not new I would like to use only 22 for raid6, and the rest for spare (I need to see if the disk count is optimal or not for zfs). It would be nice if I'm not stick to SAS in future. As OS I would like to install debian stretch with zfs 0.71 as file system and software raid. I have see that hp has an page for debian to. I would like to use hba mode because it is recommend, that zfs know at most as possible about the disk, and I'm independent from the raid controller. For us zfs have many benefits,
Post a Comment
Read more

apache 2.2 - Server Potentially Compromised -- c99madshell

So, low and behold, a legacy site we've been hosting for a client had a version of FCKEditor that allowed someone to upload the dreaded c99madshell exploit onto our web host. I'm not a big security buff -- frankly I'm just a dev currently responsible for S/A duties due to a loss of personnel. Accordingly, I'd love any help you server-faulters could provide in assessing the damage from the exploit. To give you a bit of information: The file was uploaded into a directory within the webroot, "/_img/fck_uploads/File/". The Apache user and group are restricted such that they can't log in and don't have permissions outside of the directory from which we serve sites. All the files had 770 permissions (user rwx, group rwx, other none) -- something I wanted to fix but was told to hold off on as it wasn't "high priority" (hopefully this changes that). So it seems the hackers could've easily executed the script. Now I wasn't able
Post a Comment
Read more