![Promeneur Promeneur](https://sprcdn-assets.sprinklr.com/775/65e1497e-ac08-4395-a466-a16c7e2f5979-515584076/PROMENEUR_p.png)
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!
Solution acceptée
bdemidde
Promeneur
•
20 messages
il y a 7 ans
Il faudrait que je refasse le test.
Quoiqu'il en soit, tout fonctionne normalement, le cause initiale de mon souci était donc bien le mtu trop bas poussé sur mon interface WAN.
Un grand merci à vous (et tout particulièrement à Roylion15) pour vos réponses qui m'ont permis de cerner rapidement le souci.
PS: il serait quand même pas mal que le support 2ème ligne de voo dispose d'une checklist pour les installations "bridge".
0
0
roylion15
Top Expert
•
43.2K messages
il y a 7 ans
Je ne pense pas que ce soit à cause des DNS car tout le monde n'utilise pas les DNS VOO dans leurs routeurs et ca fonctionne...
par contre c'est un en liaison avec votre serveur dhcp de votre box Linux et certains routeurs ( Cisco) du commerce ont également ce problème avec les Évasion...
également que votre pare feu ne bloque pas certains ports nécessaires à Évasion pour communiquer directement avec les serveurs voo .., je ne sais pas mais votre box Linux n'aurait pas des options avancées du dhcp qui pourraient être activées pour que cela fonctionne ?
Je n'ai pas mes notes actuellement sous la main mais sur certains routeurs Cisco ou linksys, il faut toucher à ces reglages.
0
bdemidde
Promeneur
•
20 messages
il y a 7 ans
Donc, on sort l'hypothèse du serveur DNS.
Il y aurait donc des options supplémentaires transmises via le dhcp? Si vous pouviez les retrouver, cela m'aiderait grandement.
De mon côté, je vais tenter de voir ce que je peux récupérer.
Côté firewall, comme expliqué, tout le trafic sortant était autorisé, je doute donc que cela puisse venir de là.
Il serait intéressant de comprendre ce dont ont besoin les box evasion pour fonctionner. Je ne suis pas parvenu à trouver de détails sur le sujet. Manifestement, un simple accès internet ne suffit pas.
Au plaisir de vous lire.
0
0
roylion15
Top Expert
•
43.2K messages
il y a 7 ans
Je vais essayé de retrouver ca ce we parce que la je suis au boulot ...
Il faudrait quand même remettre le bridge pour voir ce qu'il se passe et voir si vous avez WAN actif dans le diagnostic des box ou pas ?
0
bdemidde
Promeneur
•
20 messages
il y a 7 ans
Mais je n'avais effectivement pas pensé à l'upnp. Je pourrais effectivement l'activer pour faire quelques tests.
Comme expliqué, plus haut, je n'ai pas encore eu le temps d'analyser en profondeur le souci, je comptais m'y mettre ce week-end.
Si il se confirme que l'upnp soit requis, il faudra que je songe à mettre les box evasion sur un segment isolé ou que je reste avec ce setup DMZ.
Merci pour le suivi.
0
0
roylion15
Top Expert
•
43.2K messages
il y a 7 ans
0
0
bdemidde
Promeneur
•
20 messages
il y a 7 ans
J'ai de mon côté vérifié le paramétrage upnp sur le modem netgear puisqu'il semble qu'on puisse visualiser les différentes redirections en cours. J'ai constaté qu'aucune redirection n'était en cours ce qui semble confirmer ce que pthierry indique à savoir que l'upnp n'est pas nécessaire.
Ayant un contrôle total sur ce que je peux envoyer comme paramètre via le dhcp au travers de ma linux box, je suis curieux de savoir quels paramètres particuliers font que la box .evasion fonctionne ou pas. Je prendrai le temps de faire ces tests et de vous donner de plus amples détails.
Je ferai également le test en utilisant un serveur dhcp tiers.
Vos indications me permettent au moins de voir dans quelle direction chercher et me permettront de gagner du temps.
Un tout grand merci à vous.
0
0
bdemidde
Promeneur
•
20 messages
il y a 7 ans
J'ai également (dans le doute) activé le dhcp sur mon Synology.
Tel quel, le résultat était similaire à celui observé précédemment. Càd, que les box .evasion recevait une ip du dhcp mais que la connexion WAN était annoncée comme défectueuse.
En faisant une petite session de tcpdump sur le trafic de la box, j'ai observé beaucoup de "connection unreachable" à cause de la fragmentation. En changeant le mtu, cela semble avoir solutionné le souci.
Donc pas de souci côté DHCP mais plutôt un souci de mtu côté interface WAN de la linux box.
Ce paramètre pouvant être passé comme option via le dhcp, cela pourrait éventuellement expliquer certaines incompatibilités avec certains serveurs dhcp.
0
0
roylion15
Top Expert
•
43.2K messages
il y a 7 ans
0
0
bdemidde
Promeneur
•
20 messages
il y a 7 ans
J'ai forcé cette valeur dans mes fichiers de config. J'avais déjà eu des soucis dans le passé avec d'autres applications et je pensais d"ailleurs avoir forcé le MTU à 1480 dans mes fichiers de config, manifestement ce n'était pas le cas.
D'ailleurs pourriez-vous me dire quelle valeur vous avez pour votre interface WAN sur vos routeurs en mode bridge?
0
0
roylion15
Top Expert
•
43.2K messages
il y a 7 ans
0
0
roylion15
Top Expert
•
43.2K messages
il y a 7 ans
0
0
bdemidde
Promeneur
•
20 messages
il y a 7 ans
Par contre, je ne demande aucun support sur mon matériel car il est bien évident que c'est un choix personnel.
Lorsque des questions claires ont été posées aux technicien et au support 2ème ligne sur ce qu'il était nécessaire de fournir pour avoir les box en ligne, il n'y a pas eu de réponse. Certes, le problème n'est pas évident à diagnostiquer mais quelques infos supplémentaires m'auraient permis de cerner rapidement le souci. Les informations demandées concernaient un produit de Voo en l'occurence...
Une autre remarque, cette fameuse valeur de mtu est poussée par le dhcp. Je vais déployer un système plus récent et voir si j'obtiens le même mtu par défaut au travers du dhcp. Pour info, si je configure la même interface avec un ip statique, j'ai un mtu de 1500.
Tout cela pour dire, qu'au travers des infos disponibles sur le forum, il y a moyen de faire une checklist permettant de cerner plus rapidement le souci et qu'il est dommage que ce outil ne soit pas à disposition des techniciens. La remarque se voulait constructive et en rien une attaque à l'encontre de Voo. Je suis bien trop content pouvoir faire appel à des gens serviables et d'avoir la chance de pouvoir faire appel à un helpdesk localisé en Belgique.
0
0
roylion15
Top Expert
•
43.2K messages
il y a 7 ans
0
0
bdemidde
Promeneur
•
20 messages
il y a 7 ans
Il est bien possible que ce soit lié au client dhcp de ma Debian (c'est une version ancienne maintenue "à jour" via les archives).
Je verrai si une version récente change quelque chose. Je posterai mes résultats quand j'aurai eu l'occasion de faire le test.
0
0