Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

Bonjour

J'ai ouvert un case chez Fortinet (CASE Fortinet #9686357) pour des soucis similaires chez un client accompagnés de problèles de débits sans beaucoup de succès… Voici quelques pistes à transmettre à votre service informatique:

Modifications de configurations pour activer le DTLS (UDP encapsulation du VPN SSL) :

config vpn ssl settings
set ssl-min-proto-ver tls1-1
set dtls-tunnel enable
end

Réduction du TCP MSS pour l'encapsulation TCP dans UDP (DTLS c'est un peu comme des poupées russes), ici dans l'exemple 1300 ce sont les valeurs fournies par le support Fortinet mais d'après mes tests, une valeur entre 1100 et 1200 fonctionne mieux pour la stabilité

config firewall policy
edit (id) <--- SSL VPN policy handling your traffic
set tcp-mss-sender 1300
set tcp-mss-receiver 1300
end

Check des drops et d'un composant défaillant (un ASIC NPx) dans le FortiGate (Endpoint VPN SSL) :

we can check if there are any drops on the FortiGate (Testing a FAULTY ASIC)

Steps to Follow:
Run an IPERF3 test over the VPN
Please provide the IP and source of the flow used to test so that it will be possible to find it in the session list output.

1. Open a window and capture the output of the commands BEFORE the tests (iperf3):
# diag npu np6xlite anomaly-drop
# fnsysctl cat /proc/net/np6xlite_0/hif-stats
# diagnose npu np6xlite sse-stats
# diagnose npu np6xlite dce # Apply 10 times to check if any error or counting errors will appear
# diagnose snmp ip frags
# get system performance status
# diagnose sys session list

2. Capture the output of the commands below DURING the tests:
# diag npu np6xlite anomaly-drop
# fnsysctl cat /proc/net/np6xlite_0/hif-stats
# diagnose npu np6xlite sse-stats
# diagnose npu np6xlite dce # Apply 10 times to check if any error or counting errors will appear
# diagnose snmp ip frags
# get system performance status
# diagnose sys session list

3. Capture the output of the commands below AFTER finishing the tests:
# diag npu np6xlite anomaly-drop
# fnsysctl cat /proc/net/np6xlite_0/hif-stats
# diagnose npu np6xlite sse-stats
# diagnose npu np6xlite dce # Apply 10 times to check if any error or counting errors will appear
# diagnose snmp ip frags
# get system performance status
# diagnose sys session list

Aussi si vous détectez un 'FAULTY ASIC' , désactivez l'offloading sur la policy gérant le traffic ET contactez le support pour RMA

config firewall policy
edit (id) <--- SSL VPN policy handling your traffic
set auto-asic-offload disable
end

De tous les tests que j'ai pu faire (plusieurs semaines de tests avec le client, le support, etc), il à été décidé de passer en VPN IPSEC qui est beaucoup plus stable et performant.

Afin de continuer à fonctionner "presque" comme le VPN SSL, nous utilisons le RFC 8229 pour encapsuler IKE et NAT-T (UDP-500 et UDP-4500) dans TCP 443 notamment en réalisant la configuration de l'encapsulation en respectant le process décrit ici (voir la suite, notamment la Figure 5 à l'Appendix B):
https://https://datatracker.ietf.org/doc/html/rfc8229#appendix-A

La configuration à mettre dans la phase1 (pas du traffic selector IPSEC ~=phase2) au niveau du FortiGate est : set transport tcp

config vpn ipsec phase1-interface
    edit "VPN_XXX"
        set interface "port1"
        set ike-version 2
        set peertype any
        set net-device disable
        set proposal aes128-sha256 aes256-sha256 aes128gcm-prfsha256 aes256gcm-prfsha384 chacha20poly1305-prfsha256
        set transport tcp
        set remote-gw <VPN gateway public IP>
        set psksecret ENC xxxxxx
    next

end

Au niveau du FortiClient, actuvez également le transport TCP

Si vous devez connecter les users avec un annuaire comme LDAP ou MS Active Directory, faite de l'authentification EAP avec un RADIUS et mettez les groupes d'utilisateurs en plus dans les policy.

Voici quelques liens pour les différents types d'authentifications possible en entreprise avec le FortiClient en mobIKE (mobile ipsec), ça donne une bonne idée de ce que l'on peut faire :

https://https://community.fortinet.com/t5/FortiGate/Technical-Tip-Configure-Dialup-IPsec-IKEv2-VPN-tunnel-with-OKTA/ta-p/317244

https://https://docs.fortinet.com/document/fortigate/7.4.4/administration-guide/951346/saml-based-authentication-for-forticlient-remote-access-dialup-ipsec-vpn-clients

https://https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-configure-Microsoft-Entra-ID-SAML/ta-p/307457

