Promeneur
•
20 messages
Box Evasion et modem netgear en mode bridge
Bonjour à tous,
On vient de me remplacer mes 2 Voocorder par 2 box evasion. C'est plutôt chouette, néanmoins pour ce faire le technicien a du repasser mon netgear qui était en mode bridge en mode normal (l'aspect routage/firewall/... était géré par une linux box) . Sans trop rentrer dans les détails, j'ai pu solutionner temporairement mes soucis en mettant la DMZ sur ma box linux mais c'est pas top ( double nat, impossibilité de régler certains paramètres - icmp rentrant sur ip publique ...)
J'aimerais donc repasser en mode bridge rapidement.
Pour ce faire, j'ai quelques questions auxquelles ni le technicien, ni son support 2ème ligne n'ont pu me répondre (j'ai quand même été un peu surpris par le manque de connaissance sur le produit).
Pour info, quand les boxs evasion ont été branchées derrière ma linux box (avec le mode en mode bridge donc), les boxs evasion recevaient bien des ip via DHCP mais un code d'erreur apparaissait (je ne me souviens plus du quel malheureusement).
En ayant parcouru le forum, je suis arrivé à 2 ou 3 hypothèses qui pourraient expliquer que les box ne fonctionnaient pas et j'aimerais avoir des confirmations sur ces hypothèses.
-1- Mon serveur dhcp fournissait comme serveurs dns des serveurs qui n'étaient pas ceux de Voo. Ma première hypothèse est que les box doivent utiliser les serveurs DNS de Voo pour être fonctionnelles. Utiliser un dns tiers ne fonctionnerait donc pas.
-2- J'ai également suspecté que mon range interne (en 10.0.0.0/8, oui je sais c'est extrême mais il y a une raison technique derrière ce choix) rentre en conflit avec les ip des services evasion qui ne seraient disponible que via des ranges privés (le 10.0.0.0/8 en l'occurence). Cela me semble peu probable mais sait-on jamais.
-3- Les box evasion requièrent l'ipv6. Très peu probable si j'en crois les posts de ce forum, mais si j'en parle c'est que j'ai observé que les boxs evasion derrière le netgear en mode normal ont reçu une ipv4 et une ipv6.
J'ai exclu un souci de firewalling car lors des tests en mode bridge tout le trafic sortant était autorisé. Pour moi la raison la plus probable est donc ce souci de serveur dns (autre que ceux de voo) que je n'ai pas encore pu vérifier.
Si vous voyez une autre raison, je suis preneur aussi :-)
Je vous remercie d'avance pour vos lumières!
On vient de me remplacer mes 2 Voocorder par 2 box evasion. C'est plutôt chouette, néanmoins pour ce faire le technicien a du repasser mon netgear qui était en mode bridge en mode normal (l'aspect routage/firewall/... était géré par une linux box) . Sans trop rentrer dans les détails, j'ai pu solutionner temporairement mes soucis en mettant la DMZ sur ma box linux mais c'est pas top ( double nat, impossibilité de régler certains paramètres - icmp rentrant sur ip publique ...)
J'aimerais donc repasser en mode bridge rapidement.
Pour ce faire, j'ai quelques questions auxquelles ni le technicien, ni son support 2ème ligne n'ont pu me répondre (j'ai quand même été un peu surpris par le manque de connaissance sur le produit).
Pour info, quand les boxs evasion ont été branchées derrière ma linux box (avec le mode en mode bridge donc), les boxs evasion recevaient bien des ip via DHCP mais un code d'erreur apparaissait (je ne me souviens plus du quel malheureusement).
En ayant parcouru le forum, je suis arrivé à 2 ou 3 hypothèses qui pourraient expliquer que les box ne fonctionnaient pas et j'aimerais avoir des confirmations sur ces hypothèses.
-1- Mon serveur dhcp fournissait comme serveurs dns des serveurs qui n'étaient pas ceux de Voo. Ma première hypothèse est que les box doivent utiliser les serveurs DNS de Voo pour être fonctionnelles. Utiliser un dns tiers ne fonctionnerait donc pas.
-2- J'ai également suspecté que mon range interne (en 10.0.0.0/8, oui je sais c'est extrême mais il y a une raison technique derrière ce choix) rentre en conflit avec les ip des services evasion qui ne seraient disponible que via des ranges privés (le 10.0.0.0/8 en l'occurence). Cela me semble peu probable mais sait-on jamais.
-3- Les box evasion requièrent l'ipv6. Très peu probable si j'en crois les posts de ce forum, mais si j'en parle c'est que j'ai observé que les boxs evasion derrière le netgear en mode normal ont reçu une ipv4 et une ipv6.
J'ai exclu un souci de firewalling car lors des tests en mode bridge tout le trafic sortant était autorisé. Pour moi la raison la plus probable est donc ce souci de serveur dns (autre que ceux de voo) que je n'ai pas encore pu vérifier.
Si vous voyez une autre raison, je suis preneur aussi :-)
Je vous remercie d'avance pour vos lumières!
roylion15
Top Expert
•
45.1K messages
il y a 7 ans
Donc vous pourriez éventuellement enlever l'option "interface-mtu" depuis le fichier de config /etc/dhcp/dhclient.conf et alors il utilisera normalement la valeur "par défaut" de 1500. Il est quand même bizarre que le DHCP de VOO envoie cette valeur de 576 à votre box Linux alors que cela devrait être la valeur par défaut de 1500.
0
0
bdemidde
Promeneur
•
20 messages
il y a 7 ans
J'ai supprimé l'option interface-mtu de la config du client dhcp. J'ai supprimé les valeurs que j'avais poussées dans la définition des interfaces.
Un redémarrage de mon système initialise bien l'interface avec un mtu de 1500.
Par contre, je vais quand même re-tester cette valeur pour m'assurer qu'elle soit correcte. J'ai souvent vu la valeur de 1492 utilisée dans le cadre de connexions câble.
Il est possible que la valeur de 576 poussée par le serveur dhcp de voo soit une valeur par défaut (non intialisée). Le paramètre interface-mtu n'est peut-être que rarement demandé (il faut le modem voo en mode bridge et que le routeur demande spécifiquement ce paramètre ) et donc ce souci n'a jamais été remonté auparavant. De mon expérience, cette valeur basse ne provoque pas de gros soucis et pourrait donc passer inaperçue chez beaucoup de personnes.
Le fait que les box .evasion envoient des paquets avec un payload conséquent pour vérifier l'état de la connexion wan met en lumière ce souci. J'avais également eu des soucis lors de tests de streaming (en tant que producteur de contenu), la valeur basse de mtu posant souci.
0
0
roylion15
Top Expert
•
45.1K messages
il y a 7 ans
Je viens de déterminer ce qui semble être la meilleure valeur via quelques tests que j'ai effectué directement depuis la ligne de commande (linux) sur mon routeur ASUS.
Alors la valeur clef trouvée est 1472, auxquels on doit ajouter les 8 bytes pour l'entête ICMP et les 20 bytes pour l'entête IP donc çà donne bien 1500 (1472+8=1480+20=1500).
Les problèmes rencontrés par certains routeurs du commerce dans les vieux NETGEAR, certains CISCO ou LINKSYS et les box Evasion seraient-ils dus à une mauvaise valeur du MTU sur le WAN ? C'est à voir ...Enfin si c'est le même souci, je n'ai pas sous la main un de ces routeurs qui ont ce bug, mais notre expert @Pthierry peut être ?
0
0
bdemidde
Promeneur
•
20 messages
il y a 7 ans
Le MTU de 1500 est bien la bonne valeur.
Il serait intéressant de savoir si cette valeur 576 pour le MTU poussée par le serveur DHCP est volontaire (est-elle réellement fixée à cette valeur?) ou pas et si elle touche tout le réseau ou pas. Il serait utile d'avoir le renseignement de la part d'un ingénieur de chez voo sur le sujet.
Et pour ce qui concerne les problème de box .evasion et de modem en mode bridge, je pense qu'il y a encore une différence entre l'absence d'ip attribuée aux box evasion (ce qui n'était pas mon cas) et celui ou les box reçoivent une ip mais indique une absence de connectivité WAN. Dans mon cas, le simple basculement de serveur dhcp n'a pas résolu le souci.
0
0
bdemidde
Promeneur
•
20 messages
il y a 7 ans
https://community.linksys.com/t5/Linksys-Small-Business/Problems-with-DHCP-on-LRT224/td-p/967537
Qui semblerait plus tenir d'une mauvaise implémentation. Surprenant d'ailleurs qu'aucun fix n'ait été publié.
0
0