Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
marijn
New Contributor

IPV6 ping works, but i receive a lot of http(s) time-outs

Hello, 

 

I've got a strange problem with my ipv6 connection.

I receive ipv6 addresses on my internal port and my internal hosts. (not on my wan port). 

I can ping external ipv6 addresses both from the fortigate 60D and from my internal hosts. 

The ipv6 test from test-ipv6.com has a 10/10 score and is reachable. However most other ipv6 sites receive time-outs and according to the traffic logs get a firewall action "close"

 

Does anyone know how it can be that some ipv6 sites are reachable but most are getting a time-out if you try to open the web-page? 

 

Below is are the test results and my configuration.  

 

 

 

 

 

 

 

 

Wan port config: 

 

config system interface edit "kpn-wan" set vdom "root" set mode pppoe set allowaccess ping set type tunnel set estimated-upstream-bandwidth 200000 set estimated-downstream-bandwidth 200000 set role wan set snmp-index 16 config ipv6 set ip6-allowaccess ping set dhcp6-prefix-delegation enable end set interface "wan1" next end

 

lan port config: 

 

edit "internal2" set vdom "root" set ip 10.9.30.1 255.255.255.0 set allowaccess ping https ssh http set vlanforward enable set type physical set device-identification enable set device-identification-active-scan enable set snmp-index 8 config ipv6 set ip6-mode delegated set ip6-allowaccess ping set dhcp6-information-request enable set ip6-send-adv enable set ip6-upstream-interface "kpn-wan" set ip6-subnet ::1/64 config ip6-delegated-prefix-list edit 1 set upstream-interface "kpn-wan" set autonomous-flag enable set onlink-flag enable set subnet ::/64 set rdnss-service delegated next end end set mtu-override enable set mtu 1480 next end

 

ipv6 routing table:

 

S* ::/0 [10/0] via ::, kpn-wan, 12:55:50 C ::1/128 via ::, root, 12:55:56 C 2a02:XXXX:XXXX::/64 via ::, internal2, 12:20:29 C fe80::/10 via ::, internal2, 12:20:29

 

IPV6 policy's

 

ICMP in

set name "internal2-ICMP" set uuid 0f6a3a2a-b5ff-51e8-d368-c8d4255dab4e set srcintf "kpn-wan" set dstintf "internal2" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ALL_ICMP6"

 

default-out:

set name "internal2-default-out" set uuid 2788336e-b5ff-51e8-b608-6af2ddf2d074 set srcintf "internal2" set dstintf "kpn-wan" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ALL" set logtraffic all

 

 

 

 

 

3 REPLIES 3
marijn
New Contributor

Did some further testing, it looks like the TLS handshake fails on ipv6

 

curl -v https://ipv6-test.com * Rebuilt URL to: https://ipv6-test.com/ * Trying 2001:41d0:8:e8ad::1... * Connected to ipv6-test.com (2001:41d0:8:e8ad::1) port 443 (#0) * found 148 certificates in /etc/ssl/certs/ca-certificates.crt * found 597 certificates in /etc/ssl/certs * ALPN, offering http/1.1 * Operation timed out after 0 milliseconds with 0 out of 0 bytes received * Closing connection 0 curl: (28) Operation timed out after 0 milliseconds with 0 out of 0 bytes received

 

 

 

curl -v https://test-ipv6.com * Rebuilt URL to: https://test-ipv6.com/ * Trying 208.111.44.226... * Connected to test-ipv6.com (208.111.44.226) port 443 (#0) * found 148 certificates in /etc/ssl/certs/ca-certificates.crt * found 597 certificates in /etc/ssl/certs * ALPN, offering http/1.1 * SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256 * server certificate verification OK * server certificate status verification SKIPPED * common name: test-ipv6.ams.vr.org (matched) * server certificate expiration date OK * server certificate activation date OK * certificate public key: RSA * certificate version: #3 * subject: CN=test-ipv6.ams.vr.org * start date: Mon, 09 Jul 2018 01:56:09 GMT * expire date: Sun, 07 Oct 2018 01:56:09 GMT * issuer: C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3 * compression: NULL * ALPN, server accepted to use http/1.1 > GET / HTTP/1.1 > Host: test-ipv6.com > User-Agent: curl/7.47.0 > Accept: */* > < HTTP/1.1 200 OK

 

 

And it seems to work on google.com

 

curl -v [link]https://www.google.com[/link] * Rebuilt URL to: [link]https://www.google.com/[/link] % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 2a00:1450:400e:806::2004... 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Connected to www.google.com (2a00:1450:400e:806::2004) port 443 (#0) * found 148 certificates in /etc/ssl/certs/ca-certificates.crt * found 597 certificates in /etc/ssl/certs * ALPN, offering http/1.1 * SSL connection using TLS1.2 / ECDHE_ECDSA_AES_128_GCM_SHA256 * server certificate verification OK * server certificate status verification SKIPPED * common name: www.google.com (matched) * server certificate expiration date OK * server certificate activation date OK * certificate public key: EC * certificate version: #3 * subject: C=US,ST=California,L=Mountain View,O=Google LLC,CN=www.google.com

 

 

 

 

 

 

 

marijn
New Contributor

Problem has been solved.

 

I had to configure the set ip6-link-mtu command to 1492.

 

I had configured the mtu settings for both the wan en lan side, however i was under the assumption that the mtu override was for both ipv4 and ipv6, and it took me a while to figure out that this is not the case.

 

all in all i've learned a lot about ipv6 with this problem and am happy it's resolved

 

 

tanr
Valued Contributor II

Thanks for posting your solution.

Announcements
Check out our Community Chatter Blog! Click here to get involved
Labels
Top Kudoed Authors