Il n'y a pourtant qu'un pas entre BSD et Linux, et pourtant c'est un univers tellement différent

Mais tu sais Google_Bot, j'ai comme un drôle de pressentiment, j'ai l'impression que BSD va bientôt passer à la casserole Qu'il va hériter de truc de merde venant des bad guys de chez Linux, qui sait, si ça se trouve, Canonical va aller faire son marcher la bas et commencer à mettre de la merde partout

Sinon pour les experts de BSD, est-ce sur BSD l'arp forwarding est désactivé par défaut et si oui comment on l'active?
J'ai mis 2h pour comprendre un soucis de routage sur mon routeur BSD, au final j'ai abandonné et fait la même config en 10min sous iptables et ça fonctionne. BSD c'est de la grosse merde

"BSD c'est de la grosse merde "

Ok G_B, kick le, c'est un troll.

Bah les gens parlaient beaucoup de BSD pour le routage et tout, j'ai voulu essayer je regrette amèrement Mais la doc est excellente par contre.

« Le soucis c'est que par exemple dans le lien que tu m'as posté où le mec à son ubuntu qui démarre plus y a pas une trace de log, pas un seul message d'erreur explicite et surtout pas une seule réponse de l'auteur.

Ce qui porte à croire que ce n'est qu'une vaste blague Difficile de prendre ce genre de problèmes au sérieux du coup. »

Je commence à me demander si c'est pas toi la vaste blague dans cette histoire.
https://www.jeuxvideo.com/forums/1-38-7728047-1-0-1-0-enorme-bug-passage-a-ubuntu-12-04.htm#message_7728047 (classique coup de la màj)
https://www.jeuxvideo.com/forums/1-38-7758979-1-0-1-0-probleme-avec-ubuntu-13-04.htm (ya pas 15 façons d'installer Ubuntu, et pourtant...)
https://www.jeuxvideo.com/forums/1-38-7726540-1-0-1-0-ecran-violet.htm#message_7726554 (mieux, kernel panic direct depuis le live DVD)
https://www.jeuxvideo.com/forums/1-38-7773464-1-0-1-0-help-ubuntu-12-10-ecran-noir-demarrage.htm#message_7773464
https://www.jeuxvideo.com/forums/1-38-7735512-1-0-1-0-ubuntu-bug-depuis-le-passage-en-12-10.htm#message_7735512

Breeef la liste est longue comme le bras donc t'es gentil mais si t'en veux plus, tu cherches tout seul

T'es du genre à défendre Ubuntu sur le fait que PARCE QUE tu n'as pas eu de problèmes, ils sont superficiels mais tu n'hésites pas à dénigrer tout un OS pour un problème ? Au revoir l'ami

