Le DHCP Relay ecoute sur l'interface du DHCP.

maxty01

Bonjour à tous,

Je souhaiterai rouvrir ce sujet (en anglais).

Tout d'abord, laissez moi me présenter:

Je suis un jeune Administrateur Réseaux et Systèmes passionné qui ne manque pas de connaissances et qui a déjà acquis une certaine expérience au niveau de la VoIP, le monitoring, l'infrastructure, les réseaux ainsi que les différents Systèmes tel que Linux et Windows.

Je suis certifié Linux LPIC-1 et je suis actuellement employé en tant que Open Source System Engineer en Belgique.

Si besoin d'autres informations, n'hésitez pas à me demander.

Les infos à savoir :
Environnement : perso/labo
Pfsense version : 2.1.4
Matériel utilisé : FW7541 version D
Wan : 2
Lan : 3

Tout comme dans le sujet en anglais, j'ai configuré le DHCP-relay pour transmettre les DHCP REQUESTs de mon Vlan "Guest" vers mon serveur DHCP dans mon LAN.
Après quelques heures, j'ai remarqué que mon DHCP avais un comportement anormal.
Ayant fait une maintenance de mon réseau (pfsense, dhcp, vlan, …), j'ai commencé à investiguer du coté de mon DHCP, sans résultat.
J'ai donc analysé mon réseau et c'est là que j'ai remarqué que le DHCP-relay renvoyais les DHCP REQUESTs de mon LAN vers mon serveur DHCP.

  0.000000      0.0.0.0 -> 255.255.255.255 DHCP DHCP Request  - Transaction ID 0xd4fcbe1e
  0.000181 192.168.126.254 -> 192.168.126.1 DHCP DHCP Request  - Transaction ID 0xd4fcbe1e
  0.044665 192.168.126.1 -> 192.168.126.5 DHCP DHCP ACK      - Transaction ID 0xd4fcbe1e
  0.102254 192.168.126.1 -> 192.168.126.254 DHCP DHCP ACK      - Transaction ID 0xd4fcbe1e

En analysant les logs dhcp de pfSense, j'ai découvert ceci :

Dec 7 13:42:30 	dhcrelay: Sending on BPF/em0_vlan16/00:90:0b:30:2f:96
Dec 7 13:42:30 	dhcrelay: Listening on BPF/em0_vlan16/00:90:0b:30:2f:96
Dec 7 13:42:30 	dhcrelay: Sending on BPF/em0/00:90:0b:30:2f:96
Dec 7 13:42:30 	dhcrelay: Listening on BPF/em0/00:90:0b:30:2f:96

Comme le signale "jimp", pfSense est confuré pour fonctionner comme cela :
@jimp:

IIRC it needs to do that because in some cases the replies from the upstream server may not be directed back at the IP as expected, so by listening on that interface it can receive broadcast traffic there as well.

J'ai donc changé une partie de ma configuration pour que le VLAN16 ne passe plus par em0 en taggé, mais par em1 en non taggé.
Mais cela n'a pas changé le problème :

Dec 7 15:38:37 	dhcrelay: Sending on BPF/em1/00:90:0b:30:2f:97
Dec 7 15:38:37 	dhcrelay: Listening on BPF/em1/00:90:0b:30:2f:97
Dec 7 15:38:37 	dhcrelay: Sending on BPF/em0/00:90:0b:30:2f:96
Dec 7 15:38:37 	dhcrelay: Listening on BPF/em0/00:90:0b:30:2f:96

J'ai également tenté de bloquer les paquets UDP sur le port 67 et 68. mais j'ai apris avec une petite recherche que le serveur DHCP (relay compris) intercepte les DHCP REQUEST avant le firewall … ce qui est embêtant.

Il est vrai que si on regarde bien, cela ne pose pas de soucis dans un réseau "traditionnel" avec un DHCP "traditionnel".
Le serveur DHCP recois 2 DHCP REQUEST, 1X de mon client et 1X du DHCP-relay.
Conclusion, mon client reçois 2X la même IP.

Voici le nœud du problème :

