pas d'accès internet avec routeur perso

[Klona]

Un peu trop occupé pour m'occuper de ce sujet ces derniers temps.
Quelques tests supplémentaires :
Pfsense sur une machine, sans virtualisation : Exactement la meme
Avec un routeur netgear magnifique FVS336G(ca depasse pas 25Mbit sur le WAN "gigabit"), ca marche pas du tout. Faut dire que la gateway en dehors du subnet, c'est juste hors RFC...

IpCOP en VM : mieux, le mode bridge fonctionne et Ipcop crée tout seul la route vers la gateway hors plage, mais il y a quand meme des coupures "blanches" pendant 50 secondes... (voir plus bas)

Je lance ma dernière demande au support Knet qui ne se fait que sur le forum pour les config bridge (Heu... des tickets ça serait quand même bien ..)
Mais à mon avis on va me laisser mourir dans mon coin et ca va juste finir avec un autre opérateur.

/klona




ping www.google.com | while read pong; do echo "$(date): $pong"; done > /tmp/log_google &

Sun Jun 14 12:39:15 CEST 2015: 64 bytes from wq-in-f94.1e100.net (74.125.140.94): icmp_seq=534 ttl=50 time=5.96 ms
Sun Jun 14 12:39:16 CEST 2015: 64 bytes from wq-in-f94.1e100.net (74.125.140.94): icmp_seq=535 ttl=50 time=5.85 ms
Sun Jun 14 12:40:06 CEST 2015: 64 bytes from wq-in-f94.1e100.net (74.125.140.94): icmp_seq=585 ttl=50 time=6.00 ms
Sun Jun 14 12:40:07 CEST 2015: 64 bytes from wq-in-f94.1e100.net (74.125.140.94): icmp_seq=586 ttl=50 time=5.87 ms

Sun   Jun   14   12:50:18   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   1190   time=6.57   ms
Sun   Jun   14   12:50:19   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   1191   time=6.20   ms
Sun   Jun   14   12:51:01   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   1233   time=6.14   ms
Sun   Jun   14   12:51:02   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   1234   time=6.50   ms

Sun   Jun   14   12:50:18   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   1190   time=6.57   ms
Sun   Jun   14   12:50:19   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   1191   time=6.20   ms
Sun   Jun   14   12:51:01   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   1233   time=6.14   ms
Sun   Jun   14   12:51:02   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   1234   time=6.50   ms

Sun   Jun   14   13:01:22   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   1847   time=6.34   ms
Sun   Jun   14   13:01:23   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   1848   time=6.24   ms
Sun   Jun   14   13:01:45   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   1870   time=11.2   ms
Sun   Jun   14   13:01:46   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   1871   time=6.16   ms

Sun   Jun   14   13:12:25   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   2503   time=6.84   ms
Sun   Jun   14   13:12:26   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   2504   time=6.21   ms
Sun   Jun   14   13:12:51   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   2529   time=6.40   ms
Sun   Jun   14   13:12:52   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   2530   time=6.25   ms


Sun   Jun   14   13:23:28   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   3159   time=6.39   ms
Sun   Jun   14   13:23:29   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   3160   time=6.28   ms
Sun   Jun   14   13:24:13   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   3204   time=6.26   ms
Sun   Jun   14   13:24:14   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   3205   time=6.16   ms

Sun   Jun   14   13:34:32   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   3816   time=6.51   ms
Sun   Jun   14   13:34:33   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   3817   time=6.65   ms
Sun   Jun   14   13:35:04   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   3848   time=7.49   ms
Sun   Jun   14   13:35:05   CEST   2015:00:00   64   bytes   from   wq-in-f94.1e100.net   (74.125.140.94):   icmp_seq   3849   time=6.11   ms

[jack]

Dernière idée, j'ai eu un probleme à la livraison avec un convertisseur Fibre/RJ défaillant, que Knet m'a changé une fois le diagnostic réalisé. Se pourrait il qu'il y ait une config fausse chez Knet à cause de ce changement d'équipement (qui doit bien avoir une MAC coté RJ..)

Le convertisseur de media n'a pas de mac, il n'agit qu'au niveau 1 de la couche OSI

Faut dire que la gateway en dehors du subnet, c'est juste hors RFC...

Je suis curieux : tu peux me donner le numéro en question, et le passage exact ?

[Klona]

Le convertisseur de media n'a pas de mac, il n'agit qu'au niveau 1 de la couche OSI)

Autant pour moi.

Faut dire que la gateway en dehors du subnet, c'est juste hors RFC...

Je fouillerais quand j'aurais du temps. Mais c'est bien le principe de l'IP, de son mask, avec sa gateway dans le subnet (D'ailleurs en principe la première ou la dernière Ip du subnet pour faciliter la vie des switch dans la gestion des priorités.
C'est pas parce que les serveurs d'OVH fonctionnent avec ce système que c'est une bonne idée.


