DNS forwarder

[wr35nn89]

bonjour à tous,
je viens de remplacer un ipcop vieillissant par un pfsense 2. Je suis passé directement version 2 car je ne suis pas affecté par les bugs en cours au niveau de mes besoins et parce qu'il me fallait le support des chipset ax88178.
J'ai donc une livebox, branchée sur le port WAN de mon pfsense (en static). Dans l'onglet 'general setup', l'adresse du serveur dns est l'adresse de la box (je n'ai pas mis de gateway pour ce serveur dns et j'ai décoché la case "Allow DNS server list to be overriden by dhcp/ppp on WAN").
Mon lan n'a pas de dhcp. Tous les clients sont en ip fixe avec l'adresse LAN du pfsense comme serveur DNS. Tout le LAN accède bien au net.
Le DNS Forwarder est activé.
J'ai aussi une DMZ et un réseau WIFI.
Sur mon réseau WIFI, j'ai branché un point d'accès sur la patte WIFI du pfsense. Le point d'accès ne fait pas DHCP, il se contente de publier le SSID.
Donc, j'ai activé le serveur DHCP au niveau de ma patte WIFI. Quoi que je mette (valeurs ou rien) dans le champ 'DNS servers' de mon dhcp, mes clients WIFI en dhcp ne récupèrent pas l'adresse du DNS......
Je me demande si le souci vient du pfsense ou du point d'accès (mais je n'ai pas touché à la config de l'AP et il fonctionnait correctement avec l'Ipcop). Que puis-je avoir oublié???
Merci d'avance pour toute info.

[jdh]

