My Journey to IPv6: Part 3 – Outbound Firewall

Three is the magic number

In parts 1 and 2 we discussed IPv6 addressing, and connection basics then configured a Fortigate to grab a DHCPv6 PD prefix and distribute it with SLAAC to clients on the inside network. In this episode I will go over the Fortigate firewall and security policy configuration to get your IPv6 traffic out to the Internet.

The illusion of control

In part 1 I discussed how router advertisements are sent and how they are critical to the operation of an IPv6 network. Those messages are sent using the Internet Control Message Protocol version 6 (ICMPv6) protocol; ICMP being best known as the “ping” protocol in IPv4. Ping was not the only message that ICMPv4 could carry but most of the rest of the message formats were not heavily used in real-world environments. That combined with a security hegemony that promoted blocking ICMP at the network edge resulted in a protocol that could not be relied upon across the public Internet. We all survived.

In version 6, ICMP not only supports similar message types to v4 it also incorporates the functions of other v4 protocols such as ARP (now neighbor discovery protocol, NDP) and IGMP (multicast listener query, MLD). Can you imagine running a successful Ethernet network while blocking ARP? Even more (worse?) than that – There is no packet fragmenting in IPv6. If you send a packet that has to be fragmented the response is to notify the sender of the problem and drop the packet. The notification is an ICMPv6 message.

Long and short – ICMP is not optional in IPv6 and should be available end to end between devices connected to the Internet. Put another way: you should allow ICMPv6 to and from the Internet. If you are particularly paranoid/security minded, you could use the firewall to only allow certain IPv6 messages (such as those fragmentation notifications) through but “the IPv6 way” is that ICMPv6 will work from end to end.

NAT? No! No NAT!

In the IPv6 world firewalls go back to their roots and just become firewalls again. We think of firewalls as router/switch/firewall/NAT all in one devices but it’s easy to remember that NAT was an add on and not ideal. It will be reflexive when setting up inside -> WAN rules to turn on SNAT. The first place we go to setup an inbound rule will be to setup a VIP. Neither of these things are true anymore. Use all public IP’s and subnets in your IPv6 policies and leave NAT off.

Gotta keep ’em seperated

Fortinet has steadily moved IPv6 closer and closer to being a first-class citizen on its devices unlike some other manufacturers (I’m looking at you, Cisco Meraki). As of version 7.2.x you can perform the majority of your familiar IPv4 functions using IPv6 right in the web GUI. That said, v4 and v6 are different protocols not just an extension of each other so many commands and functions have a “6” version in the configuration. When viewing firewall policies, you can view v4 or v6 alone or you can see a combined view with both protocols in a single ruleset. You use the drop down in the upper right to select your protocol version view.

Keep this in mind when you are working with IPv6 in the Fortigate, check all configuration screens and CLI stanzas to see if there is a separate “6” version of that function.

Rules of the road

My basic rules are to allow ICMPv6 inbound and allow outbound Internet access. Using “all” in firewall rules should be avoided where possible but this does present a potential issue. DHCPv6 PD prefixes SHOULD be “permanent” to a subscriber and not change or only change in rare instances. Up until this point, however, we have not had to hard code the PD prefix into any firewall objects. Everything has been a variable saying, “use whatever you get from Verizon on ID 5.” Fortigate doesn’t have an address object construct that dynamically updates if the PD prefix changes. You must create a static IPv6 Address (not Address!) object with your PD prefix included.

I’ve rebooted my equipment several times since I setup IPv6 and my prefix remained stable. My IPv4 on FiOS has been remarkably stable as well so I have decent confidence that I won’t have to be changing this all the time, but you never know. They don’t care, they don’t have to; they’re the phone company.

Then I use that newly created object to create an outbound Internet rule

Notice the little 6 on the “all” destination object. Since v4 and v6 are different protocols, they have different “all” objects. You will get an error if you try to my IPv4 and v6 objects in a single policy. The top section is al you need. Don’t. Enable. NAT.

Use the same subnet object to create an inbound rule allowing ICMPv6 traffic from the Internet to your internal network.

Again, I know allowing all ICMPv6 traffic may make you nervous. You have two options:

• Create custom services matching the ICMPv6 message types you wish to allow or block and craft your rules that way
• If you have the license, use the IPS profiles to check for anomalous ICMPv6 attacks and traffic that might cause you problems.

I went with option 2 as you can see in the screen shot.

Fore!

You now should have end to end Internet browsing capabilities using native IPv6. In the next chapter I’ll discuss inbound connectivity to servers hosted inside your network.