En tout cas je suis vraiment heureux que le seul support de l'équipe Knet soit de me mettre un petit coup de règle en fer sur le bout des doigts.
C'est une aide super constructive pour un client qui se galère tout seul depuis plus d'un mois vu que personne du support ne lui répond.

Je préférerais des bonnes idées de tests ou de correctifs pour un mode bridge stable.
Ou les infos pour virer cette bouse de netgear et attaquer direct le convertisseur depuis mon Pfsense.

Mais bon, j'y crois plus beaucoup.

/klona

[jack]

Owh, ne le prends pas si mal !

Je t'explique simplement que, pour moi, les informations du DHCPD sont valides (a minima: ne sont pas interdite par la RFC)
Quant à la configuration d'un pfsense, je n'en ai aucune idée ..

Comprends bien que c'est un équipement qui m'est absolument inconnu (à mes collègues également, par ailleurs)

Je pense que tu devrais te rapprocher de personnes plus expertes à ce niveau : que ce soit via le forum ou sur la mailing-list[/b] de pfsense.

La configuration du serveur DHCP est triviale à ce niveau, si cela peut t'aider dans tes recherches :

Code Sélectionner Étendre


shared-network machin {
  subnet ..
  subnet ..
}

group {
        option subnet-mask 255.255.255.255;
        option routers 185.4.79.254;
        host .. {
                hardware ethernet ..;
                fixed-address ..;
        }
}


[Klona]

Hello !
Ok je m'énerve un peu. Sorry. Je craque un peu à la longue. J'ai pas des tonnes de temps libre, alors le passer pour faire comme au boulot...

C'est pour cela que j'ai essayé avec un Ipcop qui marche un peu mieux mais pas terible quand meme.
et aussi avec un routeur standard qui ne se connecte meme pas (il prend bien le DHCP mais ne sait vraiment pas quoi faire de la gateway et faire une route dans ce machin, impossible)
J'ai tenté aussi avec une VM ubuntu (ou debian je sais plus) et j'ai eu le meme probleme (pas une deconnexion, juste plus aucun traffic qui passe)
J'ai loggé en wireshark le flux wan et j'ai vu la meme chose. Plus rien qui passe. J'ai meme pensé à un probleme de driver ESX avec les broadcam de ma carte serveur et j'ai ajouté une carte dual Gbit intel Pro. Pareil
Puis le flux revient, sans nouvelle requete DHCP.

Je vais récupérer un routeur cisco dans ma boite mais on s'est fait dévalisé ces derniers temps et j'en ai plus d'avance..

Y' aurait il moyen de vérifier coté Knet que je n'ai pas une bizarrerie dans ma config ? A la livraison ma ligne ne fonctionnait pas et il y a eu pas mal de tests avant d'identifier que c'était un défaut sur le convertisseur. Puis le mode bridge ne s'activait pas de l'interface et le support a du décoincé un truc pour que ca marche.
Peut être qu'une config en a souffert quelquepart ?
On peut tout resetter à zéro, et je peux aller échanger le routeur netgear en magasin etc.. Ouvert à tout.


NB : en attendant, j'aurais voulu routé tous les ports 1:65535 (j'ai pas vu de DMZ dans la config) vers mon routeur pfsense mais j'arrive pas à router une plage. J'entre la plage mais quand je fais enregistrer je me paye une erreur.

NB2 : T'as raison c'est pas dans la RFC c'est dans les BEst PRactice. Pour moi je trouve quand meme ca tres bancal comme config meme si je comprend l'avantage de ne gérer qu'une IP de gateway. Reste que pour des protocoles comme du BGP par exemple, vous pourrez jamais; Pas forcement grave sur un réseau grand public.
Mais bon votre infra est comme ça, on va pas la changer hein ?

/klona

[Klona]

et plus personne...

[miky01]

Le convertisseur de media n'a pas de mac, il n'agit qu'au niveau 1 de la couche OSI

Je sais le modele qui est utilise sur ce reseau, mais ceux que j'ai installé dans un DC avait bien une IP,  SNMP et WEB managable, (des Perle)

[jack]

Heu ..

Est-ce que la connexion est correcte en mode routeur ?
Si oui, alors la partie opérateur est correcte.
Pour ce qui est de la partie Kbox, je viens de la remettre à zero, pour si, par hasard, il y avait des restes de configuration. Je n'y crois franchement pas un seul instant, m'enfin après tout, cela ne coûte rien d'essayer.

Quand tu dis que tu as testé avec une VM, tu fais bien des requêtes DHCP, oui ? Nous sommes bien d'accord que jamais, au grand jamais, tu n'essayes d'obtenir du service avec une IP attribué manuellement ? J'ai déjà testé avec un portable, et même avec un windows, il gère bien le machin. Ta VM ne devrait pas avoir de soucis (cependant, et si tu le souhaites, tu peux me soumettres la configuration réseau que tu obtient sur ta VM après avoir fait une requête, plus l'heure pour que je compulse mes journaux, histoire de vérifier si c'est correct).

