Discussion :

[Olivier Regnier]

Bonjour

Je viens de commencer la configuration de packet filter sous openbsd.

J'ai activé l'animal dans /etc/rc.conf.local :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
pf=YES
pf_rules=/etc/pf.conf.local

Pour reprendre à zéro mes règles de filtrage, je me suis dit, on va commencer par tout bloquer :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
set block-policy drop
scrub in all
block all

Ensuite, j'ai redémarré ma machine, donc pf est bien activé, le fichier de règles testés (3 lignes ) figurez-vous que mon routeur a réussi à m'adresser une adresse IP par contre, si je le ping, j'obtiens "no route to host".

Quel est le problème ? Est-ce le fonctionnement normal ? Bloquer tout veut bien dire ce que cela veut dire. Dans ce cas, pourquoi le routeur arrive à m'adresser une adresse IP ?

Merci d'avance

[gorgonite]

es-tu sûr que pf démarre avant la requête dhcp ?

[Olivier Regnier]

es-tu sûr que pf démarre avant la requête dhcp ?

Oui, il démarre avant

[gorgonite]

perso, j'avais déjà rencontré un problème similaire avec iptables, mais sur un serveur dhcp... je n'avais pas ouvert le port (et tout bloquer par défaut), et pourtant les clients réussissaient à récupérer une adresse

[Olivier Regnier]

Je me suis renseigné sur la mailing liste d'OpenBSD et voici la réponse obtenue:

Ceci n'est qu'une supposition.
Les échanges entre le client et le serveur DHCP se font par l'adresse de
broadcast (donc non routable par nature) et non par une adresse ip
définie (routable).
L'attribut "no-route" doit faire que les messages DHCP ne sont pas
bloqués par tes règles.
Si tu venais à changer "no-route" par "any", peut-être que même le
dialogue DHCP serait bloqué.

Il faut maintenant tester

[julp]

pfctl -sa (ou -sr) te renvoyait bien tes règles ?

Sinon dans ces cas-là, le plus sage est de regarder ce qu'il se passe au niveau du filtrage (après avoir fait mention de l'option log au niveau des règles concernées)

[Olivier Regnier]

Le fonctionnement est tout à fait normal du moins avec pf.

Il faut jeter un oeil à /etc/rc:Au boot, si pf != NO, alors open charge des règles génériques, puis configure les interfaces (donc le dhcp) puis charge ensuite les règles $pf_rules. Voilà donc la raison.Ca permet si j'ai bien compris les règles génériques, d'avoir un accès uniquement ssh (et port 53 ?) à la machine si jamais le chargement de pf.conf rate.

Donc, pas de soucis, je retourne donc dans ma config

[oberfaulersgeist]

bonjour tous le monde, je ne sais pas si on a déja résolu ce pb mais je pense que le pb ne vient pas du packet filter, car normalement si c le cas, on doit t'afficher "operation not permited" (bon j'etais sous freebsd) dans le cas si ton PF ne le permet pas, mais le message no route to host est un problème de la table de routage, par exemple la route par défaut doit être spécifié (bon tu utilise dhcp donc elle doit exister dans la table de routage du noyau). ce que je peu te suggérer c'est d'essayer de pinger mais sans activer le PF, et vérifier les tables de routage et l'adressage:

tout dabord, vérifie si tes règles que tu a spécifié ton celle qui sont chargé avec la commande: pfctl -sr
tu dois normalement n'avoir qu'une seule ligne qui contien "block all", après tu suis les étapes suivantes:

pfctl -d # désactive pf
ifconfig -a #vérifie que ta carte réseau a eu son @ip
netstat -rn #affiche la table de routage et regarde si tu a eu ta route par défaut
ping ma_passerelle
ping ip_fai

si le pb persiste alors c'est plus un pb de PF.
bonne chance