https://https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-configure-AD-FS-SAML-authentication-for/ta-p/310592

https://https://community.fortinet.com/t5/FortiGate/Technical-Tip-Troubleshoot-IPSEC-SAML-Dial-UP-tunnel/ta-p/343030

https://https://community.fortinet.com/t5/FortiGate/Technical-Tip-FortiGate-SAML-authentication-resource-list/ta-p/213924

PS:
Dans un premier temps, demandez à votre service informatique d'activer DTLS et de réduire le TCP MSS, ça peut résoudre les soucis.
Si cela ne change pas, vérifiez que vous n'avez pas un matériel deffectueux (un ASIC deffectueux dans le FortiGate) et si ce n'est pas le cas, réfléchissez à la solution visant à abandonner le VPN SSL pour passer en IPSEC

Cordialement
nbanba

Bonjour

Le BUG avec l'IPv6 sur les connexions dual stack se caractérise par un blocage du FortiClient lors de la tentative de connection à 98% du process.
Un deep dive dans les skb sur un Linux à montré qu'à ce stade, le FortiClient essaye de pousser les routes IPv6 dans la table IPv4 (BUG ?)
Le changement de la précédence IPv6 / IPv4 avec netsh sous Windows et dans /etc/gai.conf sous Linux aide dans pas mal de cas, tout comme attaquer une IP ou carrément désactiver IPv6 des 2 côtés (et ça en 2024, vraiment je ne recommande pas, il est temps de faire fonctionner correctement tout avec IPv4 pour pouvoir arrêter IPv4)

Il n'y a pas de soucis en IPv6 avec IPSEC, si le selector est en V6, il monte en V6, s'il est en V4, il monte en V4 quand les 2 endpoints du tunnels sont en dual stack v4/v6.

Autre point en faveur d'IPSEC chez Fortinet, voici les capacité extraites de la datasheet du Forti qui est dans mon lab :

SSL-VPN Throughput : 1 Gbps
Concurrent SSL-VPN Users (Recommended Maximum, Tunnel Mode) : 500

IPsec VPN Throughput (512 byte) : 11.5 Gbps
Client-to-Gateway IPsec VPN Tunnels : 16 000

Soit 11.5 fois le débit pour 8 fois plus de clients…!
C'est là que l'on retrouve tous les milliards investis par Palo Alto, Fortinet, Cisco
depuis 20 ans… pour réussir à à offload ipsec sur des asic hyper performants contrairement au VPN SSL qui au final n'est qu'une rustine récente relativement adaptée pour faire l'admin du firewall lui même mais beaucoup moins pour du "pure tunnelling"

Aussi, en VPN SSL sur les datacenter de ma boite, depuis chez moi avec ma Freebox j'ai 18ms à 23 ms de ping en pingant la gateway VPN (lire le FortiGate) depuis mon laptop (connecté en fibre sur le lan de la freebox), le tout avec pas mal de jigue.

En IPSEC, j'ai 2,89 ms de ping (moyenne sur 1000 ping) lorsque je ping la VPN gateway depuis mon laptop (c'est le même équipement que pour le VPN SSL, la même connexion internet côté home & datacenter, etc…)

Pour comparaison, j'ai environ 2ms de ping sur dns.google (8.8.8.8) one.one.one.one (1.1.1.1) ou encode dns9.quad9.net (9.9.9.9)

Donc en IPSEC, au niveau qualité c'est presque comme si j'avais un MPLS privé entre mon laptop et les datacenters de ma société (au travers de ma freebox) alors qu'en VPN SSL c'est comme si j'avais une mauvaise ADSL de campagne, particulièrement lorsqu'il y a plus de 30 clients en VPN SSL

Cordialement
nbanba

Bonjour

Désolé pour les coquilles de mes précédents messages, ce n'est pas :

Soit 11.5 fois le débit pour 8 fois plus de clients

Mais

Soit 11.5 fois le débit pour 32 fois plus de clients

Pour precision de mon premier message, il faut noter que la recherche de composants défaillants dans les Fortigate peut être assez délicate à analyser (notamment les états des registres mémoires des asic 'npu' Fortinet NP{6,7} capturés pas à pas lors des debugs)

Si votre service informatique a des difficultés à interpréter les output des commandes (de par leur caractère avancé, certaines commandes ne sont pas documentées publiquement), n'hésitez pas à revenir ici et je vous dirais comment transmettre les outputs des commandes + les debugs logs des Fortigate (System > debug_log) pour analyse afin de vous faire un retour.

PS :
Je serais surpris que la ligne Free ou encore la Freebox soit en cause dans le fond (pas dans la forme et sans exclure la nécessité de faire évoluer certaines configurations côté Fortigate)

Bien cordialement
nbanba