Port Forwarding port RDP
-
Bon je continue mes tests.
Dès qu'il y a la mention de 3389, pfsense remplace aussitôt par MS RDP, et aussitôt ça bloque.
J'ai testé côté port source ou port de destination, même résultat…
En comparant les différences entre mes deux pfsense, celui qui pose problème est en 2.2.6 alors que l'autre est en 2.2.4.
Toujours aussi bizarre cette histoire...
-
Si, au besoin en activant les log au niveau du FW, tu ne vois rien coté pfSense, c'est peut-être que le blocage se situe au niveau de la machine que tu veux joindre.
-
J'ai testé en mettant mon portable de Taff à la place avec son IP, même résultat.
Il faudrait que je teste en mettant volontairement un port d'un des protocoles dans la liste déroulante pour voir si c'est juste quand on fait référence à ces ports que ca bloque ou non.
-
J'ai testé en mettant mon portable de Taff à la place avec son IP, même résultat.
Même résultat que quoi, quand ? Soyez précis cela nous évite de relire tous les posts du fil pour avoir une chance de comprendre ce que vous voulez dire. Ce que je n'ai pas fait. Pas le temps. Soyons efficaces.
-
Je répondais au post précédent, il n'y a pas d'autre personnes ayant répondu entretemps…
Donc pour éclaircir les choses pour tout le monde, j'ai testé l'aspect machine en remplacant ma machine personnelle par mon portable professionnel et en lui renseignant la même adresse IP que ma machine personnelle. Même résultat, à savoir que ça ne fonctionne pas non plus.
J'en conclus donc que la machine peut être écartée de l'équation.
Est-ce assez clair pour vous ?
-
Et que donne la vérification suggérée par chris4916 : Trafic visible ou non sur l'interface de Pfsense ?
-
La vérification du trafic donne que je vois bien du trafic passer (PASS) dans le firewall.
Pour le moment j'ai réussi a bypasser le problème en changeant le port d'écoute sur ma machine (en 3390) et en faisant du NAT du 3389 vers le 3390. Si je remet le 3389, ça ne répond plus. Mais toujours PASS dans les logs du FW…
C'est rageant de pouvoir faire du TSE en LAN sans souci de poste à poste via ce port mais pour le faire depuis l’extérieur il faut changer le port d'écoute de la machine cible :'(
Bref merci pour les infos et le temps passé en tout cas.
-
On a avancé sur ce qui se produit. Et si on capture les trames d'une tentative de connexion depuis l’extérieur, donc en passant par la firewall, et en utilisant la configuration standard (3389), que voit on à l'analyse des trames ? Des drop, des reject de la part de la machine destinataire ou pas de réponse tout simplement ?
-
Je veux bien faire la capture mais je ne sais pas (plus) les interpreter :(
-
Vous en mettrez une copie d'écran ici pour que l'on puisse regarder ce qui se passe.