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

Bon je crois qu'on va oublier pour le schéma, j'essaierai de le lire dans le train mais là pour l'instant ça m'a pas spécialement aidé (quand je disais go MS Paint je rigolais qu'à moitié ), mais clairement l'énoncé de ton problème signifie que tu avais loupé une étape dans la configuration du pare-feu sous BSD.
ça se saurait, si les *BSD ne savaient pas faire un malheureux NAT (sachant qu'en terme de fonctionnalités avancées, packet filter a une réputation plus prestigieuse qu'iptables )

Bah ça parait un peu gros que j'aie raté la configuration de pf alors que tout fonctionnait avec ma VM sur le même hyperviseur

M'enfin bon tant pis, ce n'est plus vraiment un soucis mais la résolution m'intéresse

Les NAT qui marchent pas sous Linux, c'est parce que l'ip forwarding n'est pas activé par défaut au niveau du noyau Linux.

Une fois activé, avec un iptables qui fais du masquerade, le NAT marche trèèèès bien.

« M'enfin bon tant pis, ce n'est plus vraiment un soucis mais la résolution m'intéresse »

De même, j'aime pas les mystères.

Nh3xus loupé, là il avait foiré sous BSD / réussi sous Linux

Bon je vous laisse sinon je rate mon train, soyez sages

Non t'inquiètes je suis pas un noob Bien sûr qu'activer l'ip forwarding est la première chose que j'ai faite, je ne l'ai pas faite sur BSD car je ne savais pas comment faire mais bon ça fonctionnait j'arrivais à envoyer des paquets par le NAT avec ce cas particulier.

Non mais dire de BSD que c'est de la merde parce que tu n'as pas cherché, c'était purement une connerie

Jamee Ah ok.

Pour les BSD, je vais pas me prononcer vu que je n'en ai jamais utilisé.

Un NAS avec un vieux PC sous NetBSD, ça tient ?

Euh j'ai cherché j'ai passé plus de 3h sur le soucis non stop avant d'abandonner et faire la même config en 10min sous iptables fonctionnelle quand même

Même si ça veut rien dire je serais toujours un partisan de Linux