Hello! Premier poste ici même si je lis le forum depuis un moment déjà . Cela fait 2ans que j'ai un Netgate SG3100 à la place de ma box en PPPoE et tout marchait bien. Depuis quelques semaines, jai migré vers DHCPv4 en suivant les différents tutoriels de ce forum et d'autres site y faisant référence et ça marchait très bien! Avan hier, jai décidé de passé du SG3100 à un switch + OPNsense virtuel, dans le but de passer à IPv6 (raw-option pas supporté par pfSense). J'ai migré mes config tout marchait nickel. Jusqu'à hier soir vers 21h. Perte de connexion à Internet, plus d'IP public. jai passé la soirée, un bout de la nuit et la mâtiné à faire différents tests pour voir ce qui se passe.

J'ai sniff ma LB3 pour voir comment elle agit en comportement normal. J'ai un simple DORA, très rapide qui fonctionne.

Sur mon setup, j'ai mon Discover mais aucune réponse. Passé un temps, j'avais au moins un fake Offer qui me parquait dans une zone parce que mon option-90 n'était pas bon. Mais là rien du tout! j'ai bien vérifié que mon Discover passe sur le cable (je deviens parano) et oui il est bien envoyé. J'ai suivi les tuto de OPNsense pour refaire la config, config que j'avais simplement copié de la config pfSense qui marchait. J'ai mis une config perso qui retire le champ hostname, posé par OPNsense, j'ai tous les champs dans l'ordres, le seul bit qui n'est pas identique à une requête de la LB c'est le BOOTP flag. La LB3 envoie broadcast alors que j'envoie unicast. Impossible de changer cette options avec la version de dhclient de OPNsense malheureusement...

J'ai du coup essayé de me rebrancher sur mon ancien setup pfSense, avec la conf qui n'a pas bougé et qui marchait. et là non plus aucune réponse de DHCP...

N'ayant absolument rien modifié, je suppose que Orange vérifie quelque chose de nouveau depuis mais je n'arrive pas à voir quoi. Mon Discover est identique à celui de la box, j'ai même essayé de refaire un nouvelle chaine option-90 avec des nouvelles valeurs aléatoires ma sans succès.

Je suis preneur d'une piste si vous avez des idées/avez rencontré ce problème. J'ai vu d'autres topic sur ce soucis (OPNsense DHCP = KO) mais le problème venais du User Class Information qui était différent, il est bien identique chez moi.

Merci d'avance pour votre aide!

Réponse : le problème ne venait pas du tout d'Orange ni de ma config DHCP, mais du PCI passthrough que j'utilise sur proxmox. L'interface ne fonctionne plus de manière inopiné ou après un reboot de la VM. Le trafic sortant est visible, mais rien ne rentre. Ce sujet est discuté ici https://forum.proxmox.com/threads/proxmox-requires-full-reboot-after-shutting-down-vm-with-pci-passthrough.101552/.

Hello! Alors sur mon setup j'ai un OPNsense virtualisé effectivement mais ça WAN passe par une carte en PCIe passthrough. Donc le OPNsense est directement branché dans l'ONT.

Pas mal pour le hostname, au final je l'ai viré en mettant un fichier de conf plutôt que d'utiliser la GUI. Pour la MAC, avant je ne chageais rien, j'utilisais celle par défaut, mais maintenant je spoof celle de la LB. Et j'ai bien fait gaffe de le reporter dans le "Client Identifier".

Je ne sais pas si ce comportement de ne pas répondre est normal, avant ça me parquait dans une plage en 172.x.x.x, mais maintenant c'est juste aucune réponse. Je suppose aussi que si tu utilises OPNsense, tu n'as pas le flag BOOTP Broadcast, et pourtant ça à l'aire de marcher pour toi donc ça serait pas ça.

Qu'en est-il de PPPoE? Là je n'ai aucune réponse non plus, je ne sais pas si c'est ma conf qui foire (mais qui marchait avant) ou si c'est juste qu'il a été désactivé au profit de DHCP.

Temporairement, jai branché ma LB à mon OPNsense et jai fait du double NAT pour mes services et remis DynDNS sur la LB pour mon domaine, mais je préfèrerais quand même retrouver mon setup d'avant

Je continue mon investigation. J'utilise bien le VLAN 832 avec un priorité de 6 dans la conf DHCP. J'ai trouvé quelques différences très minimes entre la LB et moi:

• le TTL : 64 la LB, 128 OPNsense
• le DSCP : 0xC0 pour la LB, 0x10 pour OPNsense. Class selector 6 pour la LB et 4 pour OPNsense
• le checksum de IP : normal
• le transaction ID pour DHCP : normal
• le temps écoulé : à 1sec sur le LB mais je suppose qu'on s'en fou un peu
• BOOTP flag : unicast pour OPNsense, et Broadcast pour la LB

Aussi, j'envoie les options dans un odre différent de la LB, elle envoit par ordre croissant de code, moi j'ai le 55 qui vient après 53,60,61. Mais ça aussi je me dit qu'on s'en fou. A part ça, nos trames sont parfaitement identiques! Je ne comprends pas d'où vient le problème... et encore moins de n'avoir aucune réponse de DHCP.

