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.

Labels
Top Kudoed Authors