ipv6 traceroutes that don't report next-hops correctly from sit-tunnels fortigate

I will show you why a ipv6 traceroute  across Hurricane Electric ( HE ) or almost any other  ipv6 tunnel will always fail when using a fortigate firewall appliance or perform poorly.

  
It's very sad to say the least & I was shock to say the least when I identified the issue, FTNT flunked big time grade =  F minus !

 
But 1st here's a cisco traceroute  and a sample ipv6 debug output to show what we are expecting in our fortigate ipv6 traceroute

Our tunnel details as provided by HE.net are quite simple and easy to configure.

So first we create a  ipv6 tunnel on  our macosx-laptop using the example cfg that HE provides and conducts a simple  ipv6 traceroute and packet capture so we can see what's missing from our fortigate ipv6 traceroute.

I did this to build comparative data and macosx kernel has great support for ipv6 as most bsd flavored OSes


Here's a sample ipv6 tunnel cfg used in our testing.

BTW the HE tunnelbroker will generate various sample configurations based on  your end-device. HE tunnelbroker by far is one of the simplest broker to use, if not the best.


( x.x.x.x would be you  public facing interface that SRCs the ipv4 tunnel packets )

ifconfig gif0 create
ifconfig gif0 tunnel x.x.x.x 216.66.84.42
ifconfig gif0 inet6 2001:470:1f12:3d::2 2001:470:1f12:3d::1 prefixlen 128
route -n add -inet6 default 2001:470:1f12:3d::1

Yeap it's really that easy ;)

Now I will show why certain ipv6 traceroute will gain a response. It has to do with the protocol used in the traceroute ( ICMP vrs UDP )

A UDP traceroute6 from my macosx shows the following;

A ICMP traceroute6 from my macosx shows the following;

As you can clearly see, both style of traceroutes works for ipv6 ( UDP | ICMPv6 )  & the  HE ipv6 gateways in the route path responds as expected. This is all good and what's expected.

The fortigate defaults with-only using ICMP  with both ipv4 or ipv6 generated traceroutes. You can confirm by executing a diag sniffer packet <interfacename>  "target-destination-address". This is bad if a ipv6 next-hop gateway is set to filter or rate limit ICMPv6 packets.

So I open a ticket with HE just to see what respond they would provide on lack of responses from the traceroute6 requests, and they at first gave me a single one liner response with no other explanation when asked if they filter ICMPv6.

In my 18+ years of using ipv6, most traceroute6 tools/utilities, has the means for toggling UDP and ICMP within the traceroute6 cmd selection upon execution but not a Fortigate.

Here's a snippet of my macosx 10.10 manpage;

But, why does the MACOSX gif tunnel and ipv6-traceroutes using  ICMPv6 or even UDP works? 

and 

Why, a FortiGate ipv6-tracert using ICMPv6 does not respond, but a Cisco, SRX, Linux all works ?    ( That's the million dollar question,   so let's dive in and see why)

So I took a pcap of a traceroute using  a fortigate to see what's the issue could be & immediately seen the issue as to why a ipv6 traceroute over my SIT tunnel interfaces where failing  & until you reached a ttl of 10 or more.

1st, the ipv4 header TTL is mirrored to the IPv6  value hlim ( the name for ttl in ipv6----Next Hop Limit )

See the blue and green circle from this packet dump for comparing the ipv4 ttl value and mapped ipv6 hlim value....they match!

So no way will a ipv6 traceroute ever work,  since the ipv4 packet is dying enroute to the tunnel-server ipv4 gateway  which happens to be 216.66.84.42  { tserv1.par1.he.net  }.


So let's look at this again but from the ipv4 stand point. If I traceroute from the fortigate directly to the ipv4  address where my tunnel terminates, "  how many hops would that take? "  let's find out;

Yeap 11 hops to tserv1.par1.he.net { 216.66.84.42 }

Now let's look at this again, the  ipv6 hlim is mirrored to the outer tunnel ipv4 header ttl value, and the ttl starts at 1 for this outer value.

So the traceoutes that we are conducting via ipv6 utility on a fortigate will never get to the intended target until the outer ipv4 packet get's to our tunnel termination destination.

Here's a ipv6 traceroute to a Japan DNS ipv6-server that will reflect this. We don't get our 1st ipv6 response until we hit  the 11th hop , which so happens to be when the outer ipv4 packet arrives at the HE tunnel-server

btw the above tracert6 was executed on a FGT110C running  4.3.x , I confirmed the same behavior on 5.0.x and have no done any 5.2 stuff yet

So bottomline, your 1st ipv6 response will be determine by how many  hops your away from  the ipv4 tunnel server.


Ken Felix
NSE ( Network Security Expert) and Route/Switching Engineer.
kfelix  -----a----t---- socpuppets ---dot---com

    ^     ^
=(  :    : )=
        o 
       /   \