Objectif
Déterminer pourquoi une connexion TCP vers un hôte et un port précis échoue, en distinguant résolution DNS, routage, service non à l’écoute, firewall local, ACL réseau, NAT ou chemin asymétrique.
Prérequis
- Nom ou IP de destination, port TCP exact et application attendue.
- Une source de test représentative du vrai utilisateur.
- Accès au serveur cible ou à ses logs si possible.
- Connaissance des firewalls, NAT et ACL intermédiaires.
- Heure précise du test pour corréler les journaux.
Procédure pas à pas
Confirmer la destination et la résolution DNS
Si l’application utilise un nom, vérifiez d’abord vers quelle IP il se résout depuis le poste concerné. Un DNS split-horizon, un ancien enregistrement ou un cache peut envoyer le client vers le mauvais serveur alors que le port est parfaitement ouvert ailleurs. Comparez la réponse DNS depuis plusieurs réseaux si le service est publié en interne et en externe.
Resolve-DnsName <FQDN>nslookup <FQDN>ipconfig /displaydns- Le FQDN résout vers l’adresse réellement attendue pour cette source.
Tester le port depuis la vraie source
Utilisez Test-NetConnection depuis le poste ou serveur qui rencontre le problème. Comparez avec une autre source autorisée. Si un test fonctionne depuis le LAN mais pas depuis un VPN, la différence de chemin et de policy devient immédiatement utile. Notez l’adresse source effectivement utilisée sur les machines multi-cartes.
Test-NetConnection <HOST> -Port <PORT> -InformationLevel Detailed- TcpTestSucceeded et les adresses source ou destination permettent de qualifier l’échec.
Vérifier que le service écoute sur le serveur
Sur Windows, contrôlez le socket d’écoute et le PID. Un firewall ne peut pas expliquer un Connection refused si l’application n’est tout simplement pas démarrée ou écoute uniquement sur localhost. Comparez le port configuré dans l’application au port réellement écouté et vérifiez l’adresse de binding.
Get-NetTCPConnection -State Listen | Where-Object LocalPort -eq <PORT>netstat -ano | findstr :<PORT>Get-Process -Id <PID>- Le service prévu écoute sur la bonne adresse et le bon port.
Tester localement sur le serveur
Testez la boucle locale puis l’adresse serveur depuis le serveur lui-même. Si l’application ne répond pas localement, ne modifiez pas les équipements réseau : traitez d’abord le service, son binding, son certificat éventuel ou son firewall local. Si localhost fonctionne mais pas l’IP LAN, le binding ou le firewall hôte deviennent prioritaires.
Test-NetConnection 127.0.0.1 -Port <PORT>Test-NetConnection <SERVER-IP> -Port <PORT>- Un échec local oriente vers l’application ou le firewall hôte plutôt que le réseau.
Vérifier le firewall hôte
Contrôlez les règles Windows Defender Firewall ou le firewall de l’OS. Recherchez une règle d’entrée qui autorise le bon programme ou port et le bon profil réseau. Évitez de désactiver totalement le firewall comme test prolongé : créez plutôt une règle temporaire ciblée si nécessaire et supprimez-la après le diagnostic.
Get-NetFirewallProfileGet-NetFirewallRule -Enabled True | Select DisplayName,Direction,Action,Profile- Le port est autorisé pour la source ou le profil attendu, ou un deny local est identifié.
Vérifier routage, ACL et NAT intermédiaires
Sur les firewalls et routeurs, confirmez que la source réelle, la destination et le port correspondent à la règle. Pour une publication, vérifiez le VIP ou DNAT et la route retour du serveur. Un NAT correct à l’aller avec une route retour différente peut provoquer un handshake incomplet. Contrôlez également les objets de service et les zones ou interfaces utilisées par la policy.
- Le chemin aller-retour et la règle de sécurité sont cohérents.
Observer le handshake TCP avec une capture
Une capture SYN, SYN-ACK et RST permet de localiser la panne. SYN sans réponse : perte ou filtrage. SYN puis RST : hôte atteint mais service refusé. SYN, SYN-ACK puis pas d’ACK : souvent retour bloqué ou asymétrie. Sur FortiGate, utilisez un sniffer ciblé ; sur le serveur, Wireshark ou pktmon peuvent compléter.
diagnose sniffer packet any 'host <CLIENT-IP> and host <SERVER-IP> and tcp port <PORT>' 4 30 l- Le point où le handshake s’arrête est identifié.
Utiliser un debug flow firewall si la capture ne suffit pas
Sur FortiGate, un debug flow filtré peut montrer la route, la policy et la raison du drop. Limitez-le à la source et destination du test et désactivez-le immédiatement après collecte. Si le trafic est offloadé sur NPU, la trace peut être incomplète ; utilisez alors la capture et les logs avant toute modification d’accélération.
diagnose debug resetdiagnose debug flow filter saddr <CLIENT-IP>diagnose debug flow filter daddr <SERVER-IP>diagnose debug flow filter dport <PORT>diagnose debug enablediagnose debug flow trace start 50diagnose debug flow trace stopdiagnose debug disablediagnose debug reset- La policy et la décision FortiOS sont connues pour le flux exact.
Retester l’application complète
Après correction, refaites Test-NetConnection puis le vrai client applicatif. Un port TCP ouvert ne garantit pas la réussite TLS, HTTP, SQL ou d’un protocole métier. Vérifiez les logs applicatifs, le certificat, le SNI ou l’authentification si le handshake TCP est désormais correct mais que l’application continue d’échouer.
- Le service applicatif, pas uniquement le port, fonctionne depuis la source réelle.
Validation
La procédure est validée lorsque :
- Le nom résout vers la bonne destination et le routage aller-retour est cohérent.
- Le service écoute sur le port attendu et le firewall hôte l’autorise.
- Le handshake TCP complet est visible ou Test-NetConnection réussit.
- Le client applicatif réel fonctionne après correction.
Retour arrière
- Supprimer toute règle firewall temporaire créée uniquement pour le test.
- Restaurer les ACL ou NAT précédents si une modification réseau n’apporte pas le résultat attendu.
- Réactiver les protections désactivées temporairement et documenter la cause réelle.
Dépannage / erreurs fréquentes
- TcpTestSucceeded=False avec Connection refused : vérifier le service et le binding avant le firewall réseau.
- Timeout avec SYN visible côté client mais pas côté serveur : chercher un filtrage ou mauvais routage intermédiaire.
- SYN-ACK visible côté serveur mais absent côté client : analyser le chemin retour ou le NAT.
- TCP fonctionne mais application échoue : passer au diagnostic TLS, protocole ou applicatif.
- Le test fonctionne par IP mais pas par nom : revenir au DNS, au SNI et à la destination résolue plutôt que d’ouvrir davantage le firewall.