Résolu

Box Evasion et modem netgear en mode bridge


Badge +1
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!
icon

Meilleure réponse par bdemidde 29 juillet 2017, 19:59

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

Afficher l'original

23 commentaires

Niveau d'utilisateur 7
Badge +12
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.
Badge +1
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.
Niveau d'utilisateur 7
Badge +12
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 ?
Badge +1
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.
Niveau d'utilisateur 7
Badge +12
Faites à votre aise, je regarderai aussi ce we pour les infos sur les options dhcp .
Bonjour,

J'ai eu un problème similaire avec mes box .evasion et un routeur Linksys LRT224. Le problème semble venir du serveur DHCP de ce type de routeur (qui est peut-être similaire à celui rencontré avec un serveur sous Linux). La seule chose que j'ai changé, c'est désactiver le serveur DHCP du Linksys et utiliser celui d'un autre routeur (RT-AC88) qui me sert d'access point (et aussi de serveur DHCP du coup). Pour le reste, ce sont les DNS de Google qui sont utilisés et IPv6 est désactivé sur mon réseau...

EDIT: Et UPnP n'est pas actif non plus (j'aime garder le contrôle des ports que j'ouvre...)
Badge +1
@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.
Badge +1
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.
Niveau d'utilisateur 7
Badge +12
Quelle valeur MTU avez vous reglé ?
Badge +1
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?
Niveau d'utilisateur 7
Badge +12
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.
Badge +1
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".
Niveau d'utilisateur 7
Badge +12
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 ...
Badge +1
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.
Niveau d'utilisateur 7
Badge +12
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.
Badge +1
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.
Niveau d'utilisateur 7
Badge +12
En cherchant un peu sur le net pour votre souci, j'ai trouvé çà et apparemment vous n'êtes pas le seul ... https://askubuntu.com/questions/350992/how-do-i-override-an-mtu-provided-by-dhcp
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.
Badge +1
Merci pour le lien, c'était donc bien une valeur poussée par le serveur dhcp de voo. (encore un mystère élucidé 🙂 )

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.
Niveau d'utilisateur 7
Badge +12
Hello,
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 ?
Badge +1
Je suis arrivé à la même conclusion que vous :-)
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.
bdemidde a écrit:


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.



Bonjour,

Je suis d'accord avec vous, il semble bien s'agir de 2 problèmes différents. Dans mon cas, les box semblaient ne pas recevoir d'adresse IP, et la seule chose que j'ai changé pour résoudre le problème est le serveur DHCP local, le routeur étant resté le même... Quant à la valeur du MTU sur le Linksys LRT224, elle est réglée sur 'Auto', et je n'ai pas trouvé le moyen de voir quelle taille est effectivement utilisée pour la connexion WAN (pas d'accès SSH sur ce routeur). L'autre option est de choisir une valeur fixe, qui est par défaut sur 1500.

EDIT:
Je viens de faire un essai avec la command ping xxxx -f -l 1472 via la connexion VOO, et le ping passe. La taille du MTU utilisée sur le WAN est donc bien de 1500. Ce n'est donc pas le problème qui affecte le Linksys...
Badge +1
Pour votre souci, il s'agit probablement de ce problème ci:

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é.
bdemidde a écrit:

Pour votre souci, il s'agit probablement de ce problème ci:

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



Effectivement, cela y ressemble très fort ! Merci pour ce retour. Je resterai donc avec mon serveur DHCP séparé.

Commenter

    Gestion des cookies

    Nous utilisons des cookies pour améliorer et personnaliser votre expérience. Si vous acceptez ou continuez de naviguer, vous acceptez règles relatives aux cookies. En savoir plus sur nos cookies

    Accepter les cookies Paramètres de cookies