Le couple MAC / client-identifier est bon. Quand on parle de CoS, on parle bien de VLAN pirority? le champs dans la partie 802.1q? J'ai bien créé un VLAN 832 dans mon interface et j'ai bien une priorité de 6 qui est appliqué

802.1Q Virtual LAN, PRI: 6, DEI: 0, ID: 832
    110. .... .... .... = Priority: Internetwork Control (6)
    ...0 .... .... .... = DEI: Ineligible
    .... 0011 0100 0000 = ID: 832
    Type: IPv4 (0x0800)

Le seul autre "6" est celui de DSCP, qui est à CS6 sur la LB mais à 4 (unknown) sur OPNsense:

LB:
Differentiated Services Field: 0xc0 (DSCP: CS6, ECN: Not-ECT)
    1100 00.. = Differentiated Services Codepoint: Class Selector 6 (48)
    .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
OPNsense:
Differentiated Services Field: 0x10 (DSCP: Unknown, ECN: Not-ECT)
    0001 00.. = Differentiated Services Codepoint: Unknown (4)
    .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
ça serait checké maintenant? Je dois mettre des règles dans le pare-feu pour le changer apparemment, j'essayerai mais je n'avais pas du tout à faire ça avant c'est bizzar...

Le BNG peut avoir utilité à avoir un marquage DSCP en plus de la COS.
Cependant très peu de chance que ce BNG soit à saturation, ni sur les cartes d'interface, ni en coeur.
Je maintiens donc : DSCP cohérent avec la COS, c'est mieux. Mais dans > 99% des cas cela se passera bien même sans le DSCP en ligne avec la COS

Je cite levieuxatorange dans son méga poste sur les changements 2023, il y a un monde où je tombe dans le 1%... Ca expliquerai aussi pourquoi ça ne marche pas non plus sur pfSense. J'ai essayé de changer le DSCP via le pare-feu, mais sans succès, même en appliquant la règle sur tous les paquets. Il me semble avoir vu un poste sur le forum OPNsense d'un gars dans la même situation, mais je ne le trouve plus.

De plus, j'ai l'impression que le PCI passthrough bug, j'ai eu un moment ou il était bien présent dans la VM, branché sur la LB, mais il ne recevait plus de traffic, alors qu'un autre PC branché sur le LB recevait bien du ARP en broadcast. Donc je pense avoir plusieurs soucis. Je suis pas sorti XD

Edit:

Moi aussi je faisais cette confusion. Du coup j'ai vérifié le code source du kernel il y a quelques temps...
Et non, le kernel n'associe pas la socket_priority interne de Linux au champs IP.DSCP. Aussi vérifié par l’expérimentation...
Quand bien même le kernel le ferait pour les socket "normales", ça ne marcherait pas sur les RAW sockets utilisées par les programmes clients DHCPv4.

On peut utiliser netfilter/iptabels/nftables pour la modifier, mais seulement pour les applis qui ne sont pas obligées d'utiliser des socket RAW. Celles-ci bypass complétement netfilter, on ne peut pas agir dessus. Comme pour les client DHCPv4.

Les astuces suivantes vont fonctionner:
- modifier le code source pour positionner la bonne valeur IP.DSCP directement dans las paquets DHCPv4 initiaux sur la RAW socket
- altérer les paquets au niveau L2/L3 par un smart switch en amont du port WAN

Les astuces suivants ne vont pas fonctionner:
- preload une lib .so qui va forcer un appel socket modifié conjoint avec un setsockopt sur la RAW socket: ne modifie pas la IP.DSCP
- utiliser un programme eBPF (kernel assez récent...) qui va altérer la socket priority de la RAW socket: ne modifie pas la IP.DSCP

Et bien je suis pas sorti, si c'est bien ça le problème je ne vous souhaite pas d'avoir à set le DSCP...

Hello!

J'avais bien vérifié que les MAC correspondaient, j'avais essayé avec celle du NIC et celle de la LB, et ça n'a rien changé. En rentrant aujourd'hui, jai branché mon pfSense, sur lequel je n'avais rien changé, dans le doute... et ça a marché! Alors jai branché le OPNsense sur lequel j'ai laissé la MAC par défaut (avec le bon client identifier), et... ça a marché! Je n'ai rien changé et ça a marché...

J'ai quand même le doute sur le PCI passthrough qui a planté, et du coup OPNsense qui me remontais bien envoyer des paquets, mais que du coup il n'y ait rien sur le cable. J'ai pas la preuve formel de ça, mais ça restera un truc a verifier si ça plante. Du coup je laisse ma conf fined grained (sans le hostname OPNsense envoyé dans le Discover mdr), on va voir combien de temps ça tient, en espérant que ça ne tombe pas! Jai capturé le DORA avec OPNsense, je vais regardé des fois qu'il y ai des infos dedans (code d'erreur etc.). Prochaine étapes : apprendre et mettre en place IPv6  Merci pour votre réactivité en tout cas! ça fait plaisir de pas se sentir seul dans ces moments là.