Is it better to set rules in ip6tables or disable ipv6

iptablesipv6

I have the following network configuration:

# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:e0:1c:73:02:09
          inet addr:10.1.4.41  Bcast:10.1.255.255  Mask:255.255.0.0
          inet6 addr: fe80::2e0:4cff:fe75:309/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:858600 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1069549 errors:0 dropped:0 overruns:5 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:142871181 (136.2 MiB)  TX bytes:717982640 (684.7 MiB)

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:37952 errors:0 dropped:0 overruns:0 frame:0
          TX packets:37952 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3396918 (3.2 MiB)  TX bytes:3396918 (3.2 MiB)

I have DHCP server in my network and I can get the following lease:

lease {
  interface "eth0";
  fixed-address 10.1.4.41;
  option subnet-mask 255.255.0.0;
  option routers 10.1.255.253;
  option dhcp-lease-time 120;
  option dhcp-message-type 5;
  option domain-name-servers 82.160.125.52,213.199.198.248,82.160.1.1;
  option dhcp-server-identifier 192.168.22.22;
  renew 3 2014/01/01 18:34:41;
  rebind 3 2014/01/01 18:35:30;
  expire 3 2014/01/01 18:35:45;
}

I can ping 127.0.0.1, ::1, 10.1.4.41:

$ ping 10.1.4.41
PING 10.1.4.41 (10.1.4.41) 56(84) bytes of data.
64 bytes from 10.1.4.41: icmp_seq=1 ttl=64 time=0.065 ms
64 bytes from 10.1.4.41: icmp_seq=2 ttl=64 time=0.075 ms
64 bytes from 10.1.4.41: icmp_seq=3 ttl=64 time=0.085 ms
^C
--- 10.1.4.41 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.065/0.075/0.085/0.008 ms

$ ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.066 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.056 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.055 ms
^C
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.055/0.059/0.066/0.005 ms

$ ping6 ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.052 ms
64 bytes from ::1: icmp_seq=2 ttl=64 time=0.049 ms
64 bytes from ::1: icmp_seq=3 ttl=64 time=0.037 ms
^C
--- ::1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1998ms
rtt min/avg/max/mdev = 0.037/0.046/0.052/0.006 ms

I can't ping the ipv6 address fe80::2e0:4cff:fe75:309:

$ ping6 fe80::2e0:4cff:fe75:309
connect: Invalid argument

I have set some iptables rules (ipv4):

# iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N TCP
-N UDP
-A INPUT -i eth0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i tun0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
-A OUTPUT -m conntrack --ctstate INVALID -j DROP

And it works as expected for ipv4. But when I check ip6tables, I can see some packets go there:

# ip6tables -nvL
Chain INPUT (policy ACCEPT 381 packets, 27624 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 390 packets, 26296 bytes)
 pkts bytes target     prot opt in     out     source               destination

I followed this guide, and they say that I should copy the iptables (ipv4) configuration and paste it in ip6tables (ipv6). But when I do this, no packet can go through the rule RELATED,ESTABLISHED in the ipv6 table. All of them are dropped because of INPUT chain policy (DROP).

