Need IPv6 help

echo · ‎04-19-2016

Hello!

After realising that SLAAC is not supposed to work when ISP gives just a /64 with which I should subnet this into smaller (because I have to define globally routable IPv6 addresses non-overlappingly on both external and internal interfaces), I asked our ISP for a /48 and got it (unlike last time over a year ago). But I still can't get IPv6 working (without NAT). I write down the configuration. It is FG200D with a single internet connection in wan1 port and vlan14 is our test internal vlan for IPv6 which also has IPv4 addressing on it. I use 2001:db:1:: prefix for example conf (replacing the original with it) but prefix lengths are not altered. My main goal at the moment is to get access to IPv6 internet from internal network. Allowing access from internet to internal network will be my next step.

If anybody has ideas, thank you in advance!

1. External interface wan1 (IPv6 part of it).

config ipv6 set ip6-allowaccess ping set ip6-address 2001:db8:1::2/64 end

2. Routing.

config router static6 edit 1 set gateway 2001:db8:1::1 set device "wan1" next end

3. Test ping (excerpt) to IPv6 internet.

exec ping6 -I wan1 ipv6.google.com 64 bytes from 2a00:1450:4010:c07::8b: icmp_seq=1 ttl=54 time=62.8 ms 4. Internal interface vlan14 (IPv6 part of it). Since I wanted just SLAAC to work first, I have "unset ip6-manage-flag" for test but it didn't make any difference. I understood from examples that manage-flag should be used when DHCPv6 is also defined in the router so I have tried with or without it but didn't make any difference.

config ipv6 set ip6-allowaccess ping capwap set ip6-address 2001:db8:1:14::1/64 set ip6-send-adv enable set ip6-manage-flag enable set ip6-other-flag enable config ip6-prefix-list edit 2001:db8:1:14::/64 set autonomous-flag enable set onlink-flag enable next end end

5. With this, autoconf enabled devices in vlan14 really get the SLAAC addresses and they ping each other.

