1

Trying to get the basic firewall setup for IPv6 using ip6tables (this is on Ubuntu server 16.04). On the INPUT chain, whenever there is client-initiated IPv6 traffic (e.g. running 'apt update'), I get tons of packets from what I assume to be the gateway: from same network address as my IP address but ends in ::1 [64 bits of 0's ending in a 1]). If I drop this traffic, things run slow (e.g. 'apt update' takes quite a while to (successfully) complete). If I let these packets in, things are normal.

The problem is that I have read quite a bit on configuring ip6tables but nothing I have read so far mentions anything about this incoming 'gateway' traffic that isn't part of --ctstate ESTABLISHED,RELATED.

Also during this back and forth, I get some packets from the link-local address (fe08::1) destined to my actual public IP address. These are also being dropped as per my rules.

Here are my IPv6 rules:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED
-A INPUT -j LOG --log-prefix "IPv6-DROP="
-A INPUT -j DROP
-A FORWARD -j DROP
COMMIT

Very basic initial setup. If IPv6 configuration is supposed to ACCEPT incoming from NETWORK-ADDRESS::1 and from fe08::1, why don't the tutorial sites and examples point this out? I only get barraged with these packets when I request something (e.g. 'apt update'). So, shouldn't they be included in the ctstate RELATED,ESTABLISHED? or the lo?

  • Who knows? What is the traffic that you received? – Michael Hampton Apr 20 '18 at 02:24
  • I have no idea. I suppose I can inspect the packets and see. But I'm mainly interested in learning if it is normal behavior to receive traffic from link local and the gateway on IPv6 during a request which is not considered ESTABLISHED or RELATED. This all seems very strange to me that ipv6 examples don't show allowing packets on the INPUT chain from lo and the gateway if this is the case. – Vic Morrowshead Apr 20 '18 at 02:37
  • 2
    You really should look at the traffic and see what it is. It could be normal traffic, but without actually looking, nobody can do anything but make wild guesses. And we're professionals and don't like wild guesses. – Michael Hampton Apr 20 '18 at 02:44
  • 2
    IPv4 relies on ARP to do layer2-layer3 resolution. iptables doesn't know nor filter ARP. IPv6 uses... IPv6 (ICMPv6) (!) to do layer2-layer3 resolution. ip6tables *will* filter those packets if no provision is made for them. SO you really should check about differences between IPv4 and IPv6 in documentation and RFCs, especially about the meaning of the different scopes (interface,link,site,global...). You can't do a minimal "drop all but one thing" with IPv6 / ip6tables like it was possible with IPv4 / iptables. – A.B Apr 20 '18 at 06:02
  • @A.B - you nailed it with the ICMPv6 point. Enabling ICMPv6 made things work as expected and no more dropped packets. I did not know that those dropped packets were ICMP packets. – Vic Morrowshead Apr 20 '18 at 19:15
  • 1
    @A.B As wild guesses go, that's a very good one. ICMPv6, or at least some ICMPv6 types, absolutely needs to be allowed. See [RFC 4890](https://tools.ietf.org/html/rfc4890) for specifics. – Michael Hampton Apr 20 '18 at 20:42

1 Answers1

1

If IPv6 configuration is supposed to ACCEPT incoming from NETWORK-ADDRESS::1 and from fe08::1, why don't the tutorial sites and examples point this out?

As you guessed, fe80::1 is the address of the default gateway. I presume the tutorials don't point out that you shouldn't block traffic from the default gateway because it is so obvious.

Johan Myréen
  • 441
  • 3
  • 6
  • `fe80::1` is not necessarily a gateway address. IPv6 makes the zero (network) address, e.g. `fe80::` the router anycast address, so you should be able to hit a gateway with the network address. – Ron Maupin Apr 21 '18 at 00:55