Changer le port RDP : connecter un second PC via 3390 sans conflit

Besoin d’ouvrir une session Bureau à distance sur un second PC sans interférer avec celui déjà exposé ? En redéfinissant le port RDP et en ajustant pare‑feu ainsi que NAT, vous sécurisez l’accès à plusieurs machines derrière la même box, tout en gardant le contrôle depuis l’extérieur.

Sommaire

Vue d’ensemble du scénario

Dans un réseau domestique ou de petite entreprise, il est fréquent de vouloir contrôler plusieurs ordinateurs via Remote Desktop depuis l’extérieur :

Le PC A est la machine cliente nomade (par exemple votre ordinateur portable).
Le PC C est déjà accessible sur son port par défaut 3389, redirigé dans le routeur.
Le PC B, nouvellement ajouté, doit être joignable en RDP sans perturber l’accès à C ; vous lui attribuez donc le port 3390.

Problème : malgré la modification, la connexion vers B échoue. Passons en revue les causes possibles de bout en bout.

Pourquoi changer le port RDP ? (Sécurité & multi‑exposition)

Plusieurs raisons motivent le changement :

Éviter les collisions : un routeur ne peut transmettre qu’un seul flux TCP du port 3389 externe vers une adresse privée donnée. Pour publier un second hôte, un port externe différent est indispensable.
Réduire le bruit des robots : le port 3389 est constamment scanné. Choisir un numéro non standard, même s’il n’est pas une défense absolue, réduit le nombre de tentatives de connexion brute‑force.
Conformité : certaines politiques d’entreprise réservent 3389 à un RD Gateway ou à un VPN ; utiliser un port alternatif pour une machine isolée évite la violation de règles internes.

Pré‑requis et bonnes pratiques

Accès administrateur sur le poste B ;
Un plan d’adressage fixe : attribuez à B une IP statique ou une concession DHCP réservée ;
Connaissance de la console d’administration du routeur (home‑box, box FAI, routeur SOHO ou pare‑feu matériel) ;
Le service Télébureau (TermService) actif sur B, et l’option Autoriser les connexions à distance cochée dans Système > Bureau à distance ;
Idéalement un VPN pour éviter d’exposer quoi que ce soit en clair sur Internet – mais le présent guide se concentre sur la publication directe.

Étape 1 : Modifier le port RDP dans le Registre

Ouvrez une console PowerShell (ou regedit.exe) en mode administrateur :

Set-ItemProperty `
  -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name PortNumber `
  -Value 3390

Astuce : la valeur est en décimal ; inutile de convertir en hexadécimal si vous utilisez PowerShell.

Vérifiez immédiatement :

Get-ItemProperty `
  -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' `
  -Name PortNumber

Le résultat doit être 3390. Redémarrez ensuite le service :

Restart-Service TermService -Force

Un redémarrage système évite toute ambiguïté si vous ne pouvez pas arrêter les sessions actives.

Étape 2 : Vérifier l’écoute locale

Connectez‑vous en local (ou via un autre poste du LAN) pour inspecter les sockets :

netstat -ano | findstr :3390

Une ligne TCP 0.0.0.0:3390 0.0.0.0:0 LISTENING <PID> confirme que :

Le port est ouvert (état LISTENING) ;
Il écoute sur toutes les interfaces (0.0.0.0) ;
Le processus concerné est bien svchost.exe (TermService).

Absence d’écoute ? Revoir l’étape 1 (erreur dans le registre) ou vérifier qu’une autre application n’a pas déjà monopolisé le port.

Étape 3 : Adapter le pare‑feu Windows

La règle intégrée « Remote Desktop – User Mode (TCP‑In) » n’autorise que 3389. Dupliquez‑la ou ajustez‑la :

Ouvrez Pare‑feu Windows Defender avec fonctions avancées.
Dans Règles de trafic entrant, localisez la règle RDP existante.
Cliquez > Dupliquer ; renommez‑la RDP ‑ 3390.
Onglet Protocoles et ports : définissez Port local : 3390.
Onglet Portée : si vous désirez limiter l’accès (VPN, IP publique fixe), spécifiez les adresses autorisées.
Onglet Profils : cochez les profils réellement utilisés (Privé, Domaine, voire Public).

Réappliquez la politique :

gpupdate /force

Étape 4 : Configurer la redirection NAT sur le routeur

Chaque matériel possède son interface, mais les paramètres restent similaires :

Champ	Valeur pour le PC B	Explication
Port externe (WAN)	3390	Numéro visible depuis Internet
Adresse IP interne (LAN)	192.168.1.x	IP statique ou réservation DHCP du PC B
Port interne (LAN)	3390 ou 3389	Si vous n’avez pas modifié le port local, vous pouvez transposer 3390→3389
Protocole	TCP	Le Bureau à distance utilise TCP uniquement (UDP optionnel depuis Windows 8)

Important : Un port externe donné ne peut être mappé qu’à un seul hôte interne. Si vous exposez déjà le PC C sur 3389, n’essayez pas de renvoyer 3389 vers B.

