Résolu - Configuration PFSense (et Numericable en mode bridge)
-
Bonjour,
Je suis nouveau ici et après de nombreuses recherches, je ne trouve pas la solution à mon problème.
Je possède un petit réseau domestique sympa avec des ordinateurs, des portables et même un lapin connecté.
Je suis dans l'informatique mais plus dans la préparation et la réparation.
Touche à tout, je me suis mis en tête de me passer de mon routeur netgear-Numericable pour utiliser directement un serveur PfSense.Après plusieurs essais et ré-installation, j'arrive à faire prendre au serveur une IP de numéricable (en DHCP pour le Wan).
Je suis sur une installation fraiche, pas de configuration (hormis mon nom de domaine et le nom du serveur et un accès en https)
Si ce n'est qu'à l'installation, j'ai demandé au Wan de rester en DHCP. C'est le seul moyen pour qu'il puisse récupérer les adresses des serveurs DNS du FAI.Mais … malgré une installation sans encombres, malgré le fait que je vois bien l'ip, la passerelle et les dns du FAI, impossible de charger une page internet.
Alors je me suis penché sur le Nat, j'ai tenté quelques règles très ouvertes et, chose amusante, il m'est possible de faire du ping via le serveur PfSense sur le wan, le lan et même sur la lune, mais, toujours impossible d'afficher une page internet.
La majorité de mes lectures m'ont indiqué que suite à l'installation du serveur, c'est connecté et on peut naviguer.
Egalement, j'ai trouvé des articles intéressant expliquant que chez Numericable, quand on se connecte via son propre routeur, on ne garde pas la même IP que via le routeur Numericable.
Aussi, (surtout avec la Box Numericable dont, je suis heureusement dépourvu), il faut jouer avec des adresses MAC et limite passer la box à une réinitialisation pour éviter le blocage des ports.Bref, toujours est-il que je suis avec un serveur PfSense fraichement installé, qui récupère une adresse IP publique mais qui ne me permet pas d'accéder à internet.
Mon réseau est concentré sur un routeur wifi Asus RT AC 68U flashé avec une image Merlin (pas eu envie de faire du DDWRT que j'ai sur un WRT 54G).
Pour la blague, je me suis dit, pourquoi ne pas mettre le routeur dans le même état.
Passage du WAN en DHCP et moins de 15 secondes plus tard, je peux voguer sur le web avec une autre IP de Numéricable.Pour la précision, je modifie mes paramètres réseaux de l'ordinateur à chaque test pour choisir la bonne passerelle.
Maintenant, la configuration.
J'ai mis une image qui représente grossièrement le réseau.Le serveur PfSense est une machine virtuel sous VMWare EsxI, le serveur possède 2 cartes réseau intel dont l'une est branché sur le réseau LAN (via l'Asus) et l'autre sur le routeur netgear-bridge-Numericable.
Egalement, pour les besoins du tests, j'ai le routeur Asus (qui est le concentrateur du LAN) avec la patte WAN qui est sur le routeur netgear-blague-du-jour-Numericable.Auparavant, le serveur PfSense était la passerelle pour passer du réseau LAN en 192.168.0.0 au réseau connecté au routeur netgear (en mode routeur) sur le 192.168.1.0 et ça passait (mais je compte avoir un serveur web et dns ... et là, ça passe déjà moins avec un routeur netgear-en-bois).
Quelqu'un saurait me dire ce que j'ai pu oublier dans la configuration de PfSense (car c'est rageant de voir l'Asus y arriver en deux coups de cuillère à pot) ?
Merci de vos retours
Routeur Asus avec image WRT-Merlin -------------------------> LAN 192.168.0.254 ------------ WAN DHCP
Serveur virtuel PfSense 2.2 FreeBSD 10.1-RELEASE-p4 ---> LAN 192.168.0.6 ---------------- WAN DHCP
Un ordinateur banale ---------------------------------------------> LAN 192.168.0.99 avec passerelle 192.168.0.6 ou 192.168.0.254 selon si jeux veut aller sur internet ou me heurter à un mur.
-
Pour faire court : la resolution dns est fonctionnelle ?
Vous n'en dites pas un mot. Je reviendrai sur le reste plus tard. -
La principale différence entre pfSense et le point d'accès Asus, c'est que ce dernier ne fait pas vraiment office de pare-feu. Il peut même, à la limite, ne pas faire office de routeur 8) donc d'un point de vue réseau, c'est un mode de fonctionnement très différent.
Par ailleurs, le fait de faire des tests avec un client avec une configuration réseau statique nécessite de changer autre chose que la passerelle par défaut. Comme le fait remarquer ccnet, la configuration DNS est importante.
De mon point de vue, il serait bien plus facile, malgré les apparences, de ne pas faire cohabiter ces deux configurations mais de passer, si nécessaire de l'une à l'autre en débranchant quelques câbles, tout en activant un serveur DHCP sur pfSense et sur le point d'accès Asus (pas les deux en même temps bien sûr ;D)Enfin, le plus simple, lorsque ça ne fonctionne pas, est de faire des tests sur les différents segments du réseau afin de bien comprendre, au moins dans une démarche empirique, ce qui fonctionne et ne fonctionne pas.
pfSense dispose de beaucoup d'outils et de fonctionnalités permettant de consulter les logs et faire des tests "depuis pfSense" afin de s'assurer que ce serveur accède correctement à la cible.
Last but not least: faire un test sur une VM nécessite de déjà bien comprendre l'ensemble des couches plus la spécificité de la VM, en terme de réseau ;)
-
Il serait intéressant de savoir qu'est-ce que tu as pingé effectivement (Adresse IP ou nom de domaine). Une piste, déjà regarde du côté du DNS Forwarder pour récupérer ceux de ton FAI.
Le blocage du port 80/443 de manière native sur PfSense je n'y crois pas trop, et même au niveau réseau, si tu ping quelque chose, tout devrait être correct.
-
Bonjour,
( Pour ce qui va suivre, je considère que les aspects ESX et Dns sont ok )
1/ ajouter dans les configs Wan la MAC de votre routeur Numéricable (spoofing)
=> peut être pas obligatoire/nessessaire mais ne fera pas de mal2/ ping ok, dns ok => essayer avec une valeur de Mtu revue à la baisse (essayer en le fixant à 1492 par exemple)
=> hors cas de PppoE pf applique par défaut 1500 ^^cordialement
-
Merci à tous pour vos réponse.
En premier lieu, les test de ping ont été réalisé également depuis l'interface de PfSense.
De base, un ping sur mon réseau local n'a pas donné de résultats mais au cas ou, j'ai tout remis par défaut et fais les tests de ping suivant depuis pfsense :ping www.google.fr depuis le WAN :
PING www.google.fr (74.125.195.94) from 81.66.108.102: 56 data bytes 64 bytes from 74.125.195.94: icmp_seq=0 ttl=46 time=109.889 ms 64 bytes from 74.125.195.94: icmp_seq=1 ttl=46 time=59.498 ms 64 bytes from 74.125.195.94: icmp_seq=2 ttl=46 time=66.579 ms --- www.google.fr ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 59.498/78.655/109.889/22.274 ms
ping 74.125.195.94 depuis le WAN :
PING 74.125.195.94 (74.125.195.94) from 81.66.108.102: 56 data bytes 64 bytes from 74.125.195.94: icmp_seq=0 ttl=46 time=29.341 ms 64 bytes from 74.125.195.94: icmp_seq=1 ttl=46 time=28.262 ms 64 bytes from 74.125.195.94: icmp_seq=2 ttl=46 time=78.316 ms --- 74.125.195.94 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 28.262/45.306/78.316/23.346 ms
ping www.google.fr depuis le LAN :
PING www.google.fr (74.125.195.94) from 192.168.0.6: 56 data bytes --- www.google.fr ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss
ping 74.125.195.94 depuis le LAN :
PING 74.125.195.94 (74.125.195.94) from 192.168.0.6: 56 data bytes --- 74.125.195.94 ping statistics --- 3 packets transmitted, 0 packets received, 100.0% packet loss
ping 192.168.0.254 depuis le LAN :
PING 192.168.0.254 (192.168.0.254) from 192.168.0.6: 56 data bytes 64 bytes from 192.168.0.254: icmp_seq=0 ttl=64 time=8.320 ms 64 bytes from 192.168.0.254: icmp_seq=1 ttl=64 time=0.415 ms 64 bytes from 192.168.0.254: icmp_seq=2 ttl=64 time=0.354 ms --- 192.168.0.254 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.354/3.030/8.320/3.741 ms
Vous remarquerez que ça sort bien mais que depuis le local, rien ne passe.
Et pourtant, c'est l'installation de base, donc avec la partie LAN en open bar.Cela peut effectivement être un problème DNS et je viens de me rendre compte que j'ai oublié d'installer Bind … mais sans accès internet, cela risque d'être compliqué.
Je viens d'activer le DNS Forwarder ... mais sans plus de succès.
Le LAN ping pourtant bien le WAN :PING 81.66.108.102 (81.66.108.102) from 192.168.0.6: 56 data bytes 64 bytes from 81.66.108.102: icmp_seq=0 ttl=64 time=0.091 ms 64 bytes from 81.66.108.102: icmp_seq=1 ttl=64 time=0.052 ms 64 bytes from 81.66.108.102: icmp_seq=2 ttl=64 time=0.078 ms --- 81.66.108.102 ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 0.052/0.074/0.091/0.016 ms
Mais il ne va pas plus loin et j'avoue, je suis sous doué en ce qui concerne les problèmes DNS (surtout sur PfSense que je découvre).
Maintenant, je vais tenter le spoofing.
Réponse un peu plus tard dans la soirée.Si vous avez une idée d'ici là, n'hésitez pas ;)
-
Petite info, lorsque j'utilise une machine cliente, j'utilise par défaut le DNS de Open DNS : 208.67.222.222
Donc, que ce soit le DNS de PfSense ou autre dans mon réseau, cela ne change pas grand chose, à mes yeux.Le paquet devrais pouvoir traverser pfSense pour atteindre OpenDNS et me renvoyer la réponse et afficher le site web.
Mais comme déjà dit, le DNS, je connais les bases, le principe de fonctionnement, mais l'utiliser et le configurer … j’apprends encore.
Merci de votre mea culpa dans ce domaine. -
Le LAN ping pourtant bien le WAN :
Code: [Select]
PING 81.66.108.102 (81.66.108.102) from 192.168.0.6: 56 data bytes
64 bytes from 81.66.108.102: icmp_seq=0 ttl=64 time=0.091 ms
64 bytes from 81.66.108.102: icmp_seq=1 ttl=64 time=0.052 ms
64 bytes from 81.66.108.102: icmp_seq=2 ttl=64 time=0.078 ms–- 81.66.108.102 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.052/0.074/0.091/0.016 msDonc la connectivité réseau est bonne.
1. Activez les logs sur vos règles sur Lan.
2. Activez la capture de trame au besoin dans pfsense sur lan
2. Lancez un ping www.google.fr
3. Examinez le résultat dans les logs et la capture. -
En fait, c'est … pire que ce que je croyais (mais merci d'essayer de m'aider :) ).
Le spoofing n'a pas marché mais en même temps, le souci vient d'ailleurs.
Je me suis amusé à faire un traceroute.
Le WAN vers l'extérieur, pas de problème (même si je remarque plusieurs passages chez Numéricable).
Par contre, du LAN vers internet ... c'est équivoque :1 machi (192.168.0.6) 0.067 ms 0.039 ms 0.038 ms 2 machi (192.168.0.6) 0.042 ms 0.032 ms 0.025 ms 3 * * * 4 * * * 5 * * * 6 * * * 7 * * *
Il y a bien un soucis dans ma configuration mais … même si je sais qu'il y a du DNS là dessous, je ne saisi pas.
Faut-il faire un routage ?J'en doute, c'est pas pratique par principe.
Alors j'imagine qu'il y a une option, ou ... effectivement, le DNS côté LAN qui ne marche pas est la solution la plus plausible.Et quand je regarde ... je vois les DNS pour le WAN :
127.0.0.1
89.2.0.1
89.2.0.2Mais, côté LAN ... je ne trouve pas où configurer le DNS ... si c'est pas triste.
Voilà ce qui se présente en dessous de l'IP :
IPv4 Upstream Gateway - GW_LAN-192.168.0.6- or add a new one.Je comprends maintenant qu'il me manque juste une chose mais je ne sais pas quoi ...
Dernière info, la liste DNS dans General Setup est vide (la dernière fois, mon WAN avait bloqué dessus sans pouvoir récupérer le DNS du FAI).
Vos avis ?
-
La manière la plus simple (j'allais écrire primaire) de faire fonctionner ce type de réseau, c'est de configurer pfSense en serveur DHCP et en relais DNS (soit DNS forwerder soit Resolver) et de définir pfSense comme serveur DHCP des machines sur le LAN.
-
Et quand je regarde … je vois les DNS pour le WAN :
127.0.0.1
89.2.0.1
89.2.0.2Mais, côté LAN ... je ne trouve pas où configurer le DNS ... si c'est pas triste.
Je ne comprends pas cette formulation "coté WAN / coté LAN" :-[
De quoi parle t-on ?Contrairement à ce que décrit la doc pfSense, il n'y a pas de [i]vrai (à mon sens) split-DNS car il n'y a justement pas cette notion de DNS à deux faces.
Donc soit on utilise le DNS de pfSense, pour pfSense lui même et pour les machines clientes, soit un DNS externe.L'utilisation du DNS de pfSense permet de réécrire (c'est une sorte de spoofing) des adresses IP pour des machines hors de ton domaine.
les 2 serveurs DNS de pfSense sont plutôt destinés à être des relais des requêtes DNS clientes (et locales).Donc dans ton cas, le premier DNS est pfSense.
Les 2 suivants sont les DNS de Numericable.Si tu actives "DNS resolver" (ou DNS Forwarder) et configure tes clients pour utiliser pfSense comme leur DNS, la requête DNS va être résolue par pfSense.
Attention à l'utilisation d'outils comme ping et traceroute ou tracert: si ICMP est bloqué, ça ne marche pas ;)
-
Je me suis amusé à faire un traceroute.
Merci de faire les tests demandés si voulez vous en sortir. Cf la remarque ci dessus pour le traceroute.
Et quand je regarde … je vois les DNS pour le WAN :
127.0.0.1
89.2.0.1
89.2.0.2Manifestement le fonctionnement du resolver de Pfsense n'est pas comprise. En aucun cas Pfsense ne fourni de résolution pour Wan.
Retirez 127.0.0.1 de la liste des dns et cela devrait allez mieux. -
Manifestement le fonctionnement du resolver de Pfsense n'est pas comprise. En aucun cas Pfsense ne fourni de résolution pour Wan.
Retirez 127.0.0.1 de la liste des dns et cela devrait allez mieux.Je peux me tromper…. mais je ne le pense pas.
En effet, 127.0.0.1 est, par défaut, inclus dans la liste des DNS utilisés par pfSense sauf configuration spécifique.
(extrait de l'interface de configuration)By default localhost (127.0.0.1) will be used as the first DNS server where the DNS Forwarder or DNS Resolver is enabled and set to listen on Localhost, so system can use the local DNS service to perform lookups. Checking this box omits localhost from the list of DNS servers.
Du coup, l'ajouter est inutile, je suis d'accord, mais l'enlever sans cocher la case associée au commentaire ci-dessus ne devrait rien changer, AMHA ;)
Notre ami se focalise sur le DNS mais je ne suis pas certain que le problème se situe là. ça part un peu dans tous les sens au niveau des tests.
Ce serait pas mal de partir avec une configuration "simple"- DNS forwarder ou Resolver sur pfSense
- au moin un DNS (externe) configuré pour pfSense
- un client en DHCP qui hérite de pfSense comme serveur DNS
A partir de là, on peut faire des tests sans changer la conf client et essayer de comprendre ce qui fonctionne ou pas.
-
D'abord, merci chris4916 pour l'idée du test mais, la machine configuré en passerelle et en DNS sur PfSense n'affiche pas de page internet.
Et désolé ccnet de n'avoir pas fait les tests demandé mais je venais de réaliser que mon LAN était bloqué et ne pouvait pas trouver de serveur DNS.
Et pour préciser le trace route et le ping, en fait, mon IP LAN est 192.168.0.6 et mon IP WAN est 81.66.108.102.
J4ai donc fait un ping partant de 192.168.0.6 vers l'adresse 81.66.108.102 … et ça fonctionne, ce qui veut dire que mes deux interfaces internet arrivent à se trouver à travers PfSense.Mais bon, un reset et on recommence.
Je met donc une machine en DNS sur PfSense (je désactive mon autre serveur DHCP) et active le DHCP de PfSense.Une plage IP
la passerelle sur PfSense soit le 192.168.0.6
le DNS sur PfSense soit 192.168.0.6 et j'ajoute OpenDNS en second 208.67.222.222DNS Forwarder et Resolver activé
127.0.0.1 sur GW_LAN et Open DNS configuré pour le WAN_DHCP dans General Setup
Je valide le tout et hop, test.
bon, décidement, ça ne marche pas.
Voici la config WAN :
Status up DHCP up MAC address 74:de:2b:40:25:3a IPv4 address 81.66.108.102 Subnet mask IPv4 255.255.252.0 Gateway IPv4 81.66.108.1 IPv6 Link Local fe80::76de:2bff:fe40:253a ISP DNS servers 127.0.0.1 89.2.0.1 89.2.0.2 208.67.222.222 MTU 1500 Media 1000baseT <full-duplex>In/out packets 97983/98052 (8.04 MB/7.35 MB) In/out packets (pass) 97983/98052 (8.04 MB/7.35 MB) In/out packets (block) 3750/0 (806 KB/0 bytes) In/out errors 0/0 Collisions 0</full-duplex>
Et la ligne In/out packets (block) … m'intrigue.
Au cas où ça peut servir, voici la conf LAN
Status up MAC address 00:0c:29:56:4a:e4 IPv4 address 192.168.0.6 Subnet mask IPv4 255.255.255.0 Gateway IPv4 GW_LAN 192.168.0.6 IPv6 Link Local fe80::20c:29ff:fe56:4ae4 MTU 1500 Media 1000baseT <full-duplex>In/out packets 31015/29017 (1.92 MB/4.74 MB) In/out packets (pass) 31015/29017 (1.92 MB/4.74 MB) In/out packets (block) 12416/0 (938 KB/0 bytes) In/out errors 0/0 Collisions 0</full-duplex>
Vos avis ?
-
Et pour préciser le trace route et le ping, en fait, mon IP LAN est 192.168.0.6 et mon IP WAN est 81.66.108.102.
J4ai donc fait un ping partant de 192.168.0.6 vers l'adresse 81.66.108.102 … et ça fonctionne, ce qui veut dire que mes deux interfaces internet arrivent à se trouver à travers PfSense.:o je me demande bien comment tu fais ce type de test qui consiste à faire un ping depuis 192.168.0.6 vers 81.66.108.102 si les deux interfaces sont sur la même machine ???
DNS Forwarder et Resolver activé
Certainement pas. C'est soit l'un soit l'autre mais ils ne peuvent écouter tous les deux en même temps sur le port 53 ::)
127.0.0.1 sur GW_LAN et Open DNS configuré pour le WAN_DHCP dans General Setup
Suite au commentaire que ccnet et moi même faisions, quel est l'intérêt de mettre 127.0.0.1 comme DNS "explicite" ?
"ça ne marche pas" est assez peu explicite.
1 - tu pourrais décrire le test que tu fais et ce que tu obtiens (comportement, message d'erreur etc)
2 - tu peux également regarder dans les logs, par exemple le log du firewall pour voir si il y a des paquets bloqués -
Alors, je corrige.
Pour le test, c'est une vieille astuce pour vérifier les connexions, si une interface sait atteindre l'autre interface, c'est que les paquets peuvent circuler de l'un a l'autre.
Et par défaut savent sortir … mais, ici, c'est un peu l'échec.Désolé, le "ça ne marche pas" c'est juste tenter d'ouvrir une page web avec la machine configuré sur PfSense.
J'ai retiré DNS Forwarder pour laisser Resolver.
J'ai retiré 127.0.0.1 en cochant la case "Do not use the DNS Forwarder as a DNS server for the firewall "Désormais, seul les DNS du FAI sont enregistrés.
Status up DHCP up MAC address 74:de:2b:40:25:3a IPv4 address 81.66.108.102 Subnet mask IPv4 255.255.252.0 Gateway IPv4 81.66.108.1 IPv6 Link Local fe80::76de:2bff:fe40:253a ISP DNS servers 89.2.0.1 89.2.0.2 MTU 1500 Media 1000baseT <full-duplex>In/out packets 7676/7742 (645 KB/594 KB) In/out packets (pass) 7676/7742 (645 KB/594 KB) In/out packets (block) 351/0 (86 KB/0 bytes) In/out errors 0/0 Collisions 0</full-duplex>
Et le log du pare feu … c'est simple, tout est bloqué (cf l'image jointe).
Pourtant, les règles sont celles par défaut (LAN ouvert et WAN fermé)
![Sans titre 1.jpg](/public/imported_attachments/1/Sans titre 1.jpg)
![Sans titre 1.jpg_thumb](/public/imported_attachments/1/Sans titre 1.jpg_thumb) -
Pour le test, c'est une vieille astuce pour vérifier les connexions, si une interface sait atteindre l'autre interface, c'est que les paquets peuvent circuler de l'un a l'autre.
Et par défaut savent sortir … mais, ici, c'est un peu l'échec.Je ne comprends pas cette astuce :-
lorsque sur pfSense, tu fais un "ping 81.66.108.102", tu ne valides absolument pas que 192.168.0.6 lui parle car la commande ping s'exécute localement. Tout au plus tu t'assures que 127.0.0.1/8 sait joindre l'adresse ciblée.pour valider ce que tu décris, il faut, depuis une machine sur le LAN (et donc pas pfSense lui-même bien sûr ;)):
- faire un ping depuis cette machine vers l'interface interne (LAN) de pfSense
- si un ping de l'interface WAN
Et encore, comme expliqué précédemment, ceci ne fonctionne que si ICMP est autorisé 8)
Désolé, le "ça ne marche pas" c'est juste tenter d'ouvrir une page web avec la machine configuré sur PfSense.
Donc autant le remplacer par le message d'erreur explicite de ton navigateur, ça sera beaucoup plus clair pour tous.
J'ai retiré DNS Forwarder pour laisser Resolver.
Voila une bonne chose.
J'ai retiré 127.0.0.1 en cochant la case "Do not use the DNS Forwarder as a DNS server for the firewall "
Donc mon explication précédente n'était pas claire :( mais je soupçonne que ce soit en fait ta manière de décrire ce que tu configures qui ne l'est pas.
Le but n'est pas que 127.0.0.1 ne soit pas utilisé comme DNS mais uniquement de ne pas définir cette adresse expressément comme DNS car pfSense le fait tout seul par défaut.Tu devrais, AMHA, décrire uniquement "ce que tu fais" en terme de configuration plutôt que mélanger, d'autant que tes formulations sont parfois confuses, ce que tu configures et ce que tu vois comme résultat.
Et le log du pare feu … c'est simple, tout est bloqué (cf l'image jointe).
Pourtant, les règles sont celles par défaut (LAN ouvert et WAN fermé)En regardant cet extrait de log, je ne dirais pas "tout est bloqué".
- je ne vois pas de rejet de paquets issus du LAN en direction de port 53 (DNS) (alors que je suppose que ta machine sur le LAN requête un DNS externe (mais tu ne précises pas ça, sauf erreur)
- je ne vois pas de rejet de paquets issus du LAN en direction d'une adresse IP externe sur le port 80 (HTTP)
en revanche, je vois une machine à l'adresse 10.33.0.1 qui cherche un serveur DHCP :o :o et je me dis que tu ne nous fais qu'une description très partielle de ta configuration 8)
J'ai du mal à comprendre comment une machine avec cette adresse (RFC1918) peut se trouver coté WAN cohabitant avec une adresse 81.66.108.102Tu devrais d’abord te soucier de cet aspect au lieu de te focaliser sur le potentiel non fonctionnement du DNS.
-
Mes excuse pour la formulation, effectivement, je ne suis pas un pro dans le domaine et comme dit précédemment, je découvre PfSense.
Je vais tenter d'être le plus clair possible.
Test de ping depuis une machine cliente configuré pour utiliser PfSense :
C:\Users\ranmax>ping 192.168.0.6
Envoi d'une requête 'Ping' 192.168.0.6 avec 32 octets de
Réponse de 192.168.0.6 : octets=32 temps<1ms TTL=64
Réponse de 192.168.0.6 : octets=32 temps<1ms TTL=64
Réponse de 192.168.0.6 : octets=32 temps<1ms TTL=64
Réponse de 192.168.0.6 : octets=32 temps<1ms TTL=64Statistiques Ping pour 192.168.0.6:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%
Durée approximative des boucles en millisecondes :
Minimum = 0ms, Maximum = 0ms, Moyenne = 0msC:\Users\ranmax>ping 81.66.108.102
Envoi d'une requête 'Ping' 81.66.108.102 avec 32 octets d
Réponse de 81.66.108.102 : octets=32 temps<1ms TTL=64
Réponse de 81.66.108.102 : octets=32 temps<1ms TTL=64
Réponse de 81.66.108.102 : octets=32 temps<1ms TTL=64
Réponse de 81.66.108.102 : octets=32 temps<1ms TTL=64Statistiques Ping pour 81.66.108.102:
Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%
Durée approximative des boucles en millisecondes :
Minimum = 0ms, Maximum = 0ms, Moyenne = 0msPour le 127.0.0.1 , je ne trouve d'autre moyens de ne pas le retirer qu'en cochant la case.
Et pour l'adresse 10.33.0.1 … je ne sais pas d'où cela vient.
Mon LAN est en 192.168.0.0 et toutes les machines sont en ip statique (sauf la machine cliente de test).Pour la configuration de PfSense, c'est celle par défaut. Et pour être sur de ça, je vais refaire l'installation à zéro.
Ne connaissant que peu ce pare feu, je n'ai pas pris la liberté de modifier quoi que ce soit.La suite peut être ce soir et merci de votre patience.
-
Avant de réinstaller pouvez vous faire les tests demandés complets ?
L'étape suivant serait un ping 216.58.211.99 (une des ip de www.google.fr) puis ping www.google.fr.
Avec les résultats nous serons fixés sur la nature du problème. Il est important d'être méthodique et de comprendre.Les logs sont curieux et laissent effectivement penser que votre description est incomplète. En TCP il n'y a que de l'ip V6 et en udp V4 il y a ce trafic DHCP sur un réseau qui n'est pas le votre.
Etes vous certain de la configuration des règles sur Lan ? -
Pour le 127.0.0.1 , je ne trouve d'autre moyens de ne pas le retirer qu'en cochant la case.
Certes mais il ne s'agit pas de l'enlever absolument. Il s'agit juste de ne pas le définir expressément car pfSense l'ajoute par défaut.
Et pour l'adresse 10.33.0.1 … je ne sais pas d'où cela vient.
Mon LAN est en 192.168.0.0 et toutes les machines sont en ip statique (sauf la machine cliente de test).ma remarque va faire un peu "tatillon" mais cette IP en 10.33.0.1 ne parle pas au LAN. C'est dans le log du FW coté WAN et c'est bien ce qui est inquiétant.
Cette précision est importante: sans ce niveau de finesse (LAN vs. WAN) la lecture des logs devient très difficile :PPuisqu'une machine en interne est autorisée à parler à l'interface externe de pfSense et que la route pour l'atteindre est valide, il n'y a pas de raison de ne pas arriver à joindre une machine ailleurs sur le web, sauf si pfSense n'est pas la vraie interface physique entre le LAN et le WEB (par exemple un autre composant tel que le boîtier Numericable qui aurait une fonction autre qu'une simple passerelle.
-
Voici les tests :
Ping depuis l'outil PfSense et l'interface WAN
PING 216.58.211.99 (216.58.211.99) from 81.66.123.79: 56 data bytes
64 bytes from 216.58.211.99: icmp_seq=0 ttl=54 time=24.115 ms
64 bytes from 216.58.211.99: icmp_seq=1 ttl=54 time=22.932 ms
64 bytes from 216.58.211.99: icmp_seq=2 ttl=54 time=21.941 ms–- 216.58.211.99 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 21.941/22.996/24.115/0.889 msPing depuis l'outil PfSense et l'interface LAN
PING 216.58.211.99 (216.58.211.99) from 192.168.0.6: 56 data bytes
–- 216.58.211.99 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet lossPing depuis l'outil PfSense et l'interface WAN
PING www.google.fr (173.194.67.94) from 81.66.123.79: 56 data bytes
64 bytes from 173.194.67.94: icmp_seq=0 ttl=46 time=25.673 ms
64 bytes from 173.194.67.94: icmp_seq=1 ttl=46 time=28.372 ms
64 bytes from 173.194.67.94: icmp_seq=2 ttl=46 time=26.625 ms–- www.google.fr ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 25.673/26.890/28.372/1.118 msPing depuis l'outil PfSense et l'interface LAN
PING www.google.fr (173.194.67.94) from 192.168.0.6: 56 data bytes
–- www.google.fr ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet lossJe me suis penché sur le boitier Numéricable.
En mode bridge, son adresse est 192.168.100.1, sur d'autres articles, il est précisé que si des services ont été configurés, ce mode bridge n'est pas un vrai bridge car il peut bloquer des ports.
Je n'ai jamais configuré de service mais par acquis de conscience, je vais remettre en configuration d'usine et remettre en bridge.
Je réaliserais de nouveau les tests et reviendrais vous donner les résultats une fois ce problème résolu. -
1 - ce que montrent ces tests, c'est qu'un niveau DNS, la résolution de nom fonctionne ;)
2 - ça montre également que la suite va être très difficile car, sauf erreur de ma part, suite à pratiquement chaque message lors duquel tu décris quelques tests, tu signales également que tu vas reconfigurer ceci ou cela. Du coup, nous ne sommes jamais à périmètre constant pour analyser ce qui se passe en collectant des informations autres que le ping ;D Difficile donc de t'aider efficacement dans ces conditions ::)
3 - pour ma culture personnelle, je veux bien que tu m'expliques comment tu fais pour faire un
Ping depuis l'outil PfSense et l'interface LAN
Tu devrais essayer, au delà du ping, de nous montrer les routes sur les clients ;)
-
3 - pour ma culture personnelle, je veux bien que tu m'expliques comment tu fais pour faire un
Ping depuis l'outil PfSense et l'interface LAN
c'est Diagnostics|Ping voir image
je suis pas un spécialiste (corrigé moi si je me trompe) mais tant que le ping du lan de pfsense ne ping pas google c'est pas la peine d'essayer de configurer les clients ou les rules de pfsense
-
Je n'ai rien fais sur PfSense, j'ai juste remis le routeur en paramètre d'usine puis de nouveau en bridge.
De nouveau je tente de faire un ping avec l'outil de test "ping" dans PfSense mais, si cela fonctionne dpuis la patte WAN, , depuis la patte LAN de PfSense, le ping ne mène nul part :
PING 216.58.211.99 (216.58.211.99) from 192.168.0.6: 56 data bytes
–- 216.58.211.99 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet lossEn essayant un tracert sur le client windows configuré sur PfSense (via DHCP), le résultat est qu'il ne sait pas résoudre le nom d'hôte.
En essayant avec l'IP de Google, la requête atteint le serveur PfSense mais ne sait pas aller plus loin.Donc, quoi que soit les test, il apparait clair que la configuration de PfSense est mauvaise.
Il sait communiquer avec l'extérieur depuis sa patte WAN mais, impossible de faire transiter une information depuis le LAN.Pour preuve, même la mise à jour de PfSense ne trouve pas le chemin :
Downloading new version information…done
Unable to check for updates.
Could not contact pfSense update server https://updates.pfsense.org/_updaters/amd64Il y a donc bien quelque chose à configurer dans PfSense permettant de laisser passer le LAN vers le WAN … mais j'en reviens au point de départ, je ne sais pas ce qu'il faut configurer.
Voici la config par défaut pour les règles du parefeu en image jointe.
-
avec les outils de pfSense, peux-tu montrer les routes en IPV4 stp ?
-
Je ne suis pas sur de comprendre ce que tu demandes mais, voici ce que j'ai fait :
Menu Diagnostic > Routes (l'image en pj)
-
oui c'est très bien comme ça.
Si tu lis bien ce tableau, il te dit que la passerelle par défaut, c'est l'adresse LAN de pfSense. Si depuis le LAN tu cherches à joindre l'extérieur, il n'y a rien qui va sortir car pfSense, par défaut, va essayer depuis le LAN au lieu du WAN.C'est, ceci dit, très étrange si, comme je le suppose, tu as configuré pfSense avec le WAN en DHCP, ce qui lui ferait hériter de la passerelle fournie par le serveur DHCP de Numericable. Bien sûr à condition que tu ne définisses pas toi même manuellement une autre passerelle, ce qui n'aurait pas de sens.
Mais comme tu ne dis pas grand chose de ce que tu configures… :-X
-
En fait, justement, je n'ai rien configuré, c'est une installation fraiche sans paramètres particuliers.
Mais pour vous faire une idée, voici les infos dans les images jointes.
J'ai pu lire que sorti de l'installation, on peut déjà aller sur internet.Visiblement, j'ai mal lu ou alors, il me manque des billes pour la configuration.
J'aimerais faire de la configuration ensuite, affiner les règles du FW mais … tant que le client ne peut pas aller sur le web, je n'ai pas grand chose à affiner.
L'objectif est d'héberger à la maison un serveur de partage de fichiers (Synology), un serveur web et un serveur mail.Mais avant de permettre l'accès à mon réseau, j'aimerais à minima le protéger par un routeur F.W. et de ce que j'ai lu, PfSense est le plus complet.
Je compte même utiliser le Captive Portal et affiner les règles d'accès au web pour les enfants avec horaire et protection contre les sites qu'ils ne devraient pas découvrir avant qu'ils soient ados.Les serveurs sont prêt et fonctionnel via le routeur Asus sur un autre réseau (vous pouvez remarquer la différence entre l'ip Wan de PfSense et l'ip affiché sur mes posts).
Maintenant, comment et où dois-je configurer PfSense pour permettre de traverser le LAN et passer dans le WAN ?
Merci de votre patience.
-
J'ai oublié les passerelles ^^
(configuré par PfSense)
-
Je ne sais pas à quoi correspond la configuration "par défaut" mais il est évident, à la lecture de ces copies d'écran, que ça ne peut pas marcher.
Il ne peut y avoir qu'une seule gateway par défaut et dans ton cas, ce doit être celle associée à l'interface WAN.- Sur l'écran des interfaces, il ne devrait pas y avoir de gateway pour le LAN
- sur l'écran des gateways, la gateway par défaut devrait idéalement être WAN_DHCP
Bref, avec ce que tu montres, zéro change que ça fonctionne :-X mais j'ai du mal à comprendre pourquoi une installation "par défaut" de pfSense ferait ce genre de configuration. Ceci étant, c'est tellement naturel que lorsque j'ai configuré le mien, j'ai peut-être corrigé à la main ???
Le coté positif, c'est que maintenant qu'on a autre chose que "ping + je reconfigure et je vous tiens au courant", on sait pourquoi ça ne marche pas 8)
-
Merci, si j'avais su qu'il fallait des copies d'écran, j'aurais commencé par ça ^^
L'installation par défaut, c'est lorsqu'on met l'iso de PfSense, on lui donne l'ip LAN et on met DHCP en WAN et ensuite, il configure tout seul.
En fait, c'est le résultat que j'ai après "l'auto-configuration" de PfSense.Comme tu l'as indiqué, j'ai mis par défaut le Gateway en WAN_DHCP et j'ai retiré la passerelle pour le LAN (cf image en pj).
Et après de nouveau un test de ping, même résultat, ça ne passe pas.
Alors j'ai suivit un vieux conseil : dans le doute, reboot.Et désormais, ça fonctionne.
Le test de ping sur google.fr depuis le LAN m'affiche un résultat satisfaisant et ma machine cliente de test affiche les pages internet.Merci encore de votre patience et mes excuses de nouveau pour ma méconnaissance dans ce domaine.
Je vais pouvoir notifier ce "détail" dans ma procédure.Si je saisi bien, pas de passerelle pour le LAN et la route principale doit permettre d'atteindre le WAN dans l'écran Gatreway.
Et pour le DNS, désormais, je vais pouvoir installer Bind afin d'en avoir un complet.
Merci encore et bon courage pour l'aide que vous apportez aux autres (je sais combien ça peut être … rageant parfois).
-
Et pour le DNS, désormais, je vais pouvoir installer Bind afin d'en avoir un complet.
Je ne suis pas certain que ça présente un grand intérêt, en tous cas sur la machine pfSense.
-
Merci, si j'avais su qu'il fallait des copies d'écran, j'aurais commencé par ça ^^
Ce n'est pas tant une question de copie d'écran qu'une question d'expliquer ce qui est configuré.
La difficulté, c'est que le niveau d’explication à fournir dépend qu niveau de compréhension technique de celui qui explique (et de ceux qui tentent de comprendre de quoi il en retourne).Du coup, s tu ne sais pas qu'avoir 2 passerelles "par défaut" sur la même machine n'a pas de sens, ce n'est bien sûr pas quelque chose que tu vas mettre en avant dans tes explications 8)
-
Bind serait C'est pour la gestion de nom de domaine.
Je comptais utiliser PfSense comme serveur DNS esclave (ou primaire, je ne suis pas encore sur de ce point).Mais si tu trouves que ce n'est pas la bonne machine pour ça, j'utiliserais un autre serveur (c'est pas ce qui manque dans mon lan).
Et effectivement, sur le coup, ça ne me paraissait pas étrange … désormais, je saurais où regarder ;)
-
Bind serait C'est pour la gestion de nom de domaine.
en tant que DNS publique ?
Si c'est pour un DNS interne uniquement , Resolver ou Forwarder sont normalement suffisants sauf si tu as des besoins un peu spéciaux.
C'est clair que pfSense n'est absolument pas fait pour gérer un DNS publique mais est-ce bien ton besoin ?Mais si tu trouves que ce n'est pas la bonne machine pour ça, j'utiliserais un autre serveur (c'est pas ce qui manque dans mon lan).
Si tu as un besoin de "vrai" DNS et que tu as plein d'autres serveurs, Bind sur une autre machine c'est mieux. Surtout que vu ton niveau de compréhension des mécanismes réseau, tu risques d'avoir des surprises à faire autre chose sur pfSense que le strict minimum, même si techniquement ça va fonctionner sans problème.
-
Merci pour ton franc parlé.
Effectivement, je n'aurais pas de mal à te parler ordinateur, configurations d'une machine ou d'un parc de machine, site web et hébergeur et gestion d'un Active Directory (voir d'un Ubuntu) mais le réseau externe, même si je connais les principes de bases et que je me débrouille en LAN … le WAN, les DNS et tutti quanti ... c'est pas tout à fait mon point fort.Mais justement, j’apprends et j'avance sur le souhait d'avoir un réseau protégé et accessible par l'extérieur (pour le web, le mail, avoir mon propre DNS et accéder à mes machines de n'importe où).
Merci du conseil, je vais donc me pencher sur un DNS ailleurs.
-
Si l'idée est de disposer de ton propre nom de domaine (publique), il te faut, techniquement, absolument un DNS publique.
Mais là où tu as de la chance, c'est que tu ne peux pas déposer toi même ce nom de domaine auprès de l'IANA. Il te faut passer par un registar et celui-ci te fourni normalement l'interface pour gérer, sur ses propres serveurs, le domaine que tu as acquis.
De ce fait, tu n'es pas contraint de déployer ton propre serveur de nom publique.En interne, pour du serveur web, Resolver est suffisant.
Je ne suis pas certain par contre que la gestion d'enregistrements type MX (si tu veux un serveur de mail) soit accessible directement via l'interface sans gérer des options un peu spécifiques. -
Pour les noms de domaines, effectivement, c'est via le regitrar et on peut y modifier les entrées pour que les flux conduisent vers le serveur web.
De même pour le serveur mail, il suffit d'ajouter les entrées MX vers le bon sous domaine, lui même dirigé vers le serveur web (et son ip publique).Ce côté là fonctionne aussi déjà et, je vais peut être en rester aux redirections, vous avez raison.
Après tout, c'est le début, je vais déjà tenter de cerner, comprendre et mieux utiliser ce que j'ai déjà avant de me lancer à la conquête du web :p
-
Ce côté là fonctionne aussi déjà et, je vais peut être en rester aux redirections, vous avez raison.
D'autant que, si je comprends bien, ce dont nous discutions, c'est des serveurs hébergés chez…. un hébergeur et non pas sur ton LAN (ou une DMZ)
L'intérêt d'un serveur Bind, dans ce cas, est vraiment marginal voire nul, sauf à décrire chez ton registrar que le serveur DNS faisant foi pour ton domaine est ton propre serveur DNS, ce qui est prématuré (et peu utile pour des services externes uniquement) -
En fait, justement, tout est chez moi.
Mais les redirections depuis le registrar me permettent d'accéder aux serveurs à la maison.
Maintenant, il faut juste ouvrir les accès via PfSense pour les machines dédiés.