6. Policy6 between zones "cloud" with vlan14 and "untrust" (wihtout UUID's), that is from internal network to internet. It gets hits and there is traffic counting up when I try to initiate even pings to IPv6 internet.

config firewall address6 edit "ipv6-vlan14" set ip6 2001:db8:1:14::/64 next end

edit 1 set name "20160419" set srcintf "cloud" set dstintf "untrust" set srcaddr "ipv6-vlan14" set dstaddr "all" set action accept set schedule "always" set service "ALL" set logtraffic all next

7. Diagnostics.

7.1 I pinged Google's nameserver from an HP switch and Win2012 server.

diag sniffer packet vlan14 'icmp6' 4 10

interfaces=[vlan14] filters=[icmp6] 12.385066 vlan14 -- fe80::a5b:eff:fea0:b849 -> ff02::1: icmp6: router advertisement 24.687527 vlan14 -- 2001:db8:1:14:7646:a0ff:fee1:ec00 -> 2001:db8:1::1: icmp6: echo request seq 41 29.700829 vlan14 -- fe80::7646:a0ff:fee1:ec00 -> fe80::a5b:eff:fea0:b849: icmp6: neighbor sol: who has fe80::a5b:eff:fea0:b849 29.700842 vlan14 -- fe80::a5b:eff:fea0:b849 -> fe80::7646:a0ff:fee1:ec00: icmp6: neighbor adv: tgt is fe80::a5b:eff:fea0:b849 60.114931 vlan14 -- 2001:db8:1:14::2 -> ff02::1:ff00:1: icmp6: neighbor sol: who has 2001:db8:1:14::1 60.114962 vlan14 -- 2001:db8:1:14::1 -> 2001:db8:1:14::2: icmp6: neighbor adv: tgt is 2001:db8:1:14::1 60.115274 vlan14 -- 2001:db8:1:14::2 -> 2001:4860:4860::8888: icmp6: echo request seq 204 64.784896 vlan14 -- 2001:db8:1:14::2 -> 2001:4860:4860::8888: icmp6: echo request seq 205 69.785059 vlan14 -- 2001:db8:1:14::2 -> 2001:4860:4860::8888: icmp6: echo request seq 206 213.764101 vlan14 -- 2001:db8:1:14:8587:8aff:85ab:3535 -> ff02::1:ffa0:b849: icmp6: neighbor sol: who has fe80::a5b:eff:fea0:b849

Here are the participants:

fe80::a5b:eff:fea0:b849 -- Fortigate's LL address. Somehow this gets advertised all the time.

2001:db8:1:14::1 -- Fortigate's manually set address in vlan14.

fe80::7646:a0ff:fee1:ec00 -- HP switch with LL address.

2001:db8:1:14:7646:a0ff:fee1:ec00 -- HP switch with SLAAC address in vlan14.

2001:db8:1:14::2 -- Win2012 that had a manually set IPv6 address for a test.

2001:db8:1:14:8587:8aff:85ab:3535 -- Win2012 with SLAAC address.

2001:db8:1::1 -- ISP's default gateway.

7.2 HP switch information.

---------

show running-config (excerpt):

vlan 14 name "DMZ14" tagged 1-2 no ip address ipv6 enable ipv6 address autoconfig exit

---------

----------

HP-2530-48G-1# sho ipv6 vlan 14 Internet (IPv6) Service IPv6 Routing : Disabled Default Gateway : fe80::a5b:eff:fea0:b849%vlan14 ND DAD : Enabled DAD Attempts : 3 Interface Name : DMZ14 IPv6 Status : Enabled Layer 3 Status : Enabled IPv6 Address/Prefixlength Expiry ------------------------------------------- ------------------------- 2001:db8:1:14:7646:a0ff:fee1:ec00/64 Sat Jul 11 21:14:41 1992 fe80::7646:a0ff:fee1:ec00/64 permanent

----------

HP-2530-48G-1# sho ipv6 routers IPv6 Router Table Entries Router Address : fe80::a5b:eff:fea0:b849 Interface : DMZ14 MTU : 1500 Hop Limit : 64 Valid Preferred On/Off Prefix Advertised Lifetime(s) Lifetime(s) Link ------------------------------------------- ----------- ----------- ------- 1::/64 2592000 604800 Onlink 2001:db8:0:1::1:0/112 2592000 86400 Onlink 2001:db8:1:14::/64 2592000 604800 Onlink dead:beef:cafe::/64 86400 43200 Onlink ----------

Here 2001:db8:0:1::1:0/112 is one of my earlier attempts to get the whole thing working with smaller than /64 subnets (worked only with NAT enabled from internal IPv6 to external IPv6).

dead:beef:cafe::/64 is another earlier attempt and I got this working with /64 (without being part of some /48) when I had 2001:db8:0:1::2/112 on wan1 interface _with_ NAT enabled from cloud to untrust. I don't know how to delete these entries, maybe it is not necessary anyway.

---------

HP-2530-48G-1# sho ipv6 route IPv6 Route Entries T (Type): S: Static C: Connected Destination/ Gateway T ST Distance Metric ------------------------------------------------ --- --- ---------- ---------- ::/0 fe80::a5b:eff:fea0:b849%vlan14 S NA 254 0 ::1/128 lo0 C NA 0 1 2001:db8:1:14::/64 VLAN14 (DMZ14) C NA 0 1 fe80::%vlan14 VLAN14 (DMZ14) C NA 0 1

---------

7.2 Win2012 server.

C:\Windows\system32>route print =========================================================================== Interface List 12...00 50 56 8a 61 59 ......vmxnet3 Ethernet Adapter 1...........................Software Loopback Interface 1 =========================================================================== IPv4 Route Table =========================================================================== /// Omitted /// =========================================================================== IPv6 Route Table =========================================================================== Active Routes: If Metric Network Destination Gateway 12 261 ::/0 fe80::a5b:eff:fea0:b849 1 306 ::1/128 On-link 12 261 2001:db8:1:14::/64 On-link 12 261 2001:db8:1:14:8587:8aff:85ab:3535/128 On-link 12 261 fe80::/64 On-link 12 261 fe80::8587:8aff:85ab:3535/128 On-link 1 306 ff00::/8 On-link 12 261 ff00::/8 On-link =========================================================================== Persistent Routes: None

From Win2012, I can ping for example the Fortigate's 2001:db8:1:14::1 address (vlan14), Fortigate's 2001:db8:1::2 address (wan1), but not ISP's 2001:db8:1::1 address, although it pings from wan1 from the router. And I can't ping anything other in IPv6 internet too.

emnoc · ‎04-19-2016

Okay here's what I would do. I'm betting your /64 are not reachable & your ISP has issues.

Goto a ipv6 looking glass router ( I like NTT btw ) and traceroute to one of you /64 address hosts. ( do you see that traceroute inbound)

2nd if yes, than plumb a loop interface with a /64 network enabled and with a fwpolicy6 wan1 inbound to that /64 address , ensure set allowacces ping has been enabled. Now can you ping that /64 address on the loopback ? and from the ipv6 looking glass?

config sys interface

edit loop6

set vdom root

config ipv6

set ip6-allowaccess ping set ip6-address 2001:db8:11::1/64 end

3rd do you see session6 entry in the firewall session table ( or diag debug flow if you like diag debug flow )

These steps will ensure that 1> the /64s are reachable via your ISP and FGT, and allow you to focus on the internal-inside and narrow the area of the troubleshooting. If you can ping that /64 on the loopback than your problem(s) are local to your FGT. If not they are external to the FGT.

I must have turned up at least 70 ipv6 networks in the last 2-3 years and always did the above when isolation with SRX or FGTs.

PCNSE

NSE

StrongSwan

View solution in original post

emnoc · ‎04-19-2016

Wow

A very good details collection for t-shooting. Others should catch your method of data collection, actually I wish my day job staff would do like you with 90% of the stuff give me ;)

