Résolu - Configuration PFSense (et Numericable en mode bridge)
-
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é)

 -
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 ;)