IPv6 Tables

Creating Firewall Rules with ip6tables

Administration Needed

Although the application protocols can vary from system to system, the following are often necessary: SSH (port 22/TCP), the secure remote shell; HTTPS (port 443/TCP), secure web access to potential web administration front ends; and SNMP (port 161/UDP), the Simple Network Management Protocol, which is often required by many monitoring systems.

Assuming that administration of the system is from the inside only, you can narrow down the interface for incoming traffic, thereby offering additional security. Additionally, you can restrict access to the LAN subnet. The bottom line is the following multiport rule:

# Administration
ip6tables -A INPUT -i $LAN_IF -s $LAN_NET -p tcp -m multiport --dport 22,80,443 -j ACCEPT

Depending on the scenario, the firewall acts as a gateway to the outside world as a DNS proxy, or the internal systems use a dedicated DNS server, which can reside on the LAN or even on the Internet. DNS communication can be further limited, if necessary. In this sample scenario, you need to allow DNS traffic both on the firewall (if a DNS server is installed there) and traffic through the firewall to the Internet. Moreover, DNS traffic must be allowed from the firewall to the Internet (Listing 1).

Listing 1

Allowing DNS Traffic

# DNS Traffic
ip6tables -A INPUT -i $LAN_IF -s $LAN_NET -p udp --dport 53 -j ACCEPT
ip6tables -A FORWARD -i $LAN_IF -s $LAN_NET -p udp --dport 53 -j ACCEPT
ip6tables -A OUTPUT -p udp --dport 53 -j ACCEPT

Web and Mail

If you only have internal systems in place that require browser and email client access to the Internet, you can handle the setup with three rules, or a single rule with the multiport option.

However, in the sample scenario, you need to allow access to the server in the DMZ via HTTP, HTTPS, and SMTP. This results in a total of six rules. With the multiport option, you can compress them to two rules (Listing 2).

Listing 2


# Web and Mail off the LAN
ip6tables -A FORWARD -i $LAN_IF -s $LAN_NET -p tcp -m multiport --dport 25,80,443 -j ACCEPT
# Web and mail from the Internet
ip6tables -A FORWARD -i $WAN_IF -s 2000::/3 -d $DMZ_NET -p -m multiport tcp --dport 25,80,443 -j ACCEPT

At this point it would be possible to distinguish the outbound interfaces, if desired. The two rules include two important restrictions courtesy of the respective filters.

First, the sender address is limited to the IANA defined range of global unicast addresses; at the same time, access to the DMZ network is made conditional for letting the traffic pass. This means, conversely, that traffic from the outside to the internal systems is not allowed. If more applications are needed, the principle is always the same as shown.


IPv6 adds various new forms of communication that you should consider in your firewall rules, including, in particular, ICMPv6 with and without auto-configuration and path MTU (PMTU) discovery.

ICMPv6 is an integral part of IPv6 and thus obligatory – in contrast to IPv4, in which ICMP(v4) is optional. ICMPv6 implements various fundamental communication processes in IPv6: neighbor discovery (ICMPv6 types 135 and 136), router discovery (ICMPv6 types 133 and 134), and PMTU discovery (ICMPv6 type 2). Neighbor discovery and router discovery are only of interest for the INPUT and OUTPUT chains, but other ICMPv6 types must be allowed in the FORWARD chain for smooth operation.

In particular, type 2 (Packet Too Big) is necessary for the PMTU discovery process. It involves the sender determining the smallest MTU en route to the destination and matching the IPv6 packets to this size. This step is essential because, in IPv6, routers no longer fragment packets – only the sender.

To determine the PMTU, packets are sent at the maximum size (e.g., 1500 bytes in Ethernet). If a router in the path to the target system determines that the packet is too large for the next segment of the route, it discards it and returns an ICMPv6 type 2 (Packet Too Big) to the sender. This message contains the value for the MTU that was exceeded. The sender then adjusts the packet size accordingly. If this feedback is blocked, communication with specific systems may be impossible because the sender does not know that its packet was discarded.

More ICMPv6 types that are mostly desirable and should not be blocked relate to problem reports: type 1 (Destination Unreachable), type 3 (Time Exceeded), and type 4 (Parameter Problem).

At least from the Internet, these ICMPv6 types should be allowed. Some types that exchange information also are often desirable: multicast listener discovery (130, 131, 132, INPUT, and OUTPUT) and ping (128 and 129, INPUT, OUTPUT, and FORWARD).

If you prefer to avoid giving the ICMPv6 protocol general power of attorney in allowing access, you have no alternative but to define detailed rules, as shown in Listing 3.

Listing 3

Rules for ICMPv6

# Feedback for problems
ip6tables -A INPUT -p icmpv6 --icmpv6-type 1 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 2 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 3 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 4 -j ACCEPT
ip6tables -A FORWARD -i $WAN_IF -p icmpv6 --icmpv6-type 1 -j ACCEPT
ip6tables -A FORWARD -i $WAN_IF -p icmpv6 --icmpv6-type 2 -j ACCEPT
ip6tables -A FORWARD -i $WAN_IF -p icmpv6 --icmpv6-type 3 -j ACCEPT
ip6tables -A FORWARD -i $WAN_IF -p icmpv6 --icmpv6-type 4 -j ACCEPT
# Router and neighbor discovery incoming and outgoing
ip6tables -A INPUT -p icmpv6 --icmpv6-type 133 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 134 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 135 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 136 -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 133 -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 134 -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 135 -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 136 -j ACCEPT
# Ping request to firewall from LAN and DMZ
ip6tables -A INPUT ! -i $WAN_IF -p icmpv6 --icmpv6-type 128 -j ACCEPT
# Ping request from firewall, LAN and DMZ
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type 128 -j ACCEPT
ip6tables -A FORWARD ! -i $WAN_IF -p icmpv6 --icmpv6-type 128 -j ACCEPT

If multicast connections are required, you also need to consider the matching ICMPv6 types. This works like the rules in Listing 3.

To determine whether other ICMPv6 types are desirable or necessary in your production environment, detailed analysis of the respective infrastructure is necessary.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

comments powered by Disqus
Subscribe to our ADMIN Newsletters
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs

Support Our Work

ADMIN content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.