1st can you ping from the "FGT inside sourced ipv6" address to goog ipv6 DNS servers or the ISP gateway?

2nd, in the rtr advt to the windows and/hp are you 100% sure the default routes is present? From your output it looks like no

3rd, in the diag debug flow filter6 can you execute the diag debug flow using "6" to get and ideal if your matching any policy?

e.g

diag debug reset

diag debug enable

diag debug flow filter6 addr <ipv6 addres here >

diag debug flow show console enable

diag debug flow trace start6 100

If your not matching any fwpolicy6, it's probably due to lack of forward routes lookup.

This might shed some help on fgt ipv6

http://socpuppet.blogspot...6-fortigate-style.html

PCNSE

NSE

StrongSwan

echo · ‎04-19-2016

Thanks for quick response :) Answers to questions:

1. No, it doesn't work.

$ exec ping6-options source 2001:db8:1:14::1 $ exec ping6 2001:4860:4860::8888 PING 2001:4860:4860::8888(2001:4860:4860::8888) from 2001:db8:1:14::1 : 56 data bytes --- 2001:4860:4860::8888 ping statistics --- 5 packets transmitted, 0 packets received, 100% packet loss, time 7996ms

I'm not sure if it is related, but it has never worked with IPv4 as well when I set the source IP-address the internal IPv4 address of the router (behind the NAT) and ping something outside. Maybe it is different for IPv6 though (maybe it must work).

But setting the wan1 interface IPv6 address for source, ping works.

2. True, that was my question too that why are there only Fortigate's LL addresses visible as routers in both cases and not the one in advertised global network. This can be the reason why my stuff actually doesn't work. If SLAAC works already, then how come the router's address itself is not advertised?

3. Yes, policy matches as I've seen before.

id=20085 trace_id=1 func=resolve_ip6_tuple_fast line=3251 msg="vd-root received a packet(proto=17, 2001:db8:1:14:8587:8aff:85ab:3535:58028->2001:4860:4860::8888:53) from vlan14." id=20085 trace_id=1 func=resolve_ip6_tuple line=3352 msg="allocate a new session-006d0549" id=20085 trace_id=1 func=vf_ip6_route_input line=535 msg="find a route: gw-2001:db8:1::1 via wan1 err 0 flags 00000003" id=20085 trace_id=1 func=fw6_forward_handler line=311 msg="Check policy between vlan14 -> wan1" id=20085 trace_id=1 func=fw6_forward_handler line=435 msg="Allowed by Policy-1:"

4. For the link to the blog post, you use 2001:11::1/64 as for internal part. But what address have you configured for external interface and what is the whole allocated (possibly /48) network from ISP in that example case? Could it be eg 2001:11:0:1::2/64 assuming you are given 2001:11::/48, and the default route being 2001:11:0:1::1? Also, are there any additional parameters in external interface? Mine has just IP-address and allowing ping.

emnoc · ‎04-19-2016

Okay here's what I would do. I'm betting your /64 are not reachable & your ISP has issues.

Goto a ipv6 looking glass router ( I like NTT btw ) and traceroute to one of you /64 address hosts. ( do you see that traceroute inbound)