Pour ce qui est de rediriger l'ensemble des ports vers une IP, je t'ai fait une redirection de port type, elle est désactivée pour l'instant.

Pour ce qui est des /32, c'est quand même très souple et très pratique, et plus abordable pour des sociétés comme Knet qui n'ont pas les moyens ni l'historique suffisant pour avoir des IP plein le grenier (pour information: les /32 sont annoncés en BGP sur certain point, mais évidement pas en inter-AS)

milky: en gros, c'est des switchs non ?

[miky01]

milky: en gros, c'est des switchs non ?

Non des media converteurs utilisés pour des liaisons entre 2 sites, c'est ca:
https://www.perle.com/products/gigabit-managed-media-converters.shtml

[Klona]

Hello,
merci pour l'action à minuit !

Premier changement déja suite au reset, je n'ai plus d'erreur quand je sauvegarde le routage DMZ.
Mais il reste inactif.. La case "actif" se décoche toute seule..
J'ai laissé en l'état. Je n'ai aucun service critique sur la ligne Knet pour l'instant, en tout cas rien qui ne soit redondé en adsl free et orange.. Tu peux reseter, casser, refaire tout ce que tu veux sur le routeur, avec coupure de service, pas de pb.

Plus je creuse plus je pense qu'il y a un bug dans mon netgear.
Je testerais ce soir le bridge pour voir.

On lance une ouverture Knet pour un de nos clients à saint michel sur orge.Et je suis sur qu'on aura pas ces problèmes (hormis peut etre la gateway hors subnet qui peut facher le routeur actuel du client)

/klona

EDIT : Oui, toujours DHCP, j'ai vu que vous aviez des sécurités basées la dessus.
C'est juste une route vers la gateway qui est ajoutée manuellement.

[ebouchez]

Bonjour,

Je suis nouvel abonné et j'ai reçu mon modem K-NET aujourd'hui et souhaite m'en passer car le debit en wifi est de l'ordre de 1 à 3 Mbps en download alors que je suis à 94 Mbps par ethernet. Je suis à Bailly-Romainvilliers dans le 77 sur le réseau SEMAFOR77.

J'ai 2 routeurs à ma disposition tous 2 flashés avec le firmware DD-WRT,  le plus ancien le Linksys se connecte bien et fonctionne normalement à la place du routeur K-NET sauf que comme il est ancien j'ai des débit réduits de moitié environ 42 Mbps en ethernet par contre avec mon nouveau routeur un Netgear WNDR3700V j'arrive bien à obtenir l'ip fixe la gateway et les DNS par DHCP mais aucun paquet ne passe à l'extérieur.

Y aurait-il une combine ou quelque chose qui m'échappe et que quelqu'un aurait trouvé avant moi?

Merci d'avance.

[Klona]

Bonjour ebouchez,
de mon coté,je n'ai pas trouvé de routeur qui accepte de fonctionner en DHCP + gateway hors plage.. Encore tenté hier avec un Cisco Meraki Z1 et un MX100 mais ... ben..non..
J'ai peur que ce soit ce probleme aussi avec le WNDR3700V.

La meilleure solution est de mettre une vraie borne wifi en plus, comme une WAP321. Ou à cout plus réduit une Draytek ou une netgear (celles en boitier metal je sais plus la ref). Ou si on aime bien avoir des problemes, une Dlink..

[ebouchez]

Merci Klona,

C'est vraiment dommage cette gateway hors plage qui pose problème à plein de modems.

Comment fait ont pour passer le routeur K-Net en mode bridge car je n'ai pas possibilité de le faire dans l'onglet "avancé" je n'ai que de la Redirection de ports mais pas de case à cocher pour le passer en mode bridge?

Enfin pas d'IPV6 comme c'est indiqué sur le site.

Bonne soirée.

[Klona]

Hello,
si tu n'as pas passé ton netgear Knet en bridge, tu as juste 2 routeurs chainés. Ca doit marcher, mais tu ne dois surtout pas avoir les meme plages IP des 2 cotés.

Tu mets par exemple le LAN Knet en 192.168.2.254, DHCP activé, ton routeur WRT coté WAN récupère une adresse IP 192.168.2.x, et tu mets coté LAN de ton WRT une adresse IP pour ton LAN avec tes PC.

Et si tu n'as pas l'option bridge sur ton interface Knet... aucune idée.. sorry.. Il va falloir qu'un GO Knet regarde...

[jack]

ebouchez: tu es sur un réseau Covage, l'IPv6 n'y est pas disponible.
Le mode bridge non plus : il te suffit de remplacer la Kbox par ton équipement.

En effet, les réseaux Covage fournissent un CPE qui s'occupe des vlan etc etc, à la différence des réseaux d'Europ'Essonne par exemple.