Mon DHCP n'est pas "traditionnel", il est configuré pour m'avertir dés qu'un client se connecte sur le réseau et demande une adresse IP.
Je vous entends déjà me dire : "pas grave, tu recevra 2 mails au lieu d'un seul" ... Oui, c'est vrai, désagréable, mais non problématique.
Mon DHCP n'est pas configuré que pour m'envoyer des mails, mais aussi pour reconnaître certaines machines sur mon réseau afin d'y effectuer certaines taches.
Par exemple : démarrer des services indispensables dans mon réseau.
Mais la tache la plus importante c'est le backup de mes différents machines ... et c'est là que ça coince !
Mon système de backup ne fonctionne plus correctement !
Pire, il est actuellement à l'arrêt !

Autrement dis, je ne peux pas me permettre d'avoir une "redondance" des DHCP REQUEST.

Mon Workaround actuel et temporaire : mettre un petit serveur linux avec un DHCP-relay dans le Vlan16.

Si vous avez des solutions/corrections à proposer, je suis preneur.

D'avance, je vous remercie,
Bonne soirée,

Florian22

tout autre sujet, (désolé) mais rassure toi tu vas avoir certainement une réponse,

aurais tu le catalogue prix, ou les tarifs de lannerinc pour ta machine ou les autres?

juste pour avoir une idée de leur niveau de prix

merci bcp

cdlt

maxty01

Bonsoir,

Effectivement, hors sujet, lol. Mais pas de soucis.

Pour un FW7541, il faut compter 550€ HTVA.

Tu a des webshop en France : http://store.calexium.com/fr/74-x86-network-appliances

Ou un autre plus international : http://store.netgate.com/Netgate-FW-7541-BTO-P1893.aspx

Je ne pense pas que Lanner Inc propose ses produits en vente direct, ce qui, entre nous, est dommage.

Bien à toi,
Bonne soirée,

Florian22

@maxty01:

Voici le nœud du problème :

Mon DHCP n'est pas "traditionnel", il est configuré pour m'avertir dés qu'un client se connecte sur le réseau et demande une adresse IP.
Je vous entends déjà me dire : "pas grave, tu recevra 2 mails au lieu d'un seul" … Oui, c'est vrai, désagréable, mais non problématique.
Mon DHCP n'est pas configuré que pour m'envoyer des mails, mais aussi pour reconnaître certaines machines sur mon réseau afin d'y effectuer certaines taches.
Par exemple : démarrer des services indispensables dans mon réseau.
Mais la tache la plus importante c'est le backup de mes différents machines ... et c'est là que ça coince !
Mon système de backup ne fonctionne plus correctement !
Pire, il est actuellement à l'arrêt !

Autrement dis, je ne peux pas me permettre d'avoir une "redondance" des DHCP REQUEST.

Mon Workaround actuel et temporaire : mettre un petit serveur linux avec un DHCP-relay dans le Vlan16.

Si vous avez des solutions/corrections à proposer, je suis preneur.

Merci pour ta réponse sur le prix

concernant ce passage,