(Un peu d'aération faciliterait la lecture)

Le dhcp pour une zone fonctionne sans difficulté avec pfSense 2.0 BETA.
L'adresse de serveur dns est forcément le firewall pfSense (l'adresse de l'interface).
Je ne vois pas cela ne pas fonctionner : investigation à faire à coup de "ipconfig /all" et "nslookup".

Je suppose que l'AP est un routeur dont la patte WAN n'est pas utilisé. Normalement il ne joue pas dans ce genre de config.


Même si l'adressage fixe semble plus sûr, aujourd'hui le dhcp est presque obligatoire, ne serait ce pour les portables.
Le bon compromis est du "DHCP statique" : pour chaque PC une réservation dhcp ! C'est exigent, très exigent mais cela fonctionne bien.


NB : pfSense 2.0 est en BETA, ni en STABLE ni même en RC. Il est logique que certaines fonctions ne tournent pas comme attendu. Mais ce n'est pas le cas de DNS forwarder ou de DHCP.

[wr35nn89]

Merci pour ta réponse.

Oui, je sais que la version 2 de pfsense est en béta. Mais comme je l'ai indiqué, j'ai fait le tour des bugs ouverts et je n'ai rien trouvé qui pouvait m'affecter.

L'AP ne fait pas routeur. Il est juste AP (pas de port WAN). Je n'ai pas plus regardé sa config, car cela fonctionnait très bien avec IPCOP.

J'ai testé ce que j'ai pu à l'aide de ping, ipconfig et nslookup. Déja, il m'a fallu autoriser l'ICMP sur la patte wifi..... Des machines en wifi, je ping bien la patte wifi du pfsense. Par contre, je n'ai pas essayé le ping sur la patte WAN..... Le nslookup ne me remonte rien, car les postes wifi n'ont pas de serveur dns d'attribué.....

D'après toi, la config devrait fonctionner ? je ne vois pas très bien où ça pèche.....

D'accord avec toi sur le dhcp statique, mais dans ce cas précis, le wifi n'est là que pour les besoins d'une salle de formation qui reçoit des personnes itinérantes..... donc pas possible de gérer des dizaines et des dizaines de clients (surtout qu'il n'y a personne sur site pour le faire ; faut que ça fonctionne tout seul la majorité du temps....).

Je vais y retourner à tête reposée et essayer de voir.....

[jdh]

Le premier test à faire est "ipconfig /all" qui indique le serveur dns fourni.

Pour l'organisation dhcp statique, il va de soi qu'il faut laisser 10 @ip "ouvertes".
Mais, si j'étais nickel sur les réservations, les @ip ouvertes ne devraient être qu'occasionnelles.

[wr35nn89]

Bon, c'est résolu....
En fait, je pensais qu'activer la case "DNS Forwarder" l'activait sur tous les réseaux.... mais non.
J'ai donc créé une rêgle sur le sous réesau dédié au wifi qui autorise les requêtes dns à sortir, et c'est bon.
Edit : je viens de comprendre mon erreur : le DNS forwarding permet de faire suivre les requètes DNS au niveau au dessus, mais pour ça, il faut qu'elles arrivent à pfsense.... d'où l'utilité de la règle (vu que sur le LAN par défaut, tout sort)

Pendant que j'y suis, j'ai une autre question :

Je cherchais à restreindre l'accès à l'interface d'admin de pfsense depuis mon réseau wifi, donc j'ai fait la règle suivante :

Reject TCP WIFI (port *) IPpfsense (port *)

Je rejette sur le sous réseau WIFI tout ce qui essaie de sortir en TCP sur n'importe quel port et qui cherche à accéder à l'interface LAN de pfsense (sur n'importe quel port). Et bien, ça passe quand même en 80....
Si je modifie ma règle en nommant le port 80 sur l'interface LAN de pfsense, ça me bloque bien le port 80....
Bizarre, non ?

Et je ne comprends pas bien l'intérêt des alias WAN adress et LAN adress, par exemple..... y'a pas grand chose dans le guide à ce sujet....
En gros, j'aimerai que mon réseau wifi ne puisse que sortir vers internet et pas aller fouiller du côté de la DMZ ou de mon LAN...... mais je n'ai pas bien compris comment faire.....
Merci d'avance.

[jdh]

Et bien on est loin du minimum de compréhension/connaissance nécessaire à une mise en oeuvre en sécurité de pfSense !

- "activer la case "DNS Forwarder" active sur tous les réseaux" :
Cela active juste la fonctionnalité au niveau du serveur !
Et si on ne créé pas une règle qui autorise l'accès à pfsense sur le proto dns, cela ne risque pas de fonctionner.
Le point clé c'est de décrire chaque besoin puis de créer la règle correspondante !

- "Reject TCP WIFI (port *) IPpfsense (port *)"
Deux principes de base : juste les règles nécessaires et pas de règle "tout autorisé".
Si on veut supprimer un accès donné, on précise dans une règle d'interdiction au moins le port !

- les onglets dans "Rules" désigne l'interface d'arrivée du paquet initial
Une machine en Wifi, qui initie un trafic , doit avoir une règles dans l'onglet Wifi et pas ailleurs.

- Les alias WAN Address et LAN Address ?
Leur valeur est ... évidente. L'usage est évident.
Si pfSense est relais DNS, il y a forcément un règle de LAN pour accéder à LAN Address.
Et la même chose pour ntp, ping, l'admin, ... (squid)
L'utilisation des alias est énorme de puissance ... sous réserves que l'on prenne de bonnes habitudes en normant les noms d'alias !

- bloquer wifi vers lan et dmz ?
Facile, on utilise LAN/DMZ subnet !
Perso, je créé les alias "lanLAN" et "lanDMZ" et les règles sont évidentes ...

Il y a du boulot ! Il y a de la doc sur le site de pfSense ...

[wr35nn89]

Merci pour ta réponse.

- "activer la case "DNS Forwarder" active sur tous les réseaux" :
Cela active juste la fonctionnalité au niveau du serveur !
Et si on ne créé pas une règle qui autorise l'accès à pfsense sur le proto dns, cela ne risque pas de fonctionner.
Le point clé c'est de décrire chaque besoin puis de créer la règle correspondante !

Oui, ça y est, j'ai compris. Je pensais que le fait de cocher la case DNS Forwarder créait la règle automatiquement sur toutes les pattes......

- "Reject TCP WIFI (port *) IPpfsense (port *)"
Deux principes de base : juste les règles nécessaires et pas de règle "tout autorisé".
Si on veut supprimer un accès donné, on précise dans une règle d'interdiction au moins le port !

OK, mais je pensais aussi tout simplement (mon deuxième prénom, c'est Candide) que le fait d'interdire tous les ports était possible. (si ça peut éviter de créer autant de règles que de ports ouverts sur la machine de destination....)

- les onglets dans "Rules" désigne l'interface d'arrivée du paquet initial
Une machine en Wifi, qui initie un trafic , doit avoir une règles dans l'onglet Wifi et pas ailleurs.

Oui, oui. Ca j'ai bien compris, sinon je n'aurai pas réussi à faire causer le wifi avec le reste. J'ai du mal m'exprimer dans mon message initial.

- Les alias WAN Address et LAN Address ?
Leur valeur est ... évidente. L'usage est évident.
Si pfSense est relais DNS, il y a forcément un règle de LAN pour accéder à LAN Address.
Et la même chose pour ntp, ping, l'admin, ... (squid)
L'utilisation des alias est énorme de puissance ... sous réserves que l'on prenne de bonnes habitudes en normant les noms d'alias !

Ben non, bien que tu puisses penser que c'est évident, il n'en est rien. J'ai acheté le "definitive guide to pfsense" et j'ai bien analysé tout le chapitre des règles, et il n'y a rien de bien exceptionnel de noté (je ne l'ai pas sous la main, mais je te garantis que ce n'est pas clair).
J'ai essayé de comprendre en créant des règles qui se servent de ces fameux alias (WAN Address et LAN address), mais je n'ai pas trouvé mon bonheur.
WAN address correspond à quoi ? à l'adresse WAN du pfsense ? ou toute adresse qui se trouve sur le WAN ?
Je vais y regarder plus en détail et créer des alias pour le serveur web qui est en DMZ. Ce sera effectivement plus facile à mettre en oeuvre.
Ah oui, et puis sur le LAN, pour le moment, je ne filtre pas en sortie. Donc il y a juste une règle 'tout sort' en plus de la règle 'anti lockout'.

- bloquer wifi vers lan et dmz ?
Facile, on utilise LAN/DMZ subnet !
Perso, je créé les alias "lanLAN" et "lanDMZ" et les règles sont évidentes ...

OK, je n'y avais pas pensé. Je vais regarder ça de plus près.

Il y a du boulot ! Il y a de la doc sur le site de pfSense ...

Si je suis là à poser des questions, c'est parce que le sujet m'intéresse et que je veux rendre service à une association près de chez moi. Je n'ai pour ainsi dire jamais mis en oeuvre de firewall..... je suis admin système..... et dans ma boite le système est totalement dé-corrélé du réseau. (si, si, c'est possible).
J'ai schématisé tous mes flux avant de me lancer dans la configuration du bousin. Il me reste à fignoler quelques règles et à sécuriser l'ensemble (pour l'instant j'ai toujours une livebox pro en tête de WAN avec le firewall actif).

Enfin, tout ça pour dire que je te remercie pour tes réponses. J'en connais qui, en plus de la première remarque un poil désobligeante, se seraient contentés de brailler un gros RTFM.
Merci encore.

[jdh]

Un dessin, c'est bien, c'est utile pour se représenter la "géographie".

Un tableau avec
- en ligne, les interfaces (de départ),
- en colonne, les interfaces (d'arrivée),
- en cellule, la liste des protocoles validés ou interdits (et, le cas échéant), à quelle machine cela s'applique),
c'est aussi très bien.

Pour pfSense, ce qui me parait essentiel c'est les alias, car cela facilite la lecture (et la rédaction du tableau !).