# ip6tables -nvL
Chain INPUT (policy DROP 5 packets, 360 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all      eth0   *       ::/0                 ::/0                 ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all      lo     *       ::/0                 ::/0
    0     0 ACCEPT     all      tun0   *       ::/0                 ::/0                 ctstate RELATED,ESTABLISHED
    0     0 DROP       all      *      *       ::/0                 ::/0                 ctstate INVALID
    0     0 UDP        udp      *      *       ::/0                 ::/0                 ctstate NEW
    0     0 TCP        tcp      *      *       ::/0                 ::/0                 tcp flags:0x17/0x02 ctstate NEW
    0     0 REJECT     tcp      *      *       ::/0                 ::/0                 reject-with tcp-reset
    0     0 REJECT     udp      *      *       ::/0                 ::/0                 reject-with icmp6-port-unreachable

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       all      *      *       ::/0                 ::/0                 ctstate INVALID

Chain TCP (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain UDP (1 references)
 pkts bytes target     prot opt in     out     source               destination

As you can see there's no output packets, so why google and stack exchange try to connect to my machine? And how do they do it because even I can't ping my ipv6 address?

They also say if my ISP doesn't have ipv6 (in the lease, there's no ipv6 entry) I should disable ipv6 and had done this before by using ipv6.disable=1. I asked similar question at meta.stackoverflow.com, and I got an answer that I shouldn't disable ipv6.

I have no idea what to do. I have some connection problems, I mean sometimes I can't access pages at stack exchange, or google, I have also problems with pastebin.com. In each case there are the same symptoms — after typing an address in my browser, I have to wait sometimes several minutes in order to access the site and after reloading it 2-3 times, I can browse it freely, at least for a certain period of time.

Best Answer

Your IPv6 address starts with fe80: and is therefore a link-local address. Such addresses are only usable on the same link as the network interface. Because the same link-local subnet exists on every network interface you'll have to specify which interface you want to use. For example when you want to ping a link-local address.

Try one of the following ping6 examples. Both do the same:

ping6 fe80::2e0:4cff:fe75:309%eth0
ping6 -I eth0 fe80::2e0:4cff:fe75:309

This also means that only systems on your local link (your LAN) can use this link-local address to connect to your system. Routers won't route those addresses. There is no way that Google or Stack Exchange are sending IPv6 traffic to your machine, because your machine does not have an IPv6 address that is reachable/routable from them.

So, what IPv6 traffic are you seeing on your interface? Probably things like mDNS (multicast DNS) and other protocols that can automatically connect on the local link. For example Apple Airplay and Windows Home Group.

Your firewall rules are missing a very important thing: ICMPv6. IPv6 uses ICMP a lot more than IPv4, and not letting ICMP packets in can severely cripple your traffic because you won't receive error messages related to that traffic. This can cause long delays/timeouts. Allowing ICMPv6 traffic in usually doesn't hurt, so you can add this to your firewall rules:

ip6tables -A INPUT -p icmpv6 -j ACCEPT

If you want to block ping6 packets (although I don't really understand why people still do that these days, it makes debugging connectivity a lot harder) you can add this like before the previous ACCEPT line:

ip6tables -A INPUT -p icmpv6 --icmpv6-type 128 -j DROP

This is mostly important when you get real global IPv6 connectivity to your machine, but it won't hurt if you already prepare for that :-)

Related Solutions

Iptables: Matching Outgoing Traffic with Conntrack and Owner – Troubleshooting Drops

To cut a long story short, that ACK was sent when the socket didn't belong to anybody. Instead of allowing packets that pertain to a socket that belongs to user x, allow packets that pertain to a connection that was initiated by a socket from user x.

The longer story.

To understand the issue, it helps to understand how wget and HTTP requests work in general.

wget http://cachefly.cachefly.net/10mb.test

wget establishes a TCP connection to cachefly.cachefly.net, and once established sends a request in the HTTP protocol that says: "Please send me the content of /10mb.test (GET /10mb.test HTTP/1.1) and by the way, could you please not close the connection after you're done (Connection: Keep-alive). The reason it does that is because in case the server replies with a redirection for a URL on the same IP address, it can reuse the connection.

Now the server can reply with either, "here comes the data you requested, beware it's 10MB large (Content-Length: 10485760), and yes OK, I'll leave the connection open". Or if it doesn't know the size of the data, "Here's the data, sorry I can't leave the connection open but I'll tell when you can stop downloading the data by closing my end of the connection".

In the URL above, we're in the first case.

So, as soon as wget has obtained the headers for the response, it knows its job is done once it has downloaded 10MB of data.

Basically, what wget does is read the data until 10MB have been received and exit. But at that point, there's more to be done. What about the server? It's been told to leave the connection open.

Before exiting, wget closes (close system call) the file descriptor for the socket. Upon, the close, the system finishes acknowledging the data sent by the server and sends a FIN to say: "I won't be sending any more data". At that point close returns and wget exits. There is no socket associated to the TCP connection anymore (at least not one owned by any user). However it's not finished yet. Upon receiving that FIN, the HTTP server sees end-of-file when reading the next request from the client. In HTTP, that means "no more request, I'll close my end". So it sends its FIN as well, to say, "I won't be sending anything either, that connection is going away".

Upon receiving that FIN, the client sends a "ACK". But, at that point, wget is long gone, so that ACK is not from any user. Which is why it is blocked by your firewall. Because the server doesn't receive the ACK, it's going to send the FIN over and over until it gives up and you'll see more dropped ACKs. That also means that by dropping those ACKs, you're needlessly using resources of the server (which needs to maintain a socket in the LAST-ACK state) for quite some time.

The behavior would have been different if the client had not requested "Keep-alive" or the server had not replied with "Keep-alive".

As already mentioned, if you're using the connection tracker, what you want to do is let every packet in the ESTABLISHED and RELATED states through and only worry about NEW packets.

If you allow NEW packets from user x but not packets from user y, then other packets for established connections by user x will go through, and because there can't be established connections by user y (since we're blocking the NEW packets that would establish the connection), there will not be any packet for user y connections going through.

Best Answer

Related Solutions

Iptables: Matching Outgoing Traffic with Conntrack and Owner – Troubleshooting Drops

Related Question