(j'avais pas encore vu le post en question, cf. le temps que je perds à faire des recherches à la place du principal concerné)

Btw "ARP forwarding" ça ne veut rien dire (on va partir du principe que tu voulais parler d'IP forwarding...), et c'est clair que si tu fais pas d'efforts pour apprendre à utiliser un pare-feu que tu ne connais pas, tu n'arriveras à rien.

Pas compris le kick sur le coup mais bref.

L'arp forwarding qui veut rien dire...

Ca existe bel et bien et c'est nécessaire dans certains cas. Là clairement ça pouvait être qu'un soucis d'ARP.

Sur un vlan isolé j'ai un subnet 192.168.0.0/24 avec une machine virtuelle BSD qui fait office de routeur sur 192.168.0.254. Tout fonctionnait si je me plaçais dans le subnet en utilisant une autre VM sur le même hôte mais dès qu'on se branchait sur un port du switch et qu'on se plaçait dans le vlan isolé rien ne va plus. Je pouvais pinger la machine, pinger toutes les machines du subnet mais rien ne passait au travers du NAT et impossible de joindre l'extérieur.
Après installation de Debian et configuration d'iptables tout fonctionnait donc ça ne vient pas de l'hôte qui bloquerait les requêtes ARP et de toute façon j'étais déjà en bridge donc le forward devait se faire dans tout les cas.

« Pas compris le kick sur le coup mais bref. »

Relis les messages au dessus

« rien ne passait au travers du NAT et impossible de joindre l'extérieur. »

Et tu t'es pas dit que ton NAT pouvait avoir un souci? ça se vérifie assez rapidement à coup de capture de paquets sur les différents noeuds ça, pour le coup j'ai l'impression que t'as pas essayé longtemps.
Je ne vois strictement pas en quoi un ARP forwarding (que j'ai probablement dû croiser sous un autre nom, parce qu'en l'état on ne trouve pas beaucoup de littérature à ce sujet en cherchant ce terme ) aurait aidé ton NAT à marcher. Par définition, le NAT opère sur IP et TCP, et aucun paquet ARP n'a besoin de circuler d'un réseau IP à un autre réseau IP... c'est le routeur qui se démerde pour faire les résolutions nécessaires des deux côtés justement

« de toute façon j'étais déjà en bridge donc le forward devait se faire dans tout les cas. »

T'étais en bridge OU tu faisais du NAT?

http://www.sjdjweis.com/linux/proxyarp/

C'est bien sous ce nom que je l'ai vu passer, j'me disais aussi

Je n'ai plus non plus un très haut niveau théorique en réseau (surtout pratique) mais je crois que c'est le client qui s'occupe de récupérer le paquet ARP depuis le routeur, en tout cas dans le routage normal ça fonctionne comme ça. Pour un NAT à priori ça devrait pas changer.

Et oui je me suis mal exprimé, l'interface sur mon hôte qui accueille les paquets du vlan 21 (il s'agissait de ce vlan ci) est bridgé avec l'interface de la VM BSD. C'est de ça que je parle quand je dis que j'étais en bridge.

De toute façon c'est un problème extrêmement complexe, et Wireshark ne m'aurait pas aidé ça aurait juste confirmé que le client ne voit pas les paquets arp et que les paquets au dela du NAT ne passait pas. J'aurais aimé le résoudre mais c'est un peu trop faut croire

PS: Je plaisantais quand je dis BSD c'est de la merde ça me semble assez évident à voir pourtant.

Enormissime, NetBSd est enormissime
SI on oublie ce problème de libdrm, en fait, pkgsrc-wip (packages sources work-in-progress) possedant donc tout ce qui n'est pas inclus dans les pkgsrc de base peuvent être récuperé ici http://pkgsrc-wip.sourceforge.net/snapshots/ et donc, bonjour nouveau ou nvidia, bonjour mumble, umurmur, virtualbox etc...

J'ai rien dis, le paquet arp récuperé par le client c'est pas un comportement par défaut. La norme c'est en effet de laisser TCP/IP faire le boulot. Du coup je vois absolument pas d'où ça peut venir c'est quand même énorme comme problème

Va falloir que tu fasses un schéma je pense (même un truc viteuf' à la MS Paint hein), je sais abstraire des réseaux dans ma tête mais là j'ai l'impression qu'il me manque des éléments pour bien saisir la config que tu voulais déployer.

« c'est le client qui s'occupe de récupérer le paquet ARP depuis le routeur, en tout cas dans le routage normal ça fonctionne comme ça »

En temps normal, le client n'a que trois données pour blablater (sur son réseau ou sur un autre): son IP propre, le masque qui vient avec, et sa table de routage (avec éventuellement une route par défaut et/ou des routes définies en dur).
S'il est en 192.168.0.12 et qu'il veut envoyer un ping à 192.168.1.5, il commence par appliquer son masque de subnet pour constater qu'il n'est pas sur le même résal (pas de surprise jusque là), s'ensuit un lookup dans la table de routage pour voir si 192.168.1.0/24 est joignale (et le cas échéant, par quelle route).
Coup de bol, il a une passerelle par défaut (on reste dans un cas classique, je pense que c'était comme ça sur ton VLAN) en 192.168.0.254 , du coup c'est par lui que passera son ping. Mais pour ça il faut connaitre l'adresse MAC associée à 192.168.0.254 pour blablater au niveau Ethernet, et zou, requête ARP ("Who has 192.168.0.254? Tell 192.168.0.12"), le routeur reçoit, répond, et c'est plié (le ping est forgé, avec comme @MAC destination l'adresse MAC de l'interface côté VLAN du routeur, et comme IP dest, 192.168.1.5).
Le routeur reçoit la trame Ethernet, remonte au niveau IP pour constater qu'il n'est pas le destinataire, se rappelle qu'il est un routeur ( ) et entame donc un processus de forwarding IP (et ainsi de suite).

« l'interface sur mon hôte qui accueille les paquets du vlan 21 (il s'agissait de ce vlan ci) est bridgé avec l'interface de la VM BSD. C'est de ça que je parle quand je dis que j'étais en bridge. »

C'est l'existence de "l'hôte" que j'ignorais, vraiment, need un schéma parce qu'entre les machines physiques, les VMs, le switch physique et les VLANs on va pas s'en sortir si j'ai les infos dans le désordre

En gros ça faisait comme ça, br0 (WAN en gros) -> eth0 ------------ routeur cisco
/
VM VM-BSD
\|/
br0_21 -> eth0.21 -> eth0 ------------ autre switch
|(port en trunk)
machine physique
En gros dès que qu'on reste sur le pont br0_21 ça fonctionne mais dès qu'on part d'un peu plus loin ça fonctionne plus wtf. Surtout qu'après remplacement de BSD par Debian sur la même configuration niveau réseau donc ça fonctionne

Bordel jvc à niqué mon beau schéma

http://pastebin.com/raw.php?i=1CXeT0nV

Et sisi, je t'assure qu'un Wireshark (ou tout autre outil d'écoute) foutu sur toutes les interfaces de chaque noeud "critique" en mode promiscuous, ça clarifie bien les choses (sauf si une machine autiste broadcaste dans tous les sens en continu, mais bon, ya des filtres pour ça ).

Rien que les messages renvoyés par ping (ou mieux, traceroute, on est pas des pauvres ) devraient t'aiguiller dans un premier temps.