si je comprends bien, c'est le réseau, qui détecte qu'une machine est UP, et qui "envoie" les services ? (exemple, appel d'un backup)

peux tu en dire plus sur ces services, et sur l'utilité que tu sembles requerir, a savoir: "savoir par mail (temps reel) qu'une machine est sur le réseau"

–
je ne suis pas sur d'avoir tout bien compris, c'est pour cela que je m'abstiendrai de tout commentaire de prim'abord,

mais: a mon avis, il y a plus simple que ce que tu fais.

(par "plus simple" j'entends: l'approche que tu utilises peut s'averer inutilement "complexifiante")

maxty01

Bonsoir,

C'est exact, c'est mon réseau qui détecte les machines grâce au DHCP.
Mais il n'envoie pas de service, il en démarre certains à distance.
Le backup n'est pas exécuté par la machine, mais par le serveur (via rsync).

Une des utilités de recevoir un mail aussitôt qu'un client se connecte, c'est de connaître rapidement l'adresse IP qui lui est attribuée ainsi que sa MAC.
Ça m'est très utile lorsque je branche un nouveau périphérique sur le réseau (dernier exemple en date un Raspberry Pi).

Il faut savoir qu'il n'est pas aisé, pour un portable par exemple, de savoir s'il est sur le bon réseau pour lancer un backup.
J'ai donc pris la décision de configurer mon serveur pour que ce soit lui qui effectue le backup de ces machines après le DHCP-Request.
De plus, c'est une solution relativement simple à mettre en place, et simple à configurer.

Bonne soirée,

Florian22

c'est ca que je voulais pointer du doigt dans mon msg preceddent

c'est totalement HS

mais pourquoi déleguer cette tache par le dhcp, via un mail?

qui t oblige je presume ensuite a "lancer la procédure" sinon, ou est l utilité du mail.

par le portail captif, tu as la possibilité de travailler par la mac

tu pourrais facilement, mettre une redirection dans la config du CP
pour filer après un login vers une autre page du CP

Login (mac ou code) => Renvoi vers une page captiveportal-xxx.php => Faire ce que tu y veux => header location vers un intranet, ou google, ou ce que tu veux

dans ta page specifique, tu as la possibilité via PHP, de recuperer la mac

tu peux donc déja déclarer une variable
ensuite, via cette variable tu peux recuperer l'ip en cours du client sur le CP (ou en fait c'est l'inverse, je sais plus, faudra que je regarde mon fichier, je me rappelle juste que l'un permet de recuperer l'autre)

tu as donc tes deux variables.
il ne te reste plus que dans ce script (juste avant ton header location)
de déclencher (par exemple via curl) ta procédure, grace a tes deux variables (ou seulement l'ip vu que tu travailles avec ca)

tu peux même étendre ton script :

verifier que l'appareil a des droits, (zone, droit au backup, ) => agir en consequence
journaliser que tu lances la proc dans mysql
notifier l'utilisateur que la proc a démarree
te notifier que la proc a démarrée

c'est donc le login qui déclenche tout
et non plus une procédure qui ne semble pas automatisée, via une notif DHCP

si tu veux je te passe le bout de code php qui me sert dans le CP pfsense a recuperer ces deux variables. tu dis.
moi ca me sert a récuperer des Token via une api radius

pour faire de l'authentification trensparente sur le réseau pour certains services HTTP

avec l'ip et la mac, le script interroge l'api radius, si la session est genuine, il lui refile un token d'une heure
puis par un header location, ils sont renvoyés vers le service voulu, avec le token.

je pense que dans ton cas tu te compliques la vie, en ouvrant ta procédure "du coté du réseau" et pas du cote "de l'utilisateur"
ca doit te generer beaucoup de rejets, et d'interventions manuelles

cdlt

procéder ainsi, te permets :

de reduire le taux de ratés/rejets
d'éviter d'être attentiste coté réseau, en le "surveillant" et en agissant "après coup"
te permet de tout regrouper en UN SEUL POINT, qui a lieu en post login - sur la zone de ton choix (vu que tu fais pas sur toutes les zones) et pourquoi pas avec les appareils de ton choix, grace a l'ip, la mac, et derriere un mysql , ou un radius/mysql, ou directement dans le script si tu as 3 machines mdrr

maxty01

Bonsoir à tous,

Merci Florian22 pour cette excellente réponse, cependant toujours hors sujet …

Ma question première est et restera "l’écoute du DHCP Relay sur une interface qui n'est pas configurée pour l'être".

Ton idée, exposée ici, est très intéressante et , entre nous, je la garde sous le coude pour un prochain projet. Cependant, celle-ci ne résoudra pas le problème principal qui est "l’écoute du DHCP Relay sur une interface qui n'est pas configurée pour l'être".

Aussi, j'ai mes raisons pour avoir mis en place un système tel que je l'ai présenté dans mes derniers messages. Et je les ai présenté, non pas pour être critiqué sur la méthode choisie, mais pour remettre dans le contexte du "bug" et de sa mise en lumière.

De plus, à ta lecture, je pense que tu n'as pas compris le fait que, si mon dhcp est capable, via script, d'envoyer un mail, il est également capable d'effectuer d'autres taches, tel que le backup, de façon automatique.

@Florian22:

mais pourquoi déleguer cette tache par le dhcp, via un mail?

qui t oblige je présume ensuite a "lancer la procédure" sinon, ou est l utilité du mail.

Ta remarque n'a donc aucun sens.

Bref, j'espère, de tout cœur, refermer cette parenthèse afin de revenir au nœud du problème qui est et qui restera "l’écoute du DHCP Relay sur une interface qui n'est pas configurée pour l'être".

Bonne soirée,

Florian22

ce n'etait pas de la critique.

concernant ton probleme, peux tu envoyer les captures d''écran de config de la page dhcp relay?

maxty01

Bonsoir,

Bien sur, mais je ne sais pas ce que tu vas apprendre de plus.

Bien à toi,

Bonne,

DHCP_Relay.png_thumb

Florian22

Si tu mets le relai sur l'interface LAN, et que tu le sors du vlan, observes tu le même comportement ?

il serait interessant d'observer cela sans Vlan, directement avec le relai sur le Lan sans utiliser l'interface taggée, desactive la, mets le relay directement sur le lan
reboot, et vois si ya une difference

(apres peut etre que ca a deja été fait)

maxty01

Bonsoir,

Déjà fait.

Au départ, j'avais mon LAN en non taggé sur l'interface em0, mon LAN Guest étais en VLAN 16 taggé sur l'interface em0.

Dec 7 13:42:30 	dhcrelay: Sending on BPF/em0_vlan16/00:90:0b:30:2f:96
Dec 7 13:42:30 	dhcrelay: Listening on BPF/em0_vlan16/00:90:0b:30:2f:96
Dec 7 13:42:30 	dhcrelay: Sending on BPF/em0/00:90:0b:30:2f:96
Dec 7 13:42:30 	dhcrelay: Listening on BPF/em0/00:90:0b:30:2f:96

Pour le moment, j'ai mon LAN en non taggé sur l'interface em0 et mon LAN Guest en non taggé sur l'interface em1.

Dec 7 15:38:37 	dhcrelay: Sending on BPF/em1/00:90:0b:30:2f:97
Dec 7 15:38:37 	dhcrelay: Listening on BPF/em1/00:90:0b:30:2f:97
Dec 7 15:38:37 	dhcrelay: Sending on BPF/em0/00:90:0b:30:2f:96
Dec 7 15:38:37 	dhcrelay: Listening on BPF/em0/00:90:0b:30:2f:96

Le comportement n'est pas différents, la preuve dans les fichiers de logs.
Bonne soirée.

Florian22

tu as des clients sur le LAN ?

ou tes postes sont tous servis par des réseaux virtuels et l'interface LAN n'est que conteneuse ?

car si c'est le cas, ou est le problème ? laisse le donc écouter sur la LAN non tagée, vu qu'il se pourrait qu'il n'y ait rien dessus.

concretement, je ne sais pas dire si c'est anormal, ou un comportement normal de pfsense, qui TOI te poserait problème, (doublons de processus vis a vis de ton traitement arriere plan) (cf message d'avant)

pourquoi ne contourne tu pas ce problème en vidant LAN, et en ouvrant un VLAN nouveau.

ainsi tu n'as plus rien sur LAN, et laisse le donc "ecouter" ..

as tu verifié les fonctions dhcp relay d'un éventuel switche manageable sur le trajet?

maxty01

Bonjour,

J'ai des clients sur tous les LANs, mon Android par exemple, est sur mon Lan Guest et n'a accès qu'a internet.

Sur mon Lan, j'ai mes portables, ordinateurs, serveurs.

Ouvrir un nouveau LAN, pour par exemple "enfermer" mes serveurs est effectivement une solution à la quelle j'ai pensé, mais ce n'est pas la meilleure solution, car j'utilise de l’agrégation tout le long de mon réseau, y compris sur mon serveur.

Mes switchs sont des L2 et n'ont pas la fonction DHCP-Relay, ce qui m'aurait aidé dans ce cas là.

Merci pour ton aide.

Bonne journée,

Florian22

en tout cas, si personne n'a pris part a la conversation, a mon avis c est que les gens pensent que ca vient de ton setup
(materiel actif sur le trajet comme un switch, ou même du serveur dhcp en lui meme ou défaut de config des vlan…...)

ou de toute autre chose qu'on ignorerait.

je ne reviendrais pas sur le setup en lui même, ou je considère "que tu te fais royalement chier pour rien en faisant comme ca"

;)

maxty01

Bonjour,

Merci pour ton "avis personnel".

Effectivement, ce sujet n'a pas passionné les foules.

Si pas de réponse constructive, je vais tenter ma chance dans le support anglais.

Merci,
Bonne journée,