B
Promeneur

Promeneur

 • 

20  messages

vendredi 28 juillet 2017 08:36

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!

Solution acceptée

Promeneur

 • 

20  messages

il y a 7 ans

Dans le passé, il me semble avoir essayé d'utiliser 1500 mais cela posait des soucis.
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".

Top Expert

 • 

41.4K  messages

il y a 7 ans

Hello
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.

Promeneur

 • 

20  messages

il y a 7 ans

Merci pour ce retour.
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.

Top Expert

 • 

41.4K  messages

il y a 7 ans

UPNP est actif sur votre système ?
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 ?

Promeneur

 • 

20  messages

il y a 7 ans

Upnp n'est pas actif sur mon linux box, car je le considère comme dangereux.

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.

Top Expert

 • 

41.4K  messages

il y a 7 ans

Faites à votre aise, je regarderai aussi ce we pour les infos sur les options dhcp .

Promeneur

 • 

20  messages

il y a 7 ans

@pthierry: merci pour votre retour

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.

Promeneur

 • 

20  messages

il y a 7 ans

Sur base des informations communiquées ci-dessus. J'ai repassé mon install en mode bridge pour analyser cela à mon aise.
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.

Top Expert

 • 

41.4K  messages

il y a 7 ans

Quelle valeur MTU avez vous reglé ?

Promeneur

 • 

20  messages

il y a 7 ans

J'ai passé le MTU à 1480. Pour une raison étrange par défaut, le linux box le met à 576 sur l'interface WAN (config via DHCP).
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?

Top Expert

 • 

41.4K  messages

il y a 7 ans

Chez moi le routeur Asus, le MTU est à 1500, je n'ai pas touché à cette valeur ( par défaut pour la connexion WAN ) et c'est parfaitement stable.

Top Expert

 • 

41.4K  messages

il y a 7 ans

Non pas vraiment car il n'y a pas de support de voo pour VOTRE matériel en bridge ... aucun des routeurs du commerce que j'ai installé ( des dizaines ) n'a jamais nécessité de toucher au MTU .. la valeur de 576 de votre box Linux n'est absolument pas normale pour une connexion câble ou même adsl ...

Promeneur

 • 

20  messages

il y a 7 ans

Je n'ai pas trop envie de rentrer dans une polémique stérile.
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.

Top Expert

 • 

41.4K  messages

il y a 7 ans

Je pense qu'ils n'ont pas pensé à cela au HD. Mon routeur et d'autres en dhcp sur le modem voo me met 1500 qui est une valeur "idéale" pour une liaison ethernet. Votre box Linux à un léger bug à ce niveau à mon avis.

Promeneur

 • 

20  messages

il y a 7 ans

Nous sommes bien d'accord que 1500 est la bonne valeur pour un lien ethernet. D'ailleurs l'interface interne, a cette valeur là. Comme décrit plus haut, c'est n'est que l'interface WAN qui recevait cette valeur et seulement lorsque l'adresse reçue l'est via DHCP (elle est maintenant forcée à 1500 via les scripts de config de l'interface).

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.

Poser une question

Poser une question

Conversations populaires

Loading...
Loading...