2nd if yes, than plumb a loop interface with a /64 network enabled and with a fwpolicy6 wan1 inbound to that /64 address , ensure set allowacces ping has been enabled. Now can you ping that /64 address on the loopback ? and from the ipv6 looking glass?

config sys interface

edit loop6

set vdom root

config ipv6

set ip6-allowaccess ping set ip6-address 2001:db8:11::1/64 end

3rd do you see session6 entry in the firewall session table ( or diag debug flow if you like diag debug flow )

These steps will ensure that 1> the /64s are reachable via your ISP and FGT, and allow you to focus on the internal-inside and narrow the area of the troubleshooting. If you can ping that /64 on the loopback than your problem(s) are local to your FGT. If not they are external to the FGT.

I must have turned up at least 70 ipv6 networks in the last 2-3 years and always did the above when isolation with SRX or FGTs.

PCNSE

NSE

StrongSwan

echo · ‎04-20-2016

Good idea to test reachability from other sources. I didn't think about this at all because I can successfully ping external addresses from wan1 and also tracert6 works to outside direction.

I did traces. We got another bigger allocation than /64 from another ISP to another FGT and that one also doesn't work (it's a /57 that they gave) with a principally same config; with NAT, it works. I traced routers' addresses from NTT LG and from each other. Strange was that from both IPv6 routers, the other one's wan1 interface address was traceable, I could even open one router's https page over IPv6 when I allowed it so it wasn't that just icmp6 worked. But when tracing internal interface addresses, like 2001:db8:1:14::1, from the other router and also NTT LG, it didn' work -- I even created a special policy to allow such traffic (untrust to cloud) and even when tracing something else in that "internal" network from outside, the destination was shown unreachable.

Example of one trace:

 1 2001:5012:100:2::1 0 msec 0 msec 0 msec
 2 ae4-xcr1.six.cw.net (2001:5000:0:1a1::2) 0 msec 0 msec 0 msec
 3 2001:5012:100:7::2 0 msec 0 msec 1 msec
 4 bbr1.tln2.ee.v6.eunetip.net (2001:670:3:4:1::7) 6 msec
 bbr1.tln1.ee.v6.eunetip.net (2001:670:3:4:1::6) 7 msec
 bbr1.tln2.ee.v6.eunetip.net (2001:670:3:4:1::7) 6 msec
 5 2001:670:3:22::2 6 msec
 2001:670:3:21::2 8 msec 7 msec
 6 2001:1530:0:5::2 8 msec 7 msec
 2001:1530:0:6::2 7 msec
 7 2001:1530:b0:1::2 7 msec 7 msec * 
 8 2001:1530:b0:1::2 !H !H *

Second attempt:

 1 2001:5012:100:2::1 0 msec 1 msec 0 msec
 2 ae4-xcr1.six.cw.net (2001:5000:0:1a1::2) 0 msec 0 msec 0 msec
 3 2001:5012:100:7::2 0 msec 0 msec 0 msec
 4 bbr1.tln2.ee.v6.eunetip.net (2001:670:3:4:1::7) 6 msec 6 msec 6 msec
 5 2001:670:3:22::2 7 msec 6 msec 6 msec
 6 2001:1530:0:6::2 7 msec
 2001:1530:0:5::2 8 msec
 2001:1530:0:6::2 7 msec
 7 * 
 2001:1530:b0:1::2 8 msec * 
 8 * 7 msec 29 msec
 9 * * * 
 10 * !H *

From another farther source the end looks similar:

 14 2001:670:3:22::2 70 msec
 2001:670:3:21::2 70 msec
 2001:670:3:22::2 70 msec
 15 2001:1530:0:6::2 66 msec 66 msec
 2001:1530:0:5::2 73 msec
 16 2001:1530:b0:1::2 73 msec * * 
 17 2001:1530:b0:1::2 73 msec 73 msec * 
 18 * * * 
 19 * * * 
 20 * * * (etc.)

I already asked the ISP about this and waiting for answer.

