FortiGate IPv6 using

22 04 2012
My previous IPv6 network was configured with Astaro – recently I have switched vendor to Fortinet (partly troubleshooting, partly cause I could). Using one of their FortiGate FWs – its been “fun” getting all the functions working that I had on the Astaro – one that was a bit more complex was the IPv6 config. It was pretty much point & click GUI driven on the Astaro, its a lot more CLI driven on the FortiGate.
Im using PPPoE without a static IP – so when my IPv4 ISP connection changes address, it will take out my IPv6 Tunnel – I will try to work out how this needs to be fixed later.


First step is to enable IPv6 in the GUI – most of the tunnel config is going to be done on the CLI, but with the GUI enabled, you can at least manage the addresses / policies easily.
config system global
  set gui-ipv6 enable


Configure up the tunnel – if you are using (, there is a shortcut you can take.
View your Tunnel Details on their admin page, make sure you set the correct “Client IPv4 Address” to match your current PPoE or other connection. Then click on the tab called “Example Configurations” which allows you to simply select your OS & it populates the changes needed with the correct IP addresses. In this case, FortiGate 4.x
config system sit-tunnel
    edit “HE”
        set destination
        set ip6 2001:470:66:288::2/64
        set source
config router static6
    edit 1
        set device “HE”
Once you have pasted that into the CLI on the FG, check the tunnel comes up & finish the config

Ping from the Fortigate to the tunnel broker

Fortigate # execute ping6 2001:470:66:288::1
PING 2001:470:66:288::1(2001:470:66:288::1) 56 data bytes
64 bytes from 2001:470:66:288::1: icmp_seq=1 ttl=64 time=159 ms
64 bytes from 2001:470:66:288::1: icmp_seq=2 ttl=64 time=158 ms
64 bytes from 2001:470:66:288::1: icmp_seq=3 ttl=64 time=157 ms
64 bytes from 2001:470:66:288::1: icmp_seq=4 ttl=64 time=158 ms
64 bytes from 2001:470:66:288::1: icmp_seq=5 ttl=64 time=158 ms— 2001:470:66:288::1 ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 4042ms
rtt min/avg/max/mdev = 157.156/158.424/159.138/0.802 msFortigate #


Configure IPv6 on one of your FW interfaces (In this case, my port3(DMZ) interface)
config system interface
     edit port3
            config ipv6
                set ip6-address 2001:470:489e::1/64
                set ip6-allowaccess ping
                set ip6-manage-flag enable
                set ip6-other-flag enable
                    config ip6-prefix-list
                        edit 2001:470:489e::/64
                            set autonomous-flag enable
                            set onlink-flag enable
                            set preferred-life-time 3600
                set ip6-send-adv enable
**NOTE “set ip6-send-adv enable” enables the router auto advertisement on that segment – so any hosts configured with stateless autoconfiguration (most late OS’s) will pickup an address.


Create a FW policy to allow ping traffic to & from your network for testing
config firewall address6
    edit “DMZ_v6”
        set ip6 2001:470:489e::/64
config firewall policy6
    edit 1
        set srcintf port3
        set dstintf HE
            set srcaddr “DMZ_v6”
            set dstaddr “all”
        set action accept
        set schedule “always”
            set service “PING6”
        set logtraffic enable
    edit 2
        set srcintf HE
        set dstintf port3
            set srcaddr “all”
            set dstaddr “DMZ_v6”
        set action accept
        set schedule “always”
            set service “PING6”
        set logtraffic enable


Ping from another host or one of the many test websites


To the Firewall DMZ Interface
PING 2001:470:489e::1: 56 data bytes
64 bytes from 2001:470:489e::1: icmp_seq=0. time=339. ms
64 bytes from 2001:470:489e::1: icmp_seq=1. time=336. ms
64 bytes from 2001:470:489e::1: icmp_seq=2. time=335. ms
64 bytes from 2001:470:489e::1: icmp_seq=3. time=334. ms
64 bytes from 2001:470:489e::1: icmp_seq=4. time=334. ms
—-2001:470:489e::1 PING Statistics—-
5 packets transmitted, 5 packets received, 0% packet loss
round-trip (ms)  min/avg/max/stddev = 334./336./339./2.2


To another host on my DMZ (
PING 56 data bytes
64 bytes from (2001:470:489e::100): icmp_seq=0. time=354. ms
64 bytes from (2001:470:489e::100): icmp_seq=1. time=332. ms
64 bytes from (2001:470:489e::100): icmp_seq=2. time=333. ms
64 bytes from (2001:470:489e::100): icmp_seq=3. time=334. ms
64 bytes from (2001:470:489e::100): icmp_seq=4. time=334. ms
— PING Statistics—-
5 packets transmitted, 5 packets received, 0% packet loss
round-trip (ms)  min/avg/max/stddev = 332./337./354./9.5


From a host on my DMZ out to IPv6 Internet site
Pinging [2001:4860:4001:801::1010] with 32 bytes of data:
Reply from 2001:4860:4001:801::1010: time=160ms
Reply from 2001:4860:4001:801::1010: time=160ms
Reply from 2001:4860:4001:801::1010: time=160ms
Reply from 2001:4860:4001:801::1010: time=159ms
Ping statistics for 2001:4860:4001:801::1010:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 159ms, Maximum = 160ms, Average = 159ms

Configure some FW policies to allow your internal hosts to browse the IPv6 internet (HTTP/HTTPS/PING6/DNS). You can now use the GUI on the FortiGate to configure your new IPv6 FW rules, just remember to use the “IPv6 Policy” menu, not the standard “Policy” page – as that is your IPv4 traffic.


A note on IPv6 DNS & the FortiGate
After some mucking around & frustration, it was clear that the FortiGate was not advertising DNS to stateless autoconfiguration clients. This meant that I had to configure the IPv6 DNS server manually – hardly a great solution (you can use the one from HE).
I found another couple of config items that seems to fix the issue (I added these to my config above)
    set ip6-manage-flag enable
    set ip6-other-flag enable
Documentation from Fortinet on this is not great, so I dont know the full impact of these, but it seems to do what I want, as long as your IPv4 DNS server is the Fortigate.
As you can see, I only have an IPv4 nameserver (The FortiGate), but both IPv4 & IPv6 DNS entries are happily being resolved.
ash@public:~$ dig aaaa
; <<>> DiG 9.7.3 <<>> aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25610
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;               IN      AAAA
;; ANSWER SECTION:        13160   IN      CNAME      273     IN      AAAA    2001:4860:4001:801::1013
;; Query time: 7 msec
;; WHEN: Sun Apr 22 14:59:40 2012
;; MSG SIZE  rcvd: 82
ash@public:~$ cat /etc/resolv.conf
Once you are done, visit somewhere like to check your workstation is using IPv6


Resources Used:
and the usual

IPv6 rebooted – IPv6 SAGE Certification Project (part1)

13 03 2012

IPv6 Certification Badge for blackundertone

Well – its official – I am an IPv6 consumer. I have a public facing IPv6 web & smtp server – and I have passed the requirements of the Hurricane Electric ( IPv6 certification program to the SAGE level –

I already had IPv6 through Freenet6 – as I detailed in my previous IPv6 post here so I began the IPv6 certification program, and ran through the first few basic levels.

  • I can reach the site with IPv6- Check
  • can reach my IPv6 website – Check
  • can send me email (had to stand up postfix for this one) – Check

This got me to the Administrator level – anyone with IPv6 connectivity can easily get here – simply have a reachable IPv6 website & mail server.

This is where the fun came in. To get to the next level (Professional) – I needed a working reverse DNS entry for my mailserver. Now while this sounds simple – freenet6 doesnt appear to provide an easy way to configure reverse DNS entries for the IPv6 range they provide you – bummer.

My Astaro box provides built in support for several tunnel brokers gogo6 Freenet6, Hurricane Electric & SixXS

I had exhausted my energy trying to setup reverse DNS with Freenet6, so off to Hurricane Electric I went – seemed a logical choice considering I was doing their certification anyway. Signup was simple & within minutes I had a new IPv6 allocation. They initially allocate a single /64 – but once you have enabled your connection – you can request a /48 – which of course I did.

So – now that I have a new allocation, here is how I configured it on my network.

In Astro: Interfaces & Routing -> IPv6 (Click Enable) then from the Tunnel Broker tab, simply enter your username & password.

Minutes later, the /64 range on your account page should appear in the global tab.

A couple of tests later & I confirmed I could ping IPv6 addresses from my Astaro box (example here using the nameserver address)

I decided to use the inital /64 I was allocated as the range for my Internal hosts, and then break up the /48 into subnets for other zones.

By far the easiest way to use IPv6 is let the “Stateless Auto Configuration” work its magic. It doesnt require DHCP, allows hosts to automatically find the router & get an address – pretty much works as it says on the box.

Simply add an IPv6 address to the FW interface you want to run IPv6 on, then advertise the subnet out.

Suddenly your internal hosts will be getting IPv6 addresses & will be EXTERNALLY REACHABLE <— This is important. Make sure you setup your firewall rules, host protection etc etc. I will not cover this step, but you need to ensure you understand that as soon as your box has an IPv6 address – it is publically routable from the outside world.

Repeat the addition of an IPv6 address (from another /64 subnet – broken up out of your /48 you requested from to the DMZ interface(s). I am not enabling the “Stateless Auto Configuration” on my DMZ segments, I am just manually assigning addresses to the couple of boxes in there.

Right – that covers the move to Hurricane Electric & how to re-address the internal & DMZ segments.

Next steps are re-addressing my public web & smtp server, updating the DNS forward & reverse zone entries – and what is needed to complete the rest of the certification.