Étape 5 : Tester la connectivité

Depuis le LAN (PC A connecté au même switch que B) :
telnet 192.168.1.x 3390
Écran vide = connexion aboutie. Message d’erreur = filtrage local.
Depuis l’extérieur (4G, autre réseau Wi‑Fi) :
telnet <IP‑WAN‑routeur> 3390
Échec ? Revérifiez la règle NAT et si votre ISP bloque les ports entrants (cas des offres « Lite » ou CG‑NAT).

Étape 6 : Syntaxe de connexion côté client

Ouvrez Win + R > mstsc.exe :

Champ Ordinateur : <IP‑WAN>:3390 (accès Internet) ou 192.168.1.x:3390 (LAN).
Cliquer sur Afficher les options > Avancé > Paramètres pour forcer une authentification « Toujours me demander ». Cela clarifie le domaine ciblé.

Identifiants : utilisez DOMAINE\utilisateur ou utilisateur@machine, surtout si B n’appartient pas au même domaine que A.

Résolution avancée des problèmes

S’assurer que NLA et TLS ne bloquent pas

Depuis Windows 10, NLA est activée par défaut. Si l’horloge de B dérive ou si le certificat auto‑signé est corrompu, le client refusera la session avant même l’affichage du bureau :

wevtutil qe System /q:"*<QueryList><Query Path='System'><Select Path='System'>*[System[Provider[@Name='TerminalServices-RemoteConnectionManager'] and Level=2]]</Select></Query></QueryList>" /f:text /c:3

Regardez les IDs : 1026 pour l’échec NLA, 1100 pour TLS.

Vérifier que l’ISP n’est pas en CG‑NAT

De plus en plus de fournisseurs placent les abonnés grand public derrière un NAT Carrier‑Grade. Les ports entrants sont alors inexploitables sans service « DMZ » payant. Confirmez votre adresse IP WAN via l’interface du routeur et comparez‑la à celle retournée par un service de type Mon IP publique. Si elles diffèrent : demandez une IP fixe ou basculez vers un VPN sortant qui relaie les ports.

Contrôler le service « Remote Desktop Services UserMode Port Redirector »

Ce sous‑service gère le canal auxiliaire UDP depuis Windows 8/2012. Un dysfonctionnement provoque des connexions très lentes ou instables. Redémarrez‑le :

sc stop UmRdpService
sc start UmRdpService

Examiner les journaux pare‑feu

Activez la journalisation :

Set-NetFirewallProfile -Profile Domain,Public,Private `
  -LogFileName '%systemroot%\System32\LogFiles\Firewall\pfirewall.log' `
  -LogAllowed True -LogBlocked True

Les lignes contenant 3390 indiquent si le trafic est « ALLOW » ou « DROP ».

Bonnes pratiques de sécurité après mise en service

Activer l’authentification multifacteur : avec Windows Hello ou une passerelle RD Gateway, évitez les simples mots de passe.
Bloquer le port sur les adresses inconnues : même exposé, vous pouvez filtrer par pays ou plage IP sur certains routeurs modernes ou via un pare‑feu logiciel tiers.
Mettre à jour le chiffrement RDP : désactivez TLS 1.0/1.1 et RC4 via GPO (Computer Configuration\Administrative Templates\System\Remote Desktop Services\Remote Desktop Session Host\Security\).
Surveiller les tentatives échouées : Get-EventLog -LogName Security -InstanceId 4625 -After (Get-Date).AddDays(-1) alerte sur les échecs d’ouverture de session des dernières 24 h.
Limiter le nombre de sessions : une GPO peut réduire la fenêtre d’attaque (Maximum connections allowed).

Tableau récapitulatif des points de contrôle

Point	Pourquoi c’est crucial ?	Outil de vérification
Port modifié dans le Registre	Condition sine qua non pour écouter sur 3390.	`Get-ItemProperty`
Service à l’écoute	Assure qu’aucune application ne bloque le port.	`netstat -ano`
Pare‑feu adapté	Filtrage local sinon connexion refusée immédiatement.	Console WF.msc
Redirection NAT	Sans translation, aucun paquet n’atteint B.	Interface routeur & `telnet`
NLA/TLS OK	Évite les erreurs avant la phase d’ouverture de session.	Observateur d’événements
Syntaxe client correcte	MSTSC requiert hôte:port ; l’oubli du « :3390 » est classique.	Interface MSTSC
CG‑NAT désactivé	Port inaccessible sinon.	Comparaison IP routeur / IP publique

Conclusion

En respectant la séquence Port → Écoute → Pare‑feu → NAT → Test, vous identifierez en quelques minutes la cause d’un échec de connexion RDP sur port personnalisé 3390. Une fois opérationnel, consolidez la sécurité (MFA, filtrage IP, mises à jour) pour que ce second poste reste aussi fiable que le premier.

Changer le port RDP : connecter un second PC via 3390 sans conflit