![]()
I got an email where someone asked whether I know how to change the link-local IPv6 addresses on a FortiGate similar to any other network/firewall devices. He could not find anything about this on the Fortinet documentation nor on Google.
Well, I could not find anything either. What’s up? It’s not new to me that you cannot really configure IPv6 on the FortiGate GUI, but even on the CLI I couldn’t find anything about changing this link-local IPv6 address from the default EUI-64 based one to a manually assigned one. Hence I opened a ticket at Fortinet. It turned out that you cannot *change* this address at all, but that you must *add* another LL address which will be used for the router advertisements (RA) after a reboot (!) of the firewall. Stupid design!
Again and again and again I am not happy at all with the IPv6 implementation on the FortiGates. Too many bugs and features missing, while everything is too complicated to configure. (Have a look at my Fortinet feature requests.) For the following tests I used a FortiGate FG-90D with firmware v5.6.5 build1600 (GA).
Before (Default Behaviour)
Before I touched the config the state of IPv6 was the following. Have a look at the “fg-trust” interface with its link-local address in line 12:
fg # diagnose ipv6 address list
dev=31 devname=vsys_fgfm flag=P scope=254 prefix=128 addr=::1
dev=29 devname=vsys_ha flag=P scope=254 prefix=128 addr=::1
dev=28 devname=fg-server flag=P scope=0 prefix=64 addr=2003:de:2016:220::1
dev=27 devname=fg-trust2 flag=P scope=0 prefix=64 addr=2003:de:2016:211::1
dev=26 devname=fg-trust flag=P scope=0 prefix=64 addr=2003:de:2016:210::1
dev=24 devname=root flag=P scope=254 prefix=128 addr=::1
dev=5 devname=wan1 flag=P scope=0 prefix=64 addr=2003:de:2016::2
dev=6 devname=wan2 flag=P scope=253 prefix=10 addr=fe80::a5b:eff:fea1:8360
dev=28 devname=fg-server flag=P scope=253 prefix=10 addr=fe80::a5b:eff:fea1:835e
dev=27 devname=fg-trust2 flag=P scope=253 prefix=10 addr=fe80::a5b:eff:fea1:835e
dev=26 devname=fg-trust flag=P scope=253 prefix=10 addr=fe80::a5b:eff:fea1:835e
dev=5 devname=wan1 flag=P scope=253 prefix=10 addr=fe80::a5b:eff:fea1:835f
The configuration at this point was:
config system interface
edit "fg-trust"
set vdom "root"
set ip 192.168.210.1 255.255.255.0
set allowaccess ping https ssh
set role lan
set snmp-index 5
config ipv6
set ip6-address 2003:de:2016:210::1/64
set ip6-allowaccess ping https ssh
set ip6-send-adv enable
config ip6-prefix-list
edit 2003:de:2016:210::/64
set autonomous-flag enable
set onlink-flag enable
next
end
end
set interface "internal1"
set vlanid 210
next
end
And a Linux machine got the following routing table, in which the default route had a gateway of
fe80::a5b:eff:fea1:835e
:
weberjoh@jw-vm05-Ubuntu-Test-3:~$ ip -6 r s
2003:de:2016:210::/64 dev ens32 proto kernel metric 256 expires 2591699sec pref medium
fe80::/64 dev ens32 proto kernel metric 256 pref medium
default via fe80::a5b:eff:fea1:835e dev ens32 proto ra metric 1024 expires 1499sec pref medium
Configuration of the Link-Local Address
To add a link-local address you need the “config ip6-extra-addr” submenu. I added the quite simple
fe80::1/64
address to that interface, that is:
config system interface
edit fg-trust
config ipv6
config ip6-extra-addr
edit fe80::1/64
next
end
end
end
Now, in order to have the router advertisements sent from this newly created link-local address, you have to reboot the firewall! Come on Fortinet, you need a complete reboot for this?!? (Note that the support ticket told me to disable the “ip6-send-adv” before adding the LL address, and enabling it again after that. But this was not successful. At this point the RAs were still sent from the old EUI-64 based LL address.) Hence a reboot:
execute reboot
After
After this changes and the reboot the added link-local IPv6 was present (line 6):
fg # diagnose ipv6 address list
dev=31 devname=vsys_fgfm flag=P scope=254 prefix=128 addr=::1
dev=29 devname=vsys_ha flag=P scope=254 prefix=128 addr=::1
dev=28 devname=fg-server flag=P scope=0 prefix=64 addr=2003:de:2016:220::1
dev=27 devname=fg-trust2 flag=P scope=0 prefix=64 addr=2003:de:2016:211::1
dev=26 devname=fg-trust flag=SP scope=253 prefix=64 addr=fe80::1
dev=26 devname=fg-trust flag=P scope=0 prefix=64 addr=2003:de:2016:210::1
dev=24 devname=root flag=P scope=254 prefix=128 addr=::1
dev=5 devname=wan1 flag=P scope=0 prefix=64 addr=2003:de:2016::2
dev=6 devname=wan2 flag=P scope=253 prefix=10 addr=fe80::a5b:eff:fea1:8360
dev=28 devname=fg-server flag=P scope=253 prefix=10 addr=fe80::a5b:eff:fea1:835e
dev=27 devname=fg-trust2 flag=P scope=253 prefix=10 addr=fe80::a5b:eff:fea1:835e
dev=26 devname=fg-trust flag=P scope=253 prefix=10 addr=fe80::a5b:eff:fea1:835e
dev=5 devname=wan1 flag=P scope=253 prefix=10 addr=fe80::a5b:eff:fea1:835f
The complete configuration section for this interface looked like this:
config system interface
edit "fg-trust"
set vdom "root"
set ip 192.168.210.1 255.255.255.0
set allowaccess ping https ssh
set role lan
set snmp-index 5
config ipv6
set ip6-address 2003:de:2016:210::1/64
set ip6-allowaccess ping https ssh
config ip6-extra-addr
edit fe80::1/64
next
end
set ip6-send-adv enable
config ip6-prefix-list
edit 2003:de:2016:210::/64
set autonomous-flag enable
set onlink-flag enable
next
end
end
set interface "internal1"
set vlanid 210
next
end
And the Linux machine (after a reboot as well) got the correct next hop for its default route:
weberjoh@jw-vm05-Ubuntu-Test-3:~$ ip -6 r s
2003:de:2016:210::/64 dev ens32 proto kernel metric 256 expires 2591853sec pref medium
fe80::/64 dev ens32 proto kernel metric 256 pref medium
default via fe80::1 dev ens32 proto ra metric 1024 expires 1653sec pref medium
Accordingly I could verify that the router advertisements were sent from my added link-local address
fe80::1
:
![]()
Competitors
That’s it. I am not happy with this approach from Fortinet in “changing” the link-local address. On other firewalls such as the Palo Alto Networks firewall you can clearly change the behaviour of the interface ID portion, and it even works without rebooting the firewall:
![]()
![]()
Cheers.
Featured image “Buy Local” by Mariano Mantel is licensed under CC BY-NC 2.0.
Since PAN-OS version 6.1 the Palo Alto Networks firewall supports LACP, the Link Aggregation Control Protocol which bundles physical links to a logical channel. Palo Alto calls it “Aggregate Interface Group” while Cisco calls it EtherChannel or Channel Group. I configured LACP for two ports connected from a Palo Alto firewall to a Cisco switch. … Continue reading Palo Alto Aggregate Interface w/ LACP
I want to talk about a fun fact concerning my blog statistics: Since a few years I have some “CLI troubleshooting commands” posts on my blog – one for the Palo Alto Networks firewall and another for the FortiGate firewall from Fortinet. If you are searching on Google for something like “palo alto cli commands” … 
Haha, do you like acronyms as much as I do? This article is about the feature from Palo Alto Networks’ Next-Generation Firewall for Internet Protocol version 6 Neighbor Discovery Protocol Router Advertisements with Recursive Domain Name System Server and Domain Name System Search List options. ;) I am showing how to use it and how … 
With PAN-OS version 8.0 Palo Alto Networks introduced another IPv6 feature, namely “NDP Monitoring for Fast Device Location“. It basically adds a few information to the existing neighbor cache such as the User-ID (if present) and a “last reported” timestamp. That is: the admin has a new reporting window within the Palo Alto GUI that … 
Towards the global IPv6-only strategy ;) VPN tunnels will be used over IPv6, too. I configured a static IPsec site-to-site VPN between a Palo Alto Networks and a Fortinet FortiGate firewall via IPv6 only. I am using it for tunneling both Internet Protocols: IPv6 and legacy IP. While it was quite easy to bring the … 
And one more IPsec VPN post, again between the Palo Alto Networks firewall and a Fortinet FortiGate, again over IPv6 but this time with IKEv2. It was no problem at all to change from IKEv1 to IKEv2 for this already configured VPN connection between the two different firewall vendors. Hence I am only showing the … 
Until now I generated all SSHFP resource records on the SSH destination server itself via [crayon-5a87bab4cb5b0474928525-i/]. This is quite easy when you already have an SSH connection to a standard Linux system. But when connecting to third party products such as routers, firewalls, whatever appliances, you don’t have this option. Hence I searched and found … 
While I tested the FQDN objects with a Palo Alto Networks firewall, I ran into some strange behaviours which I could not reproduce, but have documented them. I furthermore tested the usage of FQDN objects with more than 32 IP addresses, which are the maximum that are supported due to the official Palo Alto documentation. … 
I am using the DNS Proxy on a Palo Alto Networks firewall for some user subnets. Beside the default/primary DNS server it can be configured with proxy rules (sometimes called conditional forwarding) which I am using for reverse DNS lookups, i.e., PTR records, that are answered by a BIND DNS server. While it is easy … 
I am using an almost hidden FTP server in my DMZ behind a Palo Alto Networks firewall. FTP is only allowed from a few static IP addresses, hence no brute-force attacks on my server. Furthermore, I have an “allow ping and traceroute from any to DMZ” policy since ping is no security flaw but really … 
Just a quick note concerning the session sync on a Palo Alto Networks firewall cluster: Don’t trust the green HA2 bubble on the HA widget since it is always “Up” as long as the HA interface is up. It does NOT indicate whether the session sync is working or not. You MUST verify the session … 
I came across some strange behaviors on a Palo Alto Networks firewall: Certain TLS connections with TLS inspection enabled did not work. Looking at the traffic log the connections revealed an Action of “allow” but of Type “deny” with Session End Reason of “policy-deny”. What? During troubleshooting I found the following facts. (Capturing on a … 
We needed to configure the Internet-facing firewall for a customer to block encrypted files such as protected PDF, ZIP, or Microsoft Office documents. We tested it with two next-generation firewalls, namely Fortinet FortiGate and Palo Alto Networks. The experiences were quite different… Note that the Internet connection must be either unencrypted itself, i.e., HTTP or … 
There are two methods of site-to-site VPN tunnels: route-based and policy-based. While some of you may already be familiar with this, some may have never heard of it. Some firewalls only implement one of these types, so you probably don’t have a chance to configure the other one anyway. Too bad since route-based VPNs have … 
While playing around in my lab learning BGP I configured iBGP with Multiprotocol Extensions (exchanging routing information for IPv6 and legacy IP) between two Cisco routers, a Palo Alto Networks firewall, and a Fortinet FortiGate firewall. Following are all configuration steps from their GUI (Palo) as well as their CLIs (Cisco, Fortinet). It’s just a … 
For those who are interested in analyzing basic BGP messages: I have a trace file for you. ;) It consists of two session establishments as I cleared the complete BGP session on two involved routers for it. Refer to my previous blogpost for details about the lab, that is: MP-BGP with IPv6 and legacy IP, … 
to about 
. Here is how it works on the Palo Alto Networks firewall:
to 
.
