no outgoing connection via ipv4

Question

I'm experiencing odd behavior on a VPS I own (Debian 8.6) and, honestly, have come to a point where I have no idea how to investigate it further or fix it.

As far as I can see the OS is only able to handle an outgoing request to an IPv6 address and not to an IPv4 address:

curl request to google on IPv4:

$ curl -v -4 google.be
* Rebuilt URL to: google.be/
* Hostname was NOT found in DNS cache
*   Trying 172.217.17.67...
* connect to 172.217.17.67 port 80 failed: Connection timed out
* Failed to connect to google.be port 80: Connection timed out
* Closing connection 0
curl: (7) Failed to connect to google.be port 80: Connection timed out

Traceroute to google on IPv4:

$ traceroute 172.217.17.67
traceroute to 172.217.17.67 (172.217.17.67), 30 hops max, 60 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  * * *

curl request to google on IPv6:

$ curl -v -6 google.be
* Rebuilt URL to: google.be/
* Hostname was NOT found in DNS cache
*   Trying 2a00:1450:400e:802::2003...
* Connected to google.be (2a00:1450:400e:802::2003) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.38.0
> Host: google.be
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: http://www.google.be/
< Content-Type: text/html; charset=UTF-8
< Date: Sat, 01 Oct 2016 13:55:01 GMT
< Expires: Mon, 31 Oct 2016 13:55:01 GMT
< Cache-Control: public, max-age=2592000
* Server gws is not blacklisted
< Server: gws
< Content-Length: 218
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: SAMEORIGIN
<
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.be/">here</A>.
</BODY></HTML>
* Connection #0 to host google.be left intact

traceroute to google on IPv6:

$ traceroute 2a00:1450:400e:802::2003
traceroute to 2a00:1450:400e:802::2003 (2a00:1450:400e:802::2003), 30 hops max, 80 byte packets
 1  v340.router1.dcga.ams.transip.net (2a01:7c8:aaac::2)  0.493 ms  0.409 ms  0.320 ms
 2  30gigabitethernet1-3.core1.ams1.he.net (2001:7f8:1::a500:6939:1)  11.541 ms  11.581 ms  11.569 ms
 3  amsix-router.google.com (2001:7f8:1::a501:5169:1)  1.531 ms  1.640 ms  1.509 ms
 4  2001:4860:0:f8d::1 (2001:4860:0:f8d::1)  1.500 ms 2001:4860:0:f8c::1 (2001:4860:0:f8c::1)  1.794 ms  1.871 ms
 5  2001:4860:0:1::15a9 (2001:4860:0:1::15a9)  1.774 ms  1.856 ms 2001:4860:0:1::15ad (2001:4860:0:1::15ad)  1.867 ms
 6  ams16s21-in-x03.1e100.net (2a00:1450:400e:802::2003)  1.857 ms  1.606 ms  1.459 ms

The strange thing however is, that the VPS is reachable over IPv4 (webserver and other services respond on the IPv4 address).

As far as I understand I have no firewall rules on outgoing connections that could cause this:

$ sudo iptables -L -n -v
Chain INPUT (policy DROP 76 packets, 4352 bytes)
 pkts bytes target     prot opt in     out     source               destination
 4330  481K LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 7 prefix "BANDWIDTH_IN:"
  664 79865 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
 4116  465K ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:10001
   36  2405 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:443
   47  3192 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp dpt:86
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            tcp multiport dports 20,21
    9   459 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:25
   46  5141 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp spt:53
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp spt:25

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 LOG        all  --  *      eth0    0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 7 prefix "BANDWIDTH_OUT:"
    0     0 LOG        all  --  eth0   *       0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 7 prefix "BANDWIDTH_IN:"

Chain OUTPUT (policy ACCEPT 7234 packets, 6355K bytes)
 pkts bytes target     prot opt in     out     source               destination
 6570 6275K LOG        all  --  *      eth0    0.0.0.0/0            0.0.0.0/0            LOG flags 0 level 7 prefix "BANDWIDTH_OUT:"

My network configuration:

$ sudo ifconfig
eth0      Link encap:Ethernet  HWaddr 52:54:00:xx:xx:xx
          inet addr:95.170.xx.xx  Bcast:95.170.xx.xx  Mask:255.255.255.0
          inet6 addr: 2a01:7c8:aaac:bb:5054:xx:xx:xx/64 Scope:Global
          inet6 addr: fe80::5054:xx:xx:xx/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:309169854 errors:0 dropped:0 overruns:0 frame:0
          TX packets:62960742 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:75197092341 (70.0 GiB)  TX bytes:32195269170 (29.9 GiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:92231464 errors:0 dropped:0 overruns:0 frame:0
          TX packets:92231464 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:13174664705 (12.2 GiB)  TX bytes:13174664705 (12.2 GiB)

I have another VPS with the same hosting provider and have no issues on that one.

Could you remove the firewall rules you've shown, and replace them with the output of `iptables -L -n -v`? Without the interface information, the rules are meaningless, and I'm slightly suspicious of them. — MadHatter, Oct 01 '16 at 14:30

score 9 · Accepted Answer · answered Oct 01 '16 at 14:55

9

Your problem isn't that your outbound packets are blocked, but that the inbound responses elicited by those outbound packets are blocked. Try adding a rule such as

iptables -A INPUT -m state --state ESTABLISHED -j ACCEPT

and see if that gets things working. By the way, it's always a good idea to end your ruleset with a logging rule, so that you can see what's falling off the end of the chain and being blocked by policy; something like

iptables -A INPUT -j LOG --log-prefix="INPUT DROP: "

That way, if you find you can't do something you thought you should be able to, you can see if any traffic is being dropped that might be causing the problem.

answered Oct 01 '16 at 14:55

MadHatter

79,770
20
184
232

Seems so obvious now... This did the trick, thank you! – KristofM Oct 01 '16 at 15:11
It's not so much the lines that are there as the lines that are not there ;). He has input policy set to drop and all the rules he has in the input chain are clearly aimed at allowing incoming connections. – Peter Green Oct 01 '16 at 21:48

no outgoing connection via ipv4

1 Answers1