[Résolu] Comment rediriger un de mes ports internet vers ma machine local (PAT)
-
Bonjour à tous, je viens de mettre en place un pfSense avec ma freebox. J'ai désactivé le NAT et le DHCP sur cette dernière, voici le plan actuel:
[]–-----------------|
SRV 192.168.0.104 |
|–-------------------------------[]--------------------------[]--------------------------------------[INTERNET]
[] | 192.168.0.1 PFSENSE 88.xx.yy.zz FREEBOX
SRV 192.168.0.106 –|Je voudrais rediriger un port par exemple le 7777 vers mon serveur 192.168.0.104, donc normalement j'ai créé une règle dans firewall NAT comme celà:
Uploaded with ImageShack.us
Mais rien à faire lorsque j'utilise le logiciel permettant de se connecter à mon adresse publique avec le port: 88.xx.yy.zz:7777, il me dit que le serveur ne répond, pas la redirection ne se fait pas, pourtant la règle est aussi créé dans le firewall…
Quelqu'un a une idée ?
Ne devrais-je pas mettre une plage de port "locaux" en port externe ?
Merci d'avance, Sam. -
Moi dans "External port range " j'aurai rempli from : 7777 et to : vide comme c'est indiqué en dessous "Specify the port or port range on the firewall's external address for this mapping.
Hint: you can leave the 'to' field empty if you only want to map a single port"Cdt,
-
Je l'ai fait, de toute façon par défaut c'est ce qu'il fait un from: 7777 to: 7777 est automatiquement converti en 7777…
C'est vraiment handicapant cette histoire, c'est bien dans "port forward" logiquement que ça doit se faire ? -
La règle nat semble ok. La règle d'autorisatin est elle en place ?
-
Erreur de frape ? NAT IP : 192.168.104
-
… par défaut c'est ce qu'il fait un from: 7777 to: 7777 est automatiquement converti en 7777...
Je ne dit pas le contraire, mais ayant rencontrer des soucis avec des SpeedTouch si je rentrais 'from 7777 to 7777' au lieu de 'from 7777', jamais compris pourquoi …!
-
erreur de frappe mais que pour l'exemple, je n'étais pas devant mon pfsense au moment du post de ce fait je l'ai fait sur un autre, mes correctement voilà les deux screens: (à ccnet, la règle de pare-feu est logiquement crée automatiquement à la fin du nat donc normalement je n'ai rien de plus à faire ???)
Uploaded with ImageShack.us
Uploaded with ImageShack.us
-
Les règles NAT comme Rules semble correct.
Question : la Freebox est en mode 'Routeur' quand vous dite que NAT et DHCP sont désactivé ou elle est en mode 'Bridge' ?(Histoire d'être sur)
Sinon au vu des information que l'on a, il ne reste que le serveur en question.
Et en interne, cela fonctionne t'il? -
Alors pour ce qui est du serveur j'ai vérifié il fonctionne en interne, et pour faire plus simple j'ai redirigé le port 80 vers le 192.168.0.1, c'est à dire mon pFsense et du web en entrant mon ip publique je n'ai pas accès à l'interface de gestion.
Concrètement en quoi consiste le mode bridge ?
Pour la freebox, je vous poste carément l'interface de configuration, ce sera plus simple, dans Configurer mon routeur Freebox:Mais logiquement les IP mises pour la freebox 192.168.1.1 ne sont pas actives. Quand je clique sur détails des configurations j'obtiens ça:
-
RTFM. Les règles WAN ne sont pas dans le bon ordre.
-
même en désactivant la règle muraille ça ne fonctionne pas…
-
Mettez vos règles dans le bon ordre de toute façon.
Quel est l'ip Wan de Pfsense ?
Vérifier le statut des interfaces (Menu Status: Interfaces ), les adresses, les masques. Votre interface Wan devrait être en dhcp et avoir une ip publique 88.x.y.z
Activez les logs sur vos règles Wan pour voir ce qui se présente sur l'interface Wan. -
Alors, il y a du neuf !
Seul certain ports arrivent à être rediriger, le port 80 et 443 sans problème ce qui fait que je peux accéder à mon pfsense à distance.
Le port 8767 n'est pas redirigé, ni le 22.Du coup j'ai regardé mes logs et rien n'est bloqué par le firewall j'ai vérifié les logs. J'ai remis en ordre mes règles WAN les interfaces ont été vérifiées. L'interface WAN possèdent mon IP publique 88.x.y.z, elle est en DHCP et récupère IP et passerelle correctement.
-
A mon sens il reste un test à faire. Mettre en place une redirection du port TCP 8767 par exemple puis activer la capture de trames sur Wan en réalisant depuis l'extérieur un accès sur votre ip publique port 8767. Les captures peuvent être filtrées pour éviter les trames inutiles. Si il n'y a rien dans les captures c'est que vos paquets ne parviennent pas jusqu'à pfsense. dans la cas contraire il faut regarder la configuration de la machine destinataire puisque vous ne voyez pas de rejet de Pfsense.
-
Je vais essayer de faire ce test, mais si ça peut vous éclairer je fais la redirection NAT et:
- Une fois j'autorise les paquets venant du WAN à communiquer avec ma machine locale pour atteindre le 8767.
- Une autre fois j'interdis cette fois ces paquets.
Mais rien n'est loggé dans mon firewall qui normalement m'affiche les paquets bloqués, logiquement si ils sont bloqués par la règle du parefeu je devrais le voir… Idem pour le port SSH.
EDIT:
Je viens de faire les tests... J'arrive à capturer les paquets venant du port 443, je lance la capture, en host adress je mets l'IP public de où je me situe actuellement (je ne suis pas là où se situe mon pfsense), port 443 à surveiller et je capture. Ensuite je rentre l'IP publique de mon pfsense et je me connecte sur son interface par le web. J'arrête la capture et des paquets ont bien été capturés tout fonctionne. Par contre, si je change le port en mettant le SSH ou le 8767 aucun paquet n'est capturé... Là ça m'inquiète vraiment :-\ :-\ :'(
-
Pas de paquets capturés pour le port 8767 et pas de trace de rejet dans les logs me font penser qu'ils ne parviennent tout simplement pas jusqu'à Pfsense.
-
C'est justement ce qui m'inquiète… Quand ma freebox était en NAT ça marchait très bien, mais comment Free pourrait interdire ces ports sans que je puisse les contrôler ???
-
bon je viens d'installer un terminal sur mon téléphone là j'arrive à accéder à mon serveur et à distance… donc le problème ne venait pas de chez moi à ce niveau... Pourtant depuis chez moi ça ne marche pas en rentrant mon ip publique dans un putty pour le SSH... je suis perdu là O_o
-
Depuis l'ip source pouvez vous vérifier la présence d'un filtrage sortant ? Si cela fonctionne depuis le téléphone ni Free ni Pfsense ne sont en cause.
-
oui mais pourtant quand je capture les paquets sur le port 22 et que je me connecte ensuite via le phone aucun paquet n'est capturé, et quand je me connecte depuis mon réseau freebox avec un pc client sur mon ip publique pour tester ça ne marche pas… c'est louche
EDIT: si je coupe ma règle de parefeu autorisant le SSH depuis le WAN mon téléphone n'y accède plus, normal, et en plus les logs de mon parefeu m'indique qu'il a bien été bloqué. Je me demande si il n'y a pas une sécurité interdisant soit une connexion où l'ip source et l'ip de destination sont la même où alors que l'ip source est une ip privée...
-
Activez les logs de la règles qui laisse passez, et si vous la voyez dans les logs de pfSense quand vous chercher à vous connecté, c'est que votre problème ce situe en aval, sinon c'est que le problème ce situe en amont.
-
Pouvez vous me dire où je dois renseigner qu'il faut m'afficher aussi les règles autorisées ? je ne trouve pas cette option
-
Je me demande si il n'y a pas une sécurité interdisant soit une connexion où l'ip source et l'ip de destination sont la même où alors que l'ip source est une ip privée…
Une connexion avec une ip source et une ip destination est impossible !
Les connexions sur wan avec une ip privée sont bloquées : Interfaces: WAN Block private networks (en bas de la page).Il va falloir décrire en détail votre configuration de test. Je crains une incompréhension de certains aspects réseau.
-
+1 à ce que dit ccnet.
Pouvez vous me dire où je dois renseigner qu'il faut m'afficher aussi les règles autorisées ? je ne trouve pas cette option
Dans la Rules, Log : cocher Log packets that are handled by this rule
-
bon j'ai continué à faire mes tests, j'ai télécharger un "widget" HTC :D permettant de vérifier l'état d'un serveur TeamSpeak (soit le port 8767), au début bloqué par le firewall et loggé par ce dernier, une fois les ports renseignés dans le PAT et autorisés par le firewall, tout roule et le statut du serveur est récupéré.
Le point de l'IP privé m'avait échappé je le savais en plus, mais cela voudrait t'il dire que si par exemple je me connecte dans mon réseau local sur mon serveur teamspeak avec une ip par exemple 192.168.0.10 en lui indiquant l'ip publique du serveur, soit 88.x.y.z, il devrait m'interdire ?
-
Je doute que vous puissiez faire cela. Votre ip source 192.168.0.10 est probablement translatée pour sortir sur internet. Les routeurs sur internet ne routent pas les réseaux privés. Vous traversez bien internet pour vos tests ?
-
oui je sais qu'une IP n'est pas routable donc soit il ne passe par le net et s'attaque directement à mon interface WAN puisque mon IP publique est celle de mon interface WAN, donc le paquet entre dans l'interface LAN de mon pfsense, puis est routé vers ma WAN qui a l'IP que je veux atteindre, de ce fait il se pourrait qu'il ne sorte pas sur le net…
-
J'ai demandé à un pote qui lui n'est soumis à aucune règle d'entreprise, juste derrière une simple box et il arrive très bien à se connecter à mon serveur SSH et à mon serveur 8767, et le parefeu affiche bien les logs d'autorisation. Donc ça ne vient pas de ça et ça ne concerne que mon réseau local qui n'arrive pas à aller sur mes serveurs en passant par mon ip publique. Ce n'est pas handicapant du tout mais je voudrais tout de même comprendre pourquoi…
-
=> NAT reflection.
-
en effet je viens de trouver la théorie et en quoi consisté le NAT reflection:
NAT Reflection - in some configurations, NAT reflection is possible so services can be accessed by public IP from internal networks.
par contre je ne vois pas où l'activer/configurer, quelques petits détails s'il vous plait ? :)
EDIT:
J'ai trouvé, c'est dans System > Advanced et ça qui est coché par défaut:
Network Address Translation
Disable NAT Reflection Disables the automatic creation of NAT redirect rules for access to your public IP addresses from within your internal networks. Note: Reflection only works on port forward type items and does not work for large ranges > 500 ports.J'essaye ça vers 18h00, je suis pas chez moi actuellement pour tester et je vous tiens au courant :)
-
Voilà ça marche seul problème cette règle ne concerne que les ports inférieurs ou égaux à 500… Comment puis je faire pour mon port 8767 ?
-
Moyennant l'usage du cache dns de pfsense et la technique du split horizon, ne pourriez vous pas concevoir les choses différemment ? C'est juste une éventualité à ce stade.
-
c'est à dire laisser tomber le fait que je n'y arrive pas ?
-
pensez vous que ce soit normal de passer par l'IP publique pour joindre un service privé. si vous répondez:
-oui: alors mettez en place les règles NAT nécessaire (reflection)
-non: jouez avec la resolution DNS (split horizon DNS, comme évoqué par CCNET).Bonne chance.
-
c'est à dire laisser tomber le fait que je n'y arrive pas ?
Non pas du tout. La réponse de Juve est tout à fait appropriée.
Si il y a une impossibilité technique (numéro de port) il faudra utiliser le split horizon. Personnellement je trouve que c'est beaucoup plus propre. Par exemple www.domaine.com se résout différemment selon que l'on est sur le réseau local ou à l'extérieur.
Et puis c'est quand même pratique non ? -
oui exactement, en faite je voulais savoir pourquoi ça ne marchait pas, je vois que ça bloque je ne veux pas rester sur un point sombre, maintenant que je sais pourquoi et comment je pourrais passer outre, no problem, et actuellement je n'ai nullement besoin de ce genre de solution.
Bien vu pour le DNS, je n'y avais pas pensé :)
Une dernière petite question, on peut créer des aliases de ports, cependant comment les utiliser ? parce que je ne vois pas dans port les alias que je viens de créer… :-X
-
Un exemple d'alias de ports que j'utilise souvent. La liste des flux sortants autorisés depuis le lan est par exemple : 80, 443, 110
Je nomme l'alias WebPorts (exemple arbitraire) et je créé une seule règle sur l'interface Lan pour autoriser les flux sortants sur ces trois protocoles. En indiquant que "Destination port range" est "WebPorts". Il suffit de commencer à taper les premières lettres dans la zone en rouge. -
ah oui tout simplement… :D
Merci beaucoup tout est réglé !