Regarding this, I'm a bit off the track regarding theory how should it work. Yesterday I was thinking about my current configuration and realised that I've once done something similar with IPv4 and Juniper SSG140. Imagine that I am given two /29's by my ISP. I configure one for wan1 and the other to vlan14 (internal). I create policy from vlan14 to wan1 (using zones which contain them) and don't use NAT. Should it work? In that case years ago -- I got it working when I enabled NAT from "inside" to internet direction, although, maybe something else was missing that should've been done. My question is: what is that specific "thing" or miracle in IPv6 logic that allows the same without NAT and possibly even in other direction, from internet to inside -- provided the FGT allows that traffic via a policy. Is it just the fact and internal built-in logic that it won't work with IPv4 but will work with IPv6? The difference here in IPv6 case is that there isn't any additional network that I want to get working (actually there is, former /64 that they retained, can still be used for testing) but I'm rather splitting a bigger network into smaller /64 segments.

2) For the loop6 interface I created one and I had to enter the interface too.

config system interface edit "loop6" config ipv6 set ip6-allowaccess ping set ip6-address 2001:db8:1:66::1/64 end set interface "port1" set vlanid 66 next end

config firewall policy6 edit 4 set name "20160420" set srcintf "untrust" set dstintf "loop6" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ALL" set logtraffic all next end

diag debug reset diag debug enable diag debug flow filter6 addr 2001:db8:1:66::1 diag debug flow show console enable diag debug flow trace start6 100

No logs on console.

Trace's end part from NTT:

13 bbr1.tln2.ee.v6.eunetip.net (2001:670:3:4:1::7) 69 msec
 bbr1.tln1.ee.v6.eunetip.net (2001:670:3:4:1::6) 63 msec 63 msec
 14 2001:670:3:22::2 71 msec
 2001:670:3:21::2 70 msec
 2001:670:3:22::2 70 msec
 15 2001:1530:0:5::2 76 msec
 2001:1530:0:6::2 63 msec
 2001:1530:0:5::2 71 msec
 16 2001:1530:b0:1::2 70 msec * 70 msec
 17 2001:1530:b0:1::2 71 msec * * 
 18 * * * 
 19 * * * 
 20 * * * 
 21 * * * (etc.)

Ping does not work too. Even when I set the interface to wan1 instead of (internal) port1, it was all the same.

Pings to routers' external addresses worked from NTT, but to internal it didn't work.

Before I did another test: I changed router's external address to 2001:db8:1:f::1/60 and then I could ping IPv6 addresses outside from the router's external address so it isn't that the ISP actually kept routing a /64.

3) I enabled filter6 for debug flow with addr 2001:db8:1:14::1 but when I traced that address from NTT LG, I didn't see any log appearing to console.

For me, it looks like there is something missing in the firewall configuration, or it is principally wrong at the moment. There are some vdom's too but I am dealing all this within one of them only. FGT is not a cluster. Maybe I have forgotten to mention something else important?...

Btw, from earlier description, there is another thing that I don't understand: with IPv6 NAT, there is access to internet in my case, but the advertised router address is still the LL address, not the globally routable one. Which one should it be? And in the blog post about Fortinet's IPv6 style, did you have external IPv6 configuration too or not for internet access?

emnoc · ‎04-20-2016

For#2 you need to set the type to "loopback" I guess I should have been more detailed

config system interface edit "loop6" set vdom "root" set type loopback config ipv6 set ip6-allowaccess ping set ip6-address 2001:db8:11::/64 <---- ensure you have fwpolicy6 from untrust to loop6 icmpv6 end next end

Now you test that one /64 via a NTT-LG or similar and see if 1> traffic enters 2> if you can ping it 3> this validates that your upstream ISP and internet v6 backbone has reach on that prefix. Repeat for any other address if you suspect bgp router6 issues from your ISP or any upstreams.

For#3 that's normal behavior for the link-local address and the rt-adv. I think that's what your saying. Check out these blog post on ipv6 SNAT and rt-adv it's from a pfSense but the fortigate does the same.

http://socpuppet.blogspot.com/2014/04/nat66-in-crunch-on-fortigate.html

http://socpuppet.blogspot.com/2015/08/pfsense-ipv6-router-preferences.html

and

http://socpuppet.blogspot.com/2015/07/ipv6-ra-security-concerns.html

NOTE : I'm a cli junkie and pcap analyst guy ;)

You can dump the rt-adv via wireshark/tshark and inspect the output and to ensure it's the "FGT" and not something else that's acting as a ICMPv6 router.

PCNSE

NSE

StrongSwan

echo · ‎04-21-2016

