[clos] Pfsense 2.3 fraichement installé : aucun traffic LAN->WAN
-
Bonjour / bonsoir
Contexte : installation toute fraiche de Pfsence 2.3. sur réseau personnel / J'utilise Pfsense 1.2 depuis au moins 8 ans ?
Besoin : aide sur configuration car pas de traffic LAN vers internet (explications plus loin après schéma de l'infrastructure).
Schéma : Internet <–> Bbox (192.168.1.254) vers DMZ 192.168.1.2 (Pfsense) <--> LAN (192.168.0.x)
La Bbox est reliée en filaire à Pfsense 2.3
Pfsense est relié à un switch et derrière un nombre certain de stations/serveursCette configuration fonctionne avec un Pfsense 1.2.3 mais pas avec 2.3.
Maintenant les explications :
Je possède un Pfsense 1.2.3 qui tourne depuis des années et fait bien son travail MAIS le matériel commence à avoir des sautes d'humeur et plus de possibilité d'installer des paquetages. Du coup je fais l'acquisition d'un netbook pour remplacer cette machine.
Ce netbook utilise une interface ethernet pour recevoir le LAN, une interface USB vers ETH pour le WAN
les stations du LAN peuvent communiquer avec Pfsense (webconfigurator / nslookup / ping )
Pfsense peut avoir accès à internet (mise à jour 2.3.1 effectuée il y a 30 minutes, installation de paquetages possible)mais là où ça devient marrant c'est que les stations du LAN n'ont pas accès à internet ( nslookup www.google.fr répond mais pas http://www.google.fr), elles n'arrivent même pas à pinguer la box d'ailleurs.
Ceci avec une première tentative avec NAT/RULES configurées comme sur pfsense 1.2.3, comme ça ne fonctionnait pas j'ai fait un reset to factory defaults, comme ça ne fonctionnait pas j'ai fait une update vers 2.3.1, comme ça ne fonctionne pas j'ai ajouté une règle firewall "pass from any lan to any".
en regardant le syslog, il me bloque tout traffic en provenance du LAN ...
je suis perdu.
Si vous avez le temps et la volonté de m'aider je peux faire des captures d'écrans à volonté.
Merci aux bonnes volontés ;)
-
en regardant le syslog, il me bloque tout traffic en provenance du LAN …
Nois avons déjà a priori un diagnostic correct. Avez vous vérifié le masque configuré sur l'interface Lan ? /24 ?
-
Est-ce que fortuitement, l'option de blocage des réseaux "RFC1819" ne serait pas activée dans la définition de l'interface LAN ? 8)
-
Salut salut
Coté lan as tu accès à l'interface web d'administration du pf ou c'est du coté wan ?
Si c'est sur le wan, inverse tes branchements et ou le choix des cartes réseaux dans l'interface console du portable.
Si c'est sur le wan et une fois que tu as accès à l'interface web du pf regarde comme l'a indiqué chris4916 si tu ne bloquerais pas le trafic (les 2 cases du bas) sur l'interface voulu.
autre chose au quelle je pensais , si avec la version 1.xx tu as accès à ton interface web via la carte voulu, fait une monté de version par version (télécharger les updates qui doivent etre dispo) et non pas par l'updater automatique) cela pourrait permettre de voir à partir de quelle version de pf c'est la bazar pour toi.
Cordialement, au plaisir de te relir sur smpfr
-
Bonjour et merci pour vos réponses.
J'ai passé ma nuit dessus aussi je sors à peine du canapé là et je n'ai que deux cafés dans le sang je vais essayer de répondre sans faire de fautes.
Je vous donne des détails ensuite je réponds aux questions qui n'auraient pas été répondues par image.–----
Hier soir/nuit j'ai fait un reset to factory defaults pour être sûr de partir sur une bonne base après toutes mes manipulations.
Puis je décide en désespoir de cause de suivre la check list pour ce problème connu (google me dit que nous sommes des dizaines à éprouver des difficultés similaires)
check list officielle : https://doc.pfsense.org/index.php/Connectivity_TroubleshootingCheck that the WAN IP address is correct (Interfaces > WAN)
- Using the wrong address could cause a failure of the ISP to deliver traffic to/from the firewall, among other issues
Check that the WAN IP address has the correct subnet mask (Interfaces > WAN)
- An improper subnet mask such as /1 could cause connectivity issues to large portions of the Internet, using /32 for a mask can prevent the gateway from being found/used
Check that WAN has a gateway and that the gateway IP is correct (Interfaces > WAN)
- This will interfere with automatic outbound NAT and route-to/reply-to handling
Check that the WAN gateway is set as default (System > Routing)
- Without a default gateway traffic has no exit path
Je décoche volontairement les 'block' pour maximiser les chances
Check that the WAN gateway shows Online (Status > Gateways)
- If it is not, verify the WAN settings and gateway settings, or use an alternate monitor IP
Verify that the defined WAN gateway is actually the default (Diagnostics > Routes)
- Some other source such as a VPN may have changed the default gateway
Check that the LAN IP address is correct (Interfaces > LAN)
- Using an invalid IP address (e.g. .0 or .255 in a /24) will cause problems reaching addresses locally and will not work properly.
Check that the LAN subnet mask is correct (Interfaces > LAN)
- Using an incorrect subnet mask, such as /32, will prevent other hosts in LAN from finding the LAN to use as a gateway and vice versa
Check that LAN does NOT have a gateway set (Interfaces > LAN)
- This will interfere with automatic outbound NAT
Check that LAN does NOT have "Block Private Networks" set (Interfaces > LAN)
- Should be obvious
Check that LAN does NOT have "Block Bogon Networks" set (Interfaces > LAN)
- See above
Check the firewall log for blocked connections from the LAN (Status > System Logs, Firewall tab)
- If blocks are observed, check the rule that blocked and adjust rules accordingly (Firewall > Rules, LAN tab)
J'ai oublié de faire une capture d'écran, mais dans un premier temps j'avais des BLOCK puis en manipulant j'avais des PASS mais sans résultat coté clients LAN qui demandaient du HTTP/FTP/etc.
par défaut toutes les communications entrantes vers WAN sont bloquées, du coup je crée une règle
Mais ça ne passe pas mieux.Check that the LAN rule allows all protocols, or at least TCP and UDP ports for reaching DNS and HTTP/HTTPS, and allows ICMP for testing. (Firewall > Rules, LAN tab)
- Not allowing UDP would make DNS fail, among other things. Similarly, on a DNS rule, using UDP only and not TCP/UDP will cause larger queries to fail.
- Not allowing ICMP would cause ping to fail, but other protocols may work
- Not allowing TCP would cause HTTP, HTTPS, and other protocols to fail.Check that the LAN rule allows to a destination of any (Firewall > Rules, LAN tab)
- Traffic going to the Internet will need an "any" destination. Using the wrong destination would not allow traffic to reach the Internet (e.g. "WAN net" which is only the subnet of the WAN interface, NOT the Internet.)
Check that the LAN rule does not have an improper gateway set (Firewall > Rules, LAN tab)
- If it is set to leave by some other (possibly broken) non-WAN gateway it would cause the connections to fail
Check Outbound NAT, ensure it is set for Automatic Outbound NAT unless Manual is required (Firewall > NAT, Outbound tab)
- Incorrect NAT settings will prevent traffic from reaching WAN
Check Manual Outbound NAT rules, if in use, to ensure that the source of local traffic is matched
- Incorrect NAT settings will prevent traffic from reaching WAN
Comme je ne voyais pas ce que le loopback venait faire là j'ai changé d'option outbound (testé les 4) et parfois j'avais des 'PASS' sur le LAN mais sans plus de résultat (PF dit que ça PASS mais le client PC n'arrive à rien). Suis resté en auto pour le coup.
Check connectivity from the firewall itself: Try to ping 8.8.8.8 (Diagnostics > Ping)
- If this does not work, ensure proper WAN settings, gateway, etc.
Check DNS: Try to lookup pfsense.org (Diagnostics > DNS Lookup)
- If this does not work, fix/change the DNS servers on System > General
Test NAT: Try to ping 8.8.8.8 (Diagnostics > Ping) using LAN as the Source Address
- If this fails but the other tests work, then the problem is likely Outbound NAT (See the WAN/LAN gateway checks above)
En revanche Tracert ne sort pas de la box ??
Test if the client can ping the LAN IP of the firewall
- If this fails, check the LAN rules, client IP/subnet mask, LAN IP/subnet mask, etc.
Test if the client can ping the WAN IP of the firewall
- If this fails, check the client's subnet mask and gateway
Test if the client can ping the WAN Gateway IP of the firewall
- If this fails, check the client's subnet mask and gateway, and double check Outbound NAT on the firewall
Test if the client can ping an Internet host by IP address (e.g. 8.8.8.8)
- If this fails, check the client's subnet mask and gateway, and triple check Outbound NAT on the firewall
Test if the client can ping an Internet host by Host name (e.g. www.google.com)
- If this fails, check the client's DNS settings, and/or the DNS Forwarder on the firewall (Services > DNS Forwarder, Diagnostics > DNS Lookup)
ping patte LAN de PF:
ping patte de la box:
ping IP internet :
ping IP internet avec résolution de nom:
If Captive Portal is enabled, temporarily disable it (Services > Captive Portal).
- See Captive Portal Troubleshooting if that helps.
Check for packages such as Squid that might interfere, disable them if necessary
- Improperly configured proxies would allow certain traffic such as ICMP ping to work but might prevent access to HTTP and/or HTTPS sites.
pas de portail captif ni de squid.
–----
un exemple coté client, résolution et ping OK mais HTTP ne passe pas
accessoirement un extrait de log (non filtré désolé) où l'on voit que tout ce qui arrive sur la patte WAN (192.168.1.2) de PF est bloqué (même une entrée sur le port 80 qui est explicitement RULée et NATée).
–----
maintenant je réponds aux questions :
Avez vous vérifié le masque configuré sur l'interface Lan ? /24 ?
oui :) (voir capture d'écran config LAN au dessus)
Est-ce que fortuitement, l'option de blocage des réseaux "RFC1819" ne serait pas activée dans la définition de l'interface LAN ?
non, j'ai même désactivé cette option sur WAN 'au cas où' même si il n'y aucune logique.
Coté lan as tu accès à l'interface web d'administration du pf ou c'est du coté wan ?
coté LAN, car je ne l'ai pas ouvert en WAN je n'ai encore mis aucune règle 'PASS' from WAN sur HTTPS.
Si c'est sur le wan et une fois que tu as accès à l'interface web du pf regarde comme l'a indiqué chris4916 si tu ne bloquerais pas le trafic (les 2 cases du bas) sur l'interface voulu.
vérifié ;)
autre chose au quelle je pensais , si avec la version 1.xx tu as accès à ton interface web via la carte voulu, fait une monté de version par version (télécharger les updates qui doivent etre dispo) et non pas par l'updater automatique) cela pourrait permettre de voir à partir de quelle version de pf c'est la bazar pour toi.
Mon Pfsense 1.2 et ce 2.3 sont deux machines distinctes, et heureusement car si je n'avais pas gardé mon 'vieux' 1.2 je n'aurais plus internet actuellement :)
-
Je n'ai lu qu'en diagonale ton long post et ce que je vois, c'est que tu arrives, depuis le LAN, à faire un ping sans soucis.
Ton extrait de log et les règles de FW que tu montre sont "intéressants" :- à mon sens, il n'y a pas de raison de ne pas bloquer ce qui viendrait sur la patte WAN, sauf si tu héberges des services sur le LAN
- la règle qui autorise sur le WAN ce qui est a destination du LAN en 192.168.0.0/24 ne sert à rien: si tu héberges un service sur le LAN, il faut faire un forward depuis l'IP WAN de pfSense (sauf si tu as des machines sur le segment WAN qui auraient une route vers le LAN avec comme gateway l'IP WAN de pfSense mais c'est un peu tordu.
la seule vraie surprise du log, c'est des broadcast depuis une machine Windows en 192.168.1.3 (donc sur le WAN)
-
est-ce que la reformulation "courte" du problème, ce n'est pas :
" j'arrive à faire des ping mais le browser n'accède à aucun site " ? -
Salut saut
Est ce que cela te le fait avec tous les navigateurs quelques soit l'os ?
autre piste, faire une install via la 1.2
-
faire un installation propre et tes param de base voir si tu passe sur le web depuis le lan
-
faire une monté de version par les packages à la main, entendre par la les télécharger et les uploader via l'iso update ou usbstick update https://www.pfsense.org/download/mirror.php?section=updates
-
faire les tests si passe mieux
si l'upgrade de la 1.2 à 2.3.1 ne se fait pas correctement, télécharge l'une des version 2.xx et refait les tests.
Je suis persuadé que cela vient d'une librairie ou une merdouille qui ne se pose pas correctement.
Cordialement.
-
-
- à mon sens, il n'y a pas de raison de ne pas bloquer ce qui viendrait sur la patte WAN, sauf si tu héberges des services sur le LAN
- la règle qui autorise sur le WAN ce qui est a destination du LAN en 192.168.0.0/24 ne sert à rien: si tu héberges un service sur le LAN, il faut faire un forward depuis l'IP WAN de pfSense (sauf si tu as des machines sur le segment WAN qui auraient une route vers le LAN avec comme gateway l'IP WAN de pfSense mais c'est un peu tordu.
la seule vraie surprise du log, c'est des broadcast depuis une machine Windows en 192.168.1.3 (donc sur le WAN)
hop. Je n'ai encore paramétré aucune RULE/NAT autre que celle montrée au dessus juste pour que WAN ne soit pas en BLOCK all.
Sinon j'ai un certain nombre de rules car effectivement j'héberge un certain nombre de services sur le LAN (HTTP/SFTP/MAIL/VNC/SSH/etc.) pas sur le WAN car je veux bien sûr que seuls les ports ouverts sur ces services soient exposés ;)pour le braodcast 192.168.1.3 ne pas en tenir compte c'est un serveur NAS branché à la Bbox qui me sert à lire des vidéo via DLNA pour portables/tablettes/tv/playstation, j'ai un certain nombre d'appareils directement sur la bbox (tv,playstation,nas, décodeur C+) et je n'ai pas exposé cela car c'est hors de propos pour mon problème, donc oui dans les logs ont voit des remontées de machines depuis 192.168.1.x ;)
-
est-ce que la reformulation "courte" du problème, ce n'est pas :
" j'arrive à faire des ping mais le browser n'accède à aucun site " ?ça aurait pu, mais je n'arrive pas à ouvrir un tunel VPN vers un de mes sites distants, pas de FTP, pas de SSH, pas de VNC, rien quoi :)
-
Salut saut
Est ce que cela te le fait avec tous les navigateurs quelques soit l'os ?
testé sous opensuse / Suse Linux entreprise / Debian quels que soient les navigateurs et accessoirement clients FTP/VNC/MAIL
autre piste, faire une install via la 1.2
-
faire un installation propre et tes param de base voir si tu passe sur le web depuis le lan
-
faire une monté de version par les packages à la main, entendre par la les télécharger et les uploader via l'iso update ou usbstick update https://www.pfsense.org/download/mirror.php?section=updates
-
faire les tests si passe mieux
si l'upgrade de la 1.2 à 2.3.1 ne se fait pas correctement, télécharge l'une des version 2.xx et refait les tests.
Je suis persuadé que cela vient d'une librairie ou une merdouille qui ne se pose pas correctement.
Cordialement.
Ok, il me reste peu de temps avant déplacement sous peu, il faut que je récupère tous les ISO de 1.2 à 2.3, vais voir si c'est encore possible. Je ne pense pas avoir le temps de faire cela avant mon départ :/
-
-
Salut salut
Fait de ton mieux.
On se tient au courant ^^
cordialement.
-
ça aurait pu, mais je n'arrive pas à ouvrir un tunel VPN vers un de mes sites distants, pas de FTP, pas de SSH, pas de VNC, rien quoi :)
Pas tout à fait rien puisque ICMP passe….
Que FTP ne marche pas, je ne suis pas surpris.
Pour HTTP, c'est quand même surprenant... surtout avec un comportement pareil qui ressemble à un problème de route plutôt qu'à un problème de FW.
Lorsque tu fais ces tests, ton premier FW (en 1.2) est bien déconnecté du réseau ? :-X -
En effet puisque les interfaces LAN & WAN ont la même IP histoire que je ne m'amuse pas à reparamétrer les clients à chaque fois.
-
Bonjour,
Perso, je ferais un test en baissant le MTU à 1492 voir moin (même si liaison filaire avec la box).
Si j'ai bien suivi, le wan est un dungle eth/usb, avez vous tester avec un autre modèle (drivers + ou - compatible ?)
Le netbook doit surement embarquer une carte wifi ? Pour test, vous pouvez la configurer en wan.
-
C'est une bonne idée. Merci.
-
Bonjour
franche rigolade il y a 5 minutes après 3h d'énervement :
J'installe PF 1.2 : ne reconnait pas la carte réseau Realtek integrée et encore moins le dongle USB
Je passe à la version 2.0.1 : idem
v2.1 : interface réseau OK mais même pas de NSlookup depuis PF
V2.2 : idemje fais une bête manipulation que je n'avais pas encore faite jusqu'a présent : j'assigne le LAN sur l'USB et le WAN sur l'eth intégrée : pas mieux et même pire :
Alors que je peux pinguer la patte réseau sur USB, je ne peux même plus avoir accès au webconfigurator de PF ?!!
En gros cette cochonnerie ne laisse passer que l'icmp et j'en perd mon latin. (quand PF était en 2.3.1 nslookup passait) Un problème de drivers je suppose (adaptateur eth vers USB "Edimax" http://www.edimax.fr/edimax/merchandise/merchandise_detail/data/edimax/fr/network_adapters_usb_adapters/eu-4208/ )Au moment où je vous écris je DL PF2.3 pour pouvoir tester LAN sur eth et WAN sur Wifi … (car PF 2.2 ne me voit pas l'interface wifi).
dingue ...
-
PF 2.3 installé
LAN (eth) et WAN(wifi) configurés et … je vous écris en passant à travers ce PF.Donc navré pour tout ça, c'était l'adaptateur USB qui était en cause, pourtant j'en utilise deux autres sur mon réseau et ils fonctionnent correctement (pas sur du BSD cependant ;) )
Merci à tous pour avoir jeté un oeil attentif.
-
Bon, ça n'aura pas tenu longtemps. Freeze du netbook quand trop de trafic passe entre le LAN (ethernet) et le WAN (wifi).
Solution en cours de test : Netbook sous WinXP + VMWare server + Pfsense vitualisé (pour pouvoir utiliser le dongle USB). -
Un bon vieux desktop PIV de récup peut facilement monter à 1 ou 2 go de ram, 1 ou 2 carte réseau en pci et vous avez une bonne machine pour un usage domestique ;)
