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/64address 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.