Hello,
I had been running FortiOS 6.0.1 on a FWF61E utilizing a sit-tunnel to reach the IPv6 Internet by tunneling over existing IPv4. It was configured like the following:
config system sit-tunnel
edit "MyIPv6Tunnel"
set destination 192.0.2.1
set ip6 2001:DB8:1:1::2/64
set interface "wan1"
next
end
IPv6 traffic was successfully tunneling with this configuration applied.
Urgraded 6.0.1 to 6.03 and then noticed was no longer tunneling.
I happened to notice there was no longer any configuration in the system sit-tunnel hierarchy. This is what the configuration showed:
FW1 (vdom1) # config sys sit-tunnel
FW1 (sit-tunnel) # show full
config system sit-tunnel
end
Knowing that I also had a static route configured for this traffic, I checked to make sure that was still there, and it was.
FW1 (vdom1) # config router static6
FW1 (static6) # show
config router static6
edit 1
set device "MyIPv6Tunnel"
next
end
I attempted to re-add the configuration and then noticed that you could not proceed unless you set a source IPv4 address.
FW1 (vdom1) # config sys sit-tunnel
FW1 (sit-tunnel) # edit MyIPV6Tunnel
new entry 'MyIPV6Tunnel' added
FW1 (MyIPv6Tunnel) # set destination 192.0.2.1
FW1 (MyIPv6Tunnel) # set ip6 2001:4DB8:1:1::2/64
FW1 (MyIPv6Tunnel) # next
invalid gateway address!
node_check_object fail! for source 0.0.0.0
Attribute 'source' value '0.0.0.0' checking fail -61
Command fail. Return code 1
So it appears a source IP address is now required for sit-tunnel functionality. This is problematic if you have DHCP configured on the WAN interface.
FW1 (MyIPv6Tunnel) # set source
<class_ip> Class A,B,C ip xxx.xxx.xxx.xxx
It would be nice to be able to specify a source interface instead. Anyway, I set the source IPv4 address of the WAN interface in the tunnel configuration but traffic was still not traversing the tunnel. I confirmed the firewall itself could ping across the tunnel.
FW1 (vdom1) # exe ping6 2001:4DB8:A:1::1
PING 2001:4DB8:A:1::1(2001:4DB8:A:1::1) 56 data bytes
64 bytes from 2001:4DB8:A:1::1: icmp_seq=1 ttl=64 time=8.93 ms
I ran a packet capture on the MyIPv6Tunnel interface and saw IPv6 traffic from devices behind the firewall leaving but not returning. I've confirmed routes are configured correctly and again, this was broke immediately after upgrading to 6.0.3. I experienced this in an upgrade to 5.6.something and then it fixed itself in a patched release.
Any ideas?
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
In case anyone else runs into this issue it appears a bug has been identified where the default static IPv6 route is being ignored. I found that if I added a static route for 2000::/4 that traffic worked as expected.
Apparently the issue with requiring a source IP is because a bug fix was put in to require it. Seems odd since in the 5.4, 5.6, and 6.0.0 versions it worked fine without it.
I used the following routes as a temporary solution which are equivalent to the default route:
0::0/1 - Interface MyIP6Tunnel
8000::0/1 - Interface MyIP6Tunnel
I hope this helps others until Fortinet resolve the issue.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.