[Résolu] PfSense 1.2.2 + VLANs + Procurve 2626
-
Merci beaucoup pour l'astuce mais ça ne tourne toujours pas malgré différents essais =(. Voici la config' mise en place par interface :
(Tous les VLANs sont sur mon interface nge0, tout est en /24).
LAN : 192.168.254.1 sur VLAN 254
Salle 1 : 192.168.10.1 sur VLAN 10
Salle 2 : 192.168.20.1 sur VLAN 20
Salle 3 : 192.168.30.1 sur VLAN 30Plus rien ne concerne le VLAN par défaut. Excepté dans mon switch principal où les ports non branchés sont untagged VLAN 1.
Malgré cela, PfSense continue d'émettre les trames suivant le SYN-SYN/ACK-ACK sur le VLAN par défaut…je commence sérieusement à songer à un bug.
Merci encore pour votre aide. Si vous y comprenez quelque chose, n'hésitez pas.
-
Quitte à explorer toutes les pistes, je me demande si ma carte gère convenablement les VLANs (elle devrait…vu que tout marche sauf l'interface web), mais un détail m'a mis la puce à l'oreille :
Ma carte est une SMC9452TX. FreeBSD devrait utiliser le driver sk selon la HCL. Mais ma carte est reconnue comme étant une nge0. A mon avis il y a anguille sous roche à ce niveau là.
Une autre chose troublante : je dispose de deux interfaces réseau dans ma machine (nge0 et bge0). Pourtant, PfSense reconnait en plus une interface plip0. Google me dit que ce n'est pas dramatique, mais dans le doute, je préfère le signaler...
-
Problème résolu, merci à tous. La carte réseau que j'utilisais utilise normalement le driver sk selon la HCL. Pourtant, elle utilisait le driver nge (sans que je ne sache pourquoi…). Je n'ai pas cherché plus loin, j'ai simplement inversé les deux cartes physiques dans ma configuration (l'autre carte étant en bge, je n'ai pas la référence exacte, elle gère parfaitement les VLANs).
Je n'ai aucune idée du pourquoi du comment, mais tout fonctionne avec cette configuration la. NB : avec une MTU de 1500, je n'ai aucun souci d'accès à internet. Je déconseille donc l'emploi de la SMC 9452TX pour les VLANs sur du FreeBSD, il semble que quelques soucis soient encore d'actualité.
-
Je serai curieux de connaître la fin de l'histoire.
Je viens de tester PFsense ainsi que Zeroshell en multiwans et multilans.
Je me suis retrouvé confronté à des soucis dans tous les sens, des demi-plantages, avec obligation de redémarrage pour retrouver quelque chose de cohérant.
Dès que j'ai essayé de faire du multiwan en pppoe, ca a été la catastrophe : PFsense n'accepte qu'une interface pppoe, et zeroshell est incapable de faire une reprise suite à une rupture de session. L'interface reste en fault.
Le PPPoE depuis le routeur avec modem en mode bridge RFC1483 est la seule solution en ADSL pour obtenir de l'IPv6 natif. Il faut donc qu'il soit géré correctement par les routeurs.
Finalement, je suis revenu sur mon viel Openwrt version Whiterussian 0.9, moins puissant certe, mais qui fonctionne correctement, y compris avec IPv6 en PPPoE natif sur un lien ADSL nérim.
J'en conclus qu'il ne faut pas essayer de faire trop compliqué avec ces outils gratuits, à moins de vouloir perdre beaucoup de temps.
Entre zeroshell qui se mélange les pinceaux dans le masquerading en inversant les adresses IP publiques entre interfaces ou en oubliant carrément de faire la translation, et Pfsense qui refuse de faire fonctionner du multi LAN lorsque du multi Wan est présent, j'ai cru que j'allais devenir fou…
Alors j'ai essayé par dépis Pfsense 2.0 alpha. On peut dire qu'il porte bien son nom. Au point ou il en est il faudra un certain temps pour avoir quelque chose de stable....
Je commence à me demander si du Cisco d'occasion ne serait pas plus raisonnable pour faire ce genre de choses.
-
Pfsense qui refuse de faire fonctionner du multi LAN lorsque du multi Wan est présent
Pouvez vous expliciter cette phrase ? Je ne comprend pas le problème auquel vous avez pu vous retrouver confronté.
Je confirme que l'utilisation de multiple PPOe peut poser problèmes. Il faut bien prendre en compte que pfSense est à la base conçu pour une utilisation professionnelle (haute dispo, équilibrage in/out etc) , monde dans lequel PPOe fait rarement son apparition, où alors dans des pays légèrement en retard sur les technologies de communication. Pour ma part je me suis retrouvé confronté à ce genre de problème en angleterre, en allemagne et à Dubai. Même si c'est dur à croire…les SDSL pro son livrées en PPOe...
-
Je suis en train de reprendre tout à 0 avec Pfsense, j'ai initialement eu des problèmes d'accès au firewall, depuis des interfaces OPT utilisées pour des LANs supplémentaires (carte quatre port en driver bge).
Je n'ai pas continué dans cette voie multilan sur interfaces physiques, je suis passé à du multilan sur VLAN, et là tout semble fonctionner. Il est possible que des erreurs de manipulation de ma part ait planté mon fichier de configuration initialement.
Je viens d'avoir un gros soucis d'ailleurs en effaçant des interfaces OPT sur VLAN, créant une erreur XML OPTXXXX paralisant le système. Edition manuelle du fichier config.xml, effacement du cache, pour repartir…. Je ne suis pas le seul a avoir eu ce probleme, les corrections apportées au code n'ont apparement pas été suffisantes, dans le cas de l'utilisation de Vlans.
En ce qui concerne le PPPoe, c'est la seule solution en France je pense pour avoir de l'IPv6 natif sur ADSL sans passer au SDSL ou fibre.
D'ailleurs je ne connais pas de modems ADSL capables de sortir de l'IPv6 directement en IP. Si vous en connaissez un, cela m'intéresse, car le PPPoe est souvent la cause de problèmes sous Linux et BSD lors des ruptures de sessions, notament en ce qui concerne le load balancing, failover, ou la corruption de la cible masquerading, avec parfois des firewall qui oublient de remettre la bonne IP publique sur le marquerading après la reconnection (cela se produit sur des lignes en pppoe dynamique, alors que le fournisseur envoi une ip statique dans l'ouverture de session pppoe). Dans ce cas l'IP interne est envoyée sur le WAN, avec les conséquances de non retour des informations évidement. (problème survenu dans un centre d'appel et confirmé à plusieurs reprise par une analyse de trame sur leur wan).
L'adsl n'est pas ridicule professionellement parlant, il permet d'avoir de l'IPv6 natif, ainsi que des débits descendants élevés, pour la navigation web. Le SDSL est limité en pratique à 4 Mbits, les liens 8 Mbps étants limités à de très courtes distances et très chers.
Mais je suis d'accord avec vous, le pppoe est une abération technique aujourd'hui, le plus efficace en terme de débit étant l'IPoA, et le plus simple à mettre en oeuvre le MER ou IPoEoa, le tout en encapsulation vc mux, pour éviter les octets inutiles du LLC.
Une autre abération est la non disponibilité d'offres multi VC ADSL, qui permettraient de faire de la téléphonie dans de bonnes conditions de QOS, pour les petites entreprises. La pression des associations comme l'affut ne semble pas vraiment faire avancer les choses. Les petits opérateurs ne semblent pas prêts non plus à faire des efforts, la simple idée de plonger le nez dans la ligne de commande de configuration ATM sur les modems ADSL pour faire du multi-vc et/ou de l'IPoA semble les effrayer. C'est bien dommage.
La Qos sur IP ne pourra jamais donner de très bons résultats avec la technologie actuelle. Le jitter n'est pas garanti, et la bande passante non réservé. On est encore loin d'un asterisk ou d'un IPBX qui saurait utiliser RSVP de bout en bout pour accepter des appels.
En utilisant de l'adsl couplé à du sdsl en multiwan pour une même entreprise, on obtient un bon rapport fiabilité / qualité / performances.
J'ai commencé à tester la partie QOS de PFsense, qui semble très interessante pour la téléphonie car le HFSC devrait permettre en théorie de garantir le jitter.
Dans la pratique, les premiers essais que j'ai réalisé avec la version 1.2.3 et le wizard ne sont pas satisfaisants. Le traffic VoIP n'est pas traité dans le sens montant, malgré un changement de la règle qos avec filtrage sur protocole UDP.
Les buffers asterisk montent à leurs valeurs maxi configurée de 1 seconde lors d'une saturation du lien ADSL par du FTP, ce qui est anormal.
L'interface GUI montre une queue VoIPdown vide également, avec tout le traffic UDP qui part dans la queue par défaut.Enfin les règle de filtrage QOS sont d'un autre age dans PFsense, cela fait longtemps qu'on utlise plus le champ TOS avec les indicateurs Low delay, High throughput, High reliability, etc. Tout cela est remplacé par la définition DSCP, qu'on retrouve dans tous les switchs, téléphones IP, ainsi que dans les logiciels de téléphonie tels que Asterisk depuis plusieurs années.
voir :
http://www.franceip.fr/memo.pdf -
Le multilan sur interfaces physiques doit fonctionner sans problème. J'ai des setup avec des dizaines de LAN physiques…et des dizaines (ou centaines ;D) de milliers de sessions/s sans aucun problème. Pour IPV6....c'est un problème d'argent et de retour sur investissement....quand les offres IPV6 "bout en bout" seront généralisées les outils suivront (enfin espérons-le :) )
Je suis d'accord pour la partie ADSL/SDL pour equilibrer flux métiers et surf, c'est la tendance actuelle. Il faut juste avoir un bon nombre de lignes pour éviter les étranglements en uplink et prioriser les ACK sur les SYN.Enfin pour tout le reste...ce sont des sujets ouverts à de vastes débats. ;D
Enfin(bis) la présence de la gestion des bits TOS dans les règles de QOS n'est là que pour assurer une compatibilité avec un maximum d'équipements déjà en place. Là encore, ce type de technologie, même dépassée, est encore largement utilisée (même dans les très grosses infra).
-
Certe le TOS est encore largement utilisé, mais cela ajoute à la confusion des utilisateurs, qui se retrouvent avec un fouillis QOS qu'aucune interface graphique ne saura démèler.
Dans la pratique, le TOS pour l'utilsateur en entreprise n'a pas vraiement d'intérêt puisqu'on trouve dans la plupart des matériels et logiciels actuels d'entreprise le DSCP, qui est la norme en vigueur.
De plus les opérateurs français ne prennent pas en compte la QOS TOS/DSCP en provenance du WAN de l'entreprise, sauf contrats très spéciaux et hors de prix. Il est donc un peu inutile dans un logiciel destiné aux entreprises de mettre les anciennes définitions TOS sous prétexte de compatibilité avec les grandes installations des opérateurs.
Mettre les deux définitions me semble le plus judicieux, avec un choix par menu, et éventuellement pour les nostalgiques du TOS la visualisation de l'interdépendance de chaque bit sur les deux normes.
Par exemple, beaucoup confondent COS (class of service), qui est une prioritisation niveau 2 par l'entête VLAN, avec TOS, DSCP, lorsqu'on parle d'IP precedence on ne sait pas très bien s'il s'agit de l'entête VLAN 802.1p ou des trois premiers bits du DSCP, etc etc.
Tout cela est pourtant très clair techniquement, malheureusement le foutoir des interfaces et des documents disponibles sur la QOS plongent l'utilisateur dans un profond désaroi, au point que 99,5 % des switchs et routeurs supportant la QOS en entreprise sont toujours laissés sur leur réglages par défaut, sans QOS.
Il est vrai aussi que les opérateurs en France ne font rien pour développer la QOS, et qu'il la freine certainement volontairement, pour éviter une bascule trop rapide de la téléphonie RTC vers la téléphonie et les services IP temps réels, alors que leurs connaissances et leurs infrastructures ne sont pas encore prêtes. C'est bien dommage, car 98 % des problèmes de qualité en IP proviennent d'une dégradation du timing des trames au sein des réseaux opérateurs.
Il faut absolument faire cesser cette croyance qui arrange les fabricants de switchs d'entreprise, qui est de croire que la QOS sur les switchs va résoudre les problème de qualité audio en téléphonie IP. C'est totalement faux.
La qualité en IP temps réel commence sur le routeur wan de l'entreprise, ou le flux montant doit particulièrement être soigné par les règles QOS, mais aussi et surtout chez les opérateurs, qui pour la plupart n'ont pas envie de se prendre la tête avec de nouvelles offres QOS et une refonte du réseau IP européen pour prendre en charge la QOS à cet échelon.
L'utilisateur final, ou administrateur, a besoin de voir les choses clairement, car il n'a pas forcément la culture informatique d'un ingénieur passionné qui connait l'historique de toutes ces normes.
C'est pour cela que je pense que les interfaces graphiques doivent être plus soignées encore que ce qu'on trouve actuellement, pour aider l'utilisateur à ne pas se mélanger les pinceaux dans le monde complexe du routage et de la QOS.
C'est encore plus vrai avec IPv6, où les interfaces graphiques des logiciels vont jouer un grand rôle dans l'éducation des administrateurs (Cisco n'a jamais compris cela :=)
Je vous donne un simple exemple :
Dans Pfsense 1.2, pour un sous réseaux 192.168.100.0/24, l'interface gui pour le serveur DHCP donne la zone d'adresses disponible suivante (available range) :
192.168.100.0 à 192.168.100.255
l'utilisateur moyen va tout de suite penser qu'il peut utiliser toutes ces adresses dans sa plage d'adresse DHCP, alors que :
192.168.100.0 est inutilisable, c'est l'adresse du sous réseau
192.168.100.1 est inutilisable, c'est l'adresse du firewall (en général)
192.168.100.255 est inutilisable, c'est l'adresse de broadcast du sous réseau.
Tout cela pour dire que vu le temps, les mois, les années, que les développeurs passent sur la programmation de leurs projets, qu'il soit opensource ou commercial, une toute petite partie de ce temps devrait être consacré à l'amélioration de l'interface graphique. Elles seraient alors splendides et très pédagogiques.
Il existe aujourd'hui des outils de programmation fantastiques pour des interfaces graphiques très réactives en web 2.0, mais même en html basique, il est possible de faire simple, ergonomique et facile d'utilisation.
Je ne comprends pas comment des projets sur lesquels il y a des dizaines de milliers d'heures de programmation puissent se retrouver avec des interfaces moyennes, qu'il s'agissent de PFsense, qui est un des mieux placés, comme les autres.
Peut être faudrait il que des débutants se penchent sur les interfaces, afin de faire remonter aux programmeurs leurs incompréhensions.
-
Bonjour à tous et petite question à ccnet,
Comment fais tu pour supprimer la configuration de la carte en tant qu'interface.
J'ai regardé sur ton lien et cherché dans les menus pfsense sans succès
J'ai essayé via le menu ligne de commande là non plus je n'ai pas trouvé/réussi.
… je supprime, dans la configuration la carte en tant qu' interface, puis je créé les Vlans sur cette carte. En d'autre termes je n'utilise pas une carte physique à la fois comme interface et comme Vlan. Je suis souvent obligé de redémarrer Pfsense.
Ainsi que ce lien : http://doc.pfsense.org/index.php/HOWTO_setup_vlans_with_pfSenseSi vous avez l'info ou même un piste je suis preneur.
David
-
Deux questions au préalable pour tenter de vous aider :
1. Combien de cartes physiques avez vous sur votre système ? Lan et Wan ne peuvent pas être supprimées.
2. Si vous avez au moins 3 interfaces physiques, supportent elles les vlans ? -
Hello,
Merci de ta rapidité!
J'ai 4 cartes, je n'en utilise que 2.
Et en effet j'ai constaté que LAN et WAN ne se supprimaient pas.
Oui mes cartes supportent les vlans.
Si j'ai bien lu entre les lignes tu va me proposer de mettre le LAN sur une interface non utilisée (connectée à rien ) et une carte opt dont je me servirai réellement pour le LAN (donc mes vlans)…
C'est bien ça?
Si non pour le moment mes vlans sont OK, bien créés sur le pfsense et sur le switch.
En fait je suis en train de prendre pfsense en main, j'envisage une mise en production d'ici un bon mois. Donc je teste les différentes fonctionnalités
Deux questions au préalable pour tenter de vous aider :
1. Combien de cartes physiques avez vous sur votre système ? Lan et Wan ne peuvent pas être supprimées.
2. Si vous avez au moins 3 interfaces physiques, supportent elles les vlans ? -
Si j'ai bien lu entre les lignes tu va me proposer de mettre le LAN sur une interface non utilisée (connectée à rien ) et une carte opt dont je me servirai réellement pour le LAN (donc mes vlans)…
C'est bien ça?
Non.
Si non pour le moment mes vlans sont OK, bien créés sur le pfsense et sur le switch.
Quel est alors le problème ?
-
Hello,
Arf, perdu, pas trouvé…
Et bien, je n'ai pas de problème, mais lisant le post et voyant qu'il était possible de désactiver l'interface LAN, j'ai essayé de le faire sans succès.
Je suis en train de tester pfsense en vue de mettre en prod dans les mois qui viennent et j'essaie les configs et paramètres qui correspondent le plus à ma situation.
J'essaie de tirer de pfsense le plus possible en termes de sécurité et fonctionnalités.Donc désactiver l'interface physique lan (untagged par nature) et garder les vlans sur cette interface m'intéresse.
Si je n'y parviens pas, ce n'est pas grave mais si je peux le faire pourquoi s'en priver?
David
Si j'ai bien lu entre les lignes tu va me proposer de mettre le LAN sur une interface non utilisée (connectée à rien ) et une carte opt dont je me servirai réellement pour le LAN (donc mes vlans)…
C'est bien ça?
Non.
Si non pour le moment mes vlans sont OK, bien créés sur le pfsense et sur le switch.
Quel est alors le problème ?
-
La question n'est pas de s'en priver ou pas mais d'en avoir l'usage. Pour répondre à votre question :
1. Interfaces: Assign supprimer la carte à utiliser pour les vlan (par exemple OPT2)
2. Interfaces: VLAN : cliquer sur le + et sélectionner la carte non assignée pour y mettre un ou plusieurs Vlans.
3. Interfaces: Assign pour utiliser le Vlan créé
4. Redémarrez Pfsense. -
Merci ccnet,
Et donc si g bien compris, cette manip ne peut pas être faite avec l'interface "LAN" vu qu'on ne peut pas la supprimerIl faut donc que les interfaces virtuelles des VLANs soient créés sur une autre carte réseau/interface que la carte "LAN"?… (donc une carte OPTx)
David
La question n'est pas de s'en priver ou pas mais d'en avoir l'usage. Pour répondre à votre question :
1. Interfaces: Assign supprimer la carte à utiliser pour les vlan (par exemple OPT2)
2. Interfaces: VLAN : cliquer sur le + et sélectionner la carte non assignée pour y mettre un ou plusieurs Vlans.
3. Interfaces: Assign pour utiliser le Vlan créé
4. Redémarrez Pfsense. -
Oui.
-
Merci ccnet.
Je continue dans mes tests et après avoir changé une carte réseau (changement/remplacement physique de carte), je remarque que c'est le foutoir.
J'ai bien ré-assigné les interfaces physiques via le menu mais ensuite la seule interface sur laquelle je peux me connecter à l'interface web de pfsense est mon interface LAN (que je n'avais pas supprimé, OUF!)Il a donc fallu que je recrée toutes les interfaces virtuelles des VLANs puis reconfigurer (une par une ces interfaces virtuelles (renommer, ré-attribuer IP, activer).
Notez encore que ce qui est trompeur, c'est que, connecté dans un VLAN (le 7) je recevais une IP mais ne parvenais à rien faire. En fait, après l'échange de carte réseau et la ré-assignation des cartes les VLANs sont toujours créés, le DHCP tourne mais les interfaces virtuelles ne sont pas créées/assignées. Donc je recevais une ip en 192.168.7.x (range de mon vlan7) mais ne parvenais pas à surfer ni atteindre l'interface web de pfsense!
Donc finalement est il si conseillé de désactiver l'interface physique LAN. Ne vaut il mieux pas la garder active mais reliée à rien et attribuer les vlans sur une carte/interface OPT qui elle est reliée au switch (et de là VLANs)?
Car visiblement cette interface LAN reste l'accès de secours à l'interface de pfsense en cas de problème…Je me suis permis de poster cette remarque ici vu que dans mes recherches autour des vlans et leur config je tombais souvent sur ce post.
J'espère ne pas dire une annerie...
David
Oui.
-
Donc finalement est il si conseillé de désactiver l'interface physique LAN. Ne vaut il mieux pas la garder active mais reliée à rien et attribuer les vlans sur une carte/interface OPT qui elle est reliée au switch (et de là VLANs)?
Personne, en tout cas pas moi, ne vous a conseillé de désactiver l'interface Lan, et encore moins la suite.
-
Pas de soucis CCNET, loins de moi l'idée de t'attribuer la suggestion de supprimer l'interface LAN.
Merci pour tes bonnes infos
Bien à toi
David
Donc finalement est il si conseillé de désactiver l'interface physique LAN. Ne vaut il mieux pas la garder active mais reliée à rien et attribuer les vlans sur une carte/interface OPT qui elle est reliée au switch (et de là VLANs)?
Personne, en tout cas pas moi, ne vous a conseillé de désactiver l'interface Lan, et encore moins la suite.