OK, I set the type as loopback. I created rule from vlan14 to loop6 and ping works. Ping from internet to that address doesn't work, neither traceroute. And policy got hits and didn't get hits respectively.

By the way, does it really work in your environments that when you use -I <internal> for pinging IPv6 outside, it works like that? If yes, then I can also think of this as a valid test; currently I am not sure because it doesn't work with IPv4 and NAT (pinging out from NAT interface).

NAT66 crunch? SNAT to internet has worked all the time.

I tried to see some wireshark info too in Win2012 and when RA appeared, it was from FGT's LL address.

I tried again the diag debug flow together with NTT LG tests. When I pinged the 2001:db8:1::2 address successfully, I got these lines:

id=20085 trace_id=63 func=resolve_ip6_tuple_fast line=3251 msg="vd-db8 received a packet(proto=58, 2001:668::3::6000:642:53616->2001:db8:1::2:128) from wan1." id=20085 trace_id=63 func=resolve_ip6_tuple_fast line=3276 msg="Find an existing session, id-0071848e, original direction"

When I did the same with traceroute, I got this:

id=20085 trace_id=73 func=resolve_ip6_tuple_fast line=3251 msg="vd-db8 received a packet(proto=17, 2001:668::3::6000:642:48729->2001:db8:1::2:33466) from wan1." id=20085 trace_id=73 func=resolve_ip6_tuple line=3352 msg="allocate a new session-00718508" id=20085 trace_id=73 func=vf_ip6_route_input line=535 msg="find a route: gw-:: via db8 err 0 flags 80200001" id=20085 trace_id=73 func=fw6_local_in_handler line=268 msg="iprope6_in_check() check failed,id=0 drop"

And policy gets no hits either. The source IP looks strange, with double :: which is not allowed... It was Amsterdam. Then I chose Frankfurt and got such IP-address in console: 2001:728::2000::16d, again with double ::, how come? Anyway, since ping worked and the same double-:: address was shown also there, maybe it's not the problem at the moment. From the tracert output of NTT LG I concluded that this address is actually 2001:728:0:2000::16d so this is very embarrassing for FortiOS to use :: in more than one place in the address. Npw I tried to use 2001:728:0:2000::16d as saddr in diag debug flow but I got the same error msg as earlier, and only when I tracert'd wan1 address, with tracert to internal address there were no logs.

When I searched the latter errormsg, I found this:

http://kb.fortinet.com/kb/viewContent.do?externalId=FD31702

and got a hint that maybe it is related to management issues and our trusthost usage for FGT admins. But when I configured one admin with no trusthosts, the error message remained.

When I repeated the diag debug flow using 2001:db8:1:14:8587:8aff:85ab:3535 (Win2012) for daddr, that is, tracert or ping to internal network from NTT LG, there was no output in console. I specifically allowed ICMPv6 in firewall first and even turned off firewall but no difference, FGT logs should have appeared regardless of that. Internally ping works of course.

Then I tried to ping and tracert that loop6 address from outside, no output in console.

So in total, ping works up to wan1 address, tracert doesn't, and neither of these can go further into internal network, no policy matches either, even after broadening addresses and allowing all traffic just in case. Impicit deny policy at the bottom also didn't capture any additional packets or traffic during this. Still no answer from ISP's but why is FGT dropping tracert?

echo · ‎04-22-2016

I got an answer from both ISP's. Consider the original one now (discussion above). It turned out that they routed the /48 behind the original /64 (let it be noted here as 2001:db8:2::/64 while the /48 is as before, 2001:db8:1::/48). I'm not sure if this is any standard mode of setting up IPv6 because I have no experience, but in IPv4 this is usual when an additional network is allocated by ISP.

Anyway, I set up 2001:db8:2::2/64 to wan1, I set 2001:db8:2::1 as default route. Internally, there address is still 2001:db8:1:14::1/64 as just one /64 out of /48, also the loopback has 2001:db8:1:66::1/64.

Ping tests to internet direction.

Pinging internet in such conf works:

$ exec ping6 -I wan1 2001:4860:4860::8888 PING 2001:4860:4860::8888(2001:4860:4860::8888) from 2001:db8:2::2 wan1: 56 data bytes 64 bytes from 2001:4860:4860::8888: icmp_seq=1 ttl=52 time=51.2 ms

Pinging FGT itself from internal is fine as in next two tests:

$ exec ping6 -I vlan14 2001:db8:1:14::1 PING 2001:db8:1:14::1(2001:db8:1:14::1) from ::1 vlan14: 56 data bytes 64 bytes from 2001:db8:1:14::1: icmp_seq=1 ttl=64 time=0.028 ms

$ exec ping6 -I vlan14 2001:db8:2::2 PING 2001:db8:2::2(2001:db8:2::2) from ::1 vlan14: 56 data bytes 64 bytes from 2001:db8:2::2: icmp_seq=1 ttl=64 time=0.026 ms

Pinging ISP's router or internet from internal doesn't work anymore (as it's always been):

$ exec ping6 -I vlan14 2001:db8:2::1 connect: Network is unreachable

$ exec ping6 -I vlan14 2001:4860:4860::8888 connect: Network is unreachable

Ping tests to FGT direction from NTT LG. Router: Frankfurt - DE

Command: ping 2001:db8:2::2 Sending 5, 100-byte ICMP Echos to 2001:db8:2::2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 35/36/36 ms

Command: ping 2001:db8:1:14::1 Sending 5, 100-byte ICMP Echos to 2001:db8:1:14::1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

Command: ping 2001:db8:1:66::1 Sending 5, 100-byte ICMP Echos to 2001:db8:1:66::1, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)

Tracert together with diag debug flow gives the same "iprope6_in_check() check failed,id=0 drop" messages on console if I tracert wan1, and nothing appears when I tracert internal addresses, policies get no hits.

$ diagnose ipv6 neighbor-cache list Includes such line:

ifindex=6 ifname=wan1 2001:d8:2::1 00:0d:65:66:9d:47 state=00000002 use=502 confirm=502 update=406 ref=2 and this is the only one that begins with 2001. Maybe this is OK.

From ISP's e-mail: they saw in their neighbour list only FGT's wan1 address as it has been so far until yesterday, that is 2001:db8:1::2. Today I added "set ip6-send-adv enable" to wan1 too, just in case, but I don't know if this is required or not. This change automatically added "set ip6-other-flag enable" too to wan1.

I even allowed temporarily asymroute6-icmp because trace NTT LG --> FGT and backwards has different addresses but that didn't change anything (it should have local meaning anyway).

Now for the other ISP and other FGT where there is just one /57 involved, tracert from NTT LG gives exactly the same error:

id=20085 trace_id=126 func=fw6_local_in_handler line=268 msg="iprope6_in_check() check failed,id=0 drop"

and at the same time, ping to FGT's wan1 interface works:

id=20085 trace_id=131 func=resolve_ip6_tuple_fast line=3276 msg="Find an existing session, id-00486c9f, original direction"

Also, pinging from internal interface to ISP's def-gw already says that network is unreachable, as well as anything farther from that.

I will come back to this in May.

echo · ‎05-04-2016

After ISP made some additional changes, things got working. So it was the ISP issue.

1. It is now possible to use IPv6 internet without NAT from internal network to external, using globally routable addresses in internal part. The thing they did was they routed the /48 behind the firstly-given /64. Now ping from internet works to those internal addresses, it didn't work before.

2. I could also use IPv6 from internet to inside by creating a test firewall rule for HP switch web interface management and win2012 Remote Desktop.

3. Using diag debug flow I finally realised the problem why even after the above steps the tracert still didn't work. I thought that the service called ALL_ICMP6 contains traceroute but it turned out this is another service (it was so much more lower in the list that I never looked there by chance). After I allowed that one, trace started working!

4. Despite of all that, I still can't use FortiGate's CLI command to verify connection from internal to external, exactly as it is (not working) with IPv4. I can use "exec ping6 -I" only up to pinging FortiGate's addresses. If I go one step further to ping ISP's gateway, I get "connect: Network is unreachable". Sad. Because that means I must have also some device in the network which is able to get IPv6 address and then start testing from there. The same thing bothers me with IPv4 where pinging from internal network address of FGT behind NAT to external has never worked.

So now I try to get things working with the other ISP in another office. Thanks for help!

emnoc · ‎05-04-2016

Good for the positive outcome ;)

On the int-ext, you might have better luck just using one of your /64 on a loopback interface as suggested earlier and have someone ping internally after allowance ping and a firewall policy

e.g

WAN--->----LOOPipv6-interface

allow icmp6

That would ensure you are really part of the ipv6 network.

PCNSE

NSE

StrongSwan