[Résolu] PfSense 1.2.2 + VLANs + Procurve 2626



  • Salut à tous,

    Si je me décide à poster ici, c'est que ça fait plus de deux semaines que je sèche sur le même souci, un truc vraiment pénible. Vous êtes un peu mon dernier espoir ^^.

    Alors voilà : je dispose d'une architecture de VLANs comme suit :

    Mon switch est configuré très simplement. Il dispose d'une adresse IP par VLAN (toujours en X.254).

    De plus, les ports sont taggués / untaggued correctement. C'est à dire que le port du switch menant au PfSense (le premier) est taggué 10, 20, 30, 40, et 100.

    Les ports menant aux Vlans sont untaggués respectivement selon leur ID de Vlan.

    Venons-en au problème. L'architecture fonctionne très bien, les règles de firewall également (plusieurs tests, avec log de règles, et tout passe niquel, quand on interdit HTTP d'un VLAN vers le WAN, ça coupe le net, etc…). Le souci est simple : même si tout marche très bien, il reste encore quelques bugs étranges. Par exemple, je n'ai pas accès, depuis les VLANs, à certains sites bien particuliers (applestore, macgeneration, hotmail, entre autres). De plus, je ne peux pas me connecter à MSN depuis un VLAN. Je tiens à préciser que dans le doute, j'ai configuré des "trous" en guise de Firewall, histoire de balayer tout soupçon. C'est vraiment étrange car le surf marche très bien, mis à part sur certains sites. Pareil pour l'interface web PfSense. Si je suis dans le Vlan3 par exemple, que je tape https://192.168.40.1 dans mon navigateur, je reçois un "connecté à 192.168.40.1", puis plus rien. J'ai fait quelques examens avec Wireshark, et on dirait que des paquets TCP se perdent, car on arrive toujours à du RST de connexion.

    Je précise que j'ai laissé tout ce qui touchait au NAT en automatique.

    Quelqu'un saurait-il me dire si quelque chose cloche dans ma configuration ? J'ai lu sur certains forums qu'il ne valait mieux pas attribuer d'IP à l'interface physique. Mais j'ai fait quelques tests, soldés par un échec.

    Merci par avance pour votre aide =/.



  • Loi de murphy : c'est toujours quand on pose la question qu'on trouve la réponse après. J'ai résolu une partie de mon souci en passant la MTU du WAN à 1496, comme le spécifiait ce post' : http://forum.pfsense.org/index.php/topic,13014.0.html.

    Il me reste toujours l'autre souci : je suis incapable d'accéder à l'interface web de PfSense depuis un de mes Vlans =/. Il reste bloqué sur "Connecté à [ip]".



  • J'ai lu sur certains forums qu'il ne valait mieux pas attribuer d'IP à l'interface physique. Mais j'ai fait quelques tests, soldés par un échec.

    En effet j'ai toujours monté l'ensemble des vlans sur une carte physique marquée désactivée sur Pfense. La configuration mélangeant les deux m'ayant régulièrement posé problème.

    Il me reste toujours l'autre souci : je suis incapable d'accéder à l'interface web de PfSense depuis un de mes Vlans =/. Il reste bloqué sur "Connecté à [ip]".

    En vrac : Une coquille dans les règles, un nom de Vlan incorrect ? Rien dans les logs Pfsense ? Ping avec un paquet de 196 octets ? Ce n'est pas le Vlan monté sur la carte physique ?



  • Merci d'avoir répondu ^^.

    Monter des VLANs sur une carte désactivée, je veux bien, mais comment désactive-t-on la physique dans l'interface ?

    Le ping de 196 marche niquel. Pour les règles je viens de vérifier, tout est ok, il n'y a pas plus bateau, que des trous ^^.
    Les noms de VLANs correspondent parfaitement à ceux donnés dans le switch (à ce propos, qu'est ce qu'on entend par "nom de VLAN" ? Uniquement l'ID ? Ou bien aussi la description ?).

    Rien dans les logs PfSense si ce n'est que la connexion est acceptée de mon IP vers la sienne…qu'il est drôle ^^.

    Je soupçonne fortement cette histoire d'interface physique, étant donné qu'en bricolant un peu sur mes tagged / untaggued, je peux avoir accès à PfSense, mais seulement via l'IP de la physique.



  • J'ai retrouvé les infos que j'ai posté à ce propos il y a quelques mois.
    Pour le ou les Vlans 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_pfSense



  • Salut ^^.

    J'avais en effet vu ce tutorial, mais les rares fois où j'ai "tenté" de l'appliquer se sont soldées par un échec. Je vais essayer (avec un bon cp /cf/conf/config.xml avant =p) et je tiens au courant.



  • Il y a du neuf : je n'ai toujours pas essayé de virer l'interface physique, mais j'ai passé la matinée à faire des recherches sur une chose précise. En effet, via Wireshark, il me crache dessus (pour la connexion SSL à PfSense) en me criant que le TCP checksum est invalide (et ce dès le "Client hello"). Il me rajoute un "maybe caused by TCP checksum offload". Après avoir coché l'option correspondant à ça dans "Advanced", toujours la même chose. Je précise que la MTU est standard sur les interfaces autres que WAN. J'ai essayé de la passer en 1496 mais rien n'y fait.



  • J'ai "réussi" en taggant mes VLANs dans les deux sens…c'est extrêmement bizarre, si quelqu'un pouvait confirmer =/ on dirait du bricolage avec les tags, mais j'ai vraiment du mal à comprendre cette notion depuis que je l'ai apprise.

    Considérons un VLAN de VID 10 branché sur le port 10 du switch.
    Pfsense est dans le VLAN par défaut de VID 1 branché sur le port 24 du switch.

    Mon port 24 était taggé en 10 et untaggé en 1.
    Mon port 10 était untaggé en 10.

    L'état du port 10 pour le VID 1 était en "no" sur le switch.

    Pour que la connexion SSL avec PfSense fonctionne, j'ai dû, en supplément, tagger mon port 10 en 1....et là miracle, tout marche.

    C'est peut être logique étant donné qu'en réalité, derrière le port 10 se trouve un switch (sur lequel sont branchées diverses machines) non configuré (aucune IP, config' par défaut, pas de VLAN) qui attend des trames à destination du Default VLAN ?

    Je ne comprends vraiment pas la logique de ce truc, si quelqu'un pouvait m'éclairer...merci par avance.

    NB : j'ai dû faire ça pour tous mes VLANs, mais pour ne pas alourdir le post...



  • Du moment que l'on veut faire transiter plusieurs VLAN sur un lien a destination d'un switch on appelle cela un TRUNK. Le trunk en question peut être global (tous les VIDs) ou sélectif (un certain nombre de VIDs).
    Pour ma part j'utilise très fréquemment pfsense avec du matériel ProCurve et ce sans aucun soucis, sans "désactiver" la carte portant les VLAN.

    Un port d'un switch peut être untagged sur un seul VLAN, c'est le réseau de base de la carte. Imaginons une carte OPT2 branchée au port 1 du switch. Si ce port 1 est untagged dans le VLAN 15 alors la carte OPT2 pourra dialoguer avec les machines qui sont sur des ports untagged VLAN 15 ou TAGGED VLAN 15 (si la machine sait tagger ses paquets, ou si un switch intermédiaire est configuré en trunk) .

    Maintenant, si sur cette Carte OPT2 on créé un vlan 16, pfsense va créer une interface qui n'acceptera que les trames portant le tagg VLAN16. Le port 1 du switch faisant transiter désormais deux vlan (son vlan natif: le 15 et le vlan taggé le 16) il devient alors un port de trunk. Toutes les machines reliées à un port untagged dans le VLAN 16 sur le switch pourront alors dialoguer avec pfsense sur son interface VLAN16 (physiquement transportée par OPT2).

    Dans votr cas, la présence d'un switch intermédiaire non configuré comme trunk casse le contexte des vlan, obligeant un transit via le vlan par défaut.



  • Bonsoir,

    Merci pour votre réponse, en d'autres termes, à cause de ces switchs non configurés, je suis obligée de tagguer mes ports sur le VLAN par défaut pour qu'une communication puisse s'établir de PfSense vers le VLAN en question, dans le cas d'une SSL par exemple. Enfin c'est ce que je comprends du moins. Ou bien faut-il que je configure les switchs intermédiaires comme "trunk" ? Ce qui me semblerait bizarre, vu qu'ils ne concernent qu'un seul VLAN (et que cela ne changera pas).

    Il me reste un souci à ce niveau là. Certains VLANs sont reliés à des switchs, d'autres à des bornes Wifi du modèle Netgear WG102. Et la connexion à PfSense ne fonctionne pas à ce niveau là. J'ai bien l'impression que ces bornes ne gèrent pas les VLANs sur leur interface filaire en fait…c'est extrêmement bizarre. Auquel cas mis à part rajouter un switch, je ne vois pas comment configurer la chose. J'aurais bien aimé "centraliser" la configuration des VLANs sur un seul switch et sur PfSense. Vais-je être obligée de configurer chaque switch séparément sur un VLAN particulier pour que tout fonctionne de manière "clean" ? Même avec une architecture "en cascade" comme celle-là ?

    Merci par avance pour votre réponse.

    Edit : Bon, après maintes recherches, tout commence enfin à s'éclaircir. Demain, je vais procéder comme suit pour les switchs "inférieurs" en cascade : configurer un trunk entre eux et le switch global (c'est à dire tagguer les deux ports reliants les deux switchs entre eux sur le bon VLAN id). Ensuite, il me suffira sur le switch inférieur d'untagguer tous les ports reliés aux machines avec le bon VLAN id. Ca impose une configuration de chaque switch, mais je préfère avoir un truc propre.

    Là où je m'inquiète d'avantage c'est pour ces fichues bornes wifi…mais on verra sur le moment !



  • Pour les bornes wifi, il faut vérifier que le modèle propose la fonctionnalité de tagger le flux sur la sortie filaire, en fonction du SSID d'arrivée sans-fil.

    Bonne chance.



  • Salut,

    Merci pour l'info', effectivement les bornes le prennent en charge. Reste à voir au niveau de la configuration. Je vous tiens au courant.



  • Bonsoir à tous,

    Tout se passe bien, j'ai untag les VLANs correspondants entre les switchs (vu que ça ne m'aurait pas servi de les tagger). J'ai désactivé les VLANs sur les bornes wifi.

    Je n'ai qu'un problème (que j'avais au départ). Depuis mes VLANs, je suis incapable d'accéder à PfSense. La connexion reste bloquée sur "Connecté…". En d'autres termes, j'envoie bien le paquet de connexion SSL, mais je ne reçois pas la réponse. Je ne peux donc pas administrer PfSense depuis mon réseau, mis à part en passant par ma DMZ, ce n'est pas le plus pratique dirons-nous.

    Quelqu'un saurait-il d'où vient le souci ?

    Info' utile : un de mes VLANs se trouve derrière un switch non configurable. Lorsque j'untag le VLAN par défaut sur le port 24 (qui mène à PfSense) et que je tag le VLAN par défaut sur le port 1 (qui mène au-dit switch), la connexion à PfSense fonctionne depuis ce VLAN...je ne comprends décidément pas le souci. Cette expérience n'est réalisable que sur ce VLAN là, car c'est le seul situé derrière un switch non administrable.

    Merci par avance pour votre réponse.



  • Les nouvelles du jour : les VLANs tournent niquel, me reste seul ce souci d'accès à l'interface web.

    A noter que si je tente une connexion SSH, j'ai exactement le même souci (la connexion s'établit, mais rien n'apparait, on dirait que PfSense ne me répond pas une fois la session TCP établie).

    Dans les logs de PfSense (Diagnostics -> Show states), je me retrouve avec des lignes de ce type là :
    tcp  192.168.0.1:443 <- 192.168.0.98:1421  ESTABLISHED:ESTABLISHED

    Ce qui me semble parfaitement normal. Après quelques secondes, on passe à du FIN_WAIT_2:ESTABLISHED, puis du FIN_WAIT_2:FIN_WAIT_2.

    Je ne comprends vraiment pas ce qu'il se passe. Je ne peux pas accéder à mon interface web depuis aucun des VLANs, ce qui est extrêmement handicapant. J'ai beau diagnostiquer la chose, je sèche pas mal…j'ai l'impression que PfSense renvoie des trames tagguées sur le VLAN par défaut, ce qui cause un souci de transfert...(cf mon post précédent). De nombreuses choses sont également à envisager, routes statiques ? NAT ? Je ne vois pas ce que ça viendrait faire là-dedans mais à défaut d'autre chose..

    Si quelqu'un a une idée. Merci par avance. J'éditerai le post au fur et à mesure que je trouverai des informations supplémentaires.

    Voici un exemple de capture de trame lors d'une tentative de connexion SSL depuis 192.168.0.98 sur l'interface web de PfSense.

    14:57:18.384555 00:04:e2:61:04:a5 > 00:21:70:07:9c:92, ethertype IPv4 (0x0800), length 948: (tos 0x0, ttl 64, id 51805, offset 0, flags [DF], proto TCP (6), length 934) 192.168.0.1.443 > 192.168.0.98.1491: FP, cksum 0x81bf (correct), 749492561:749493455(894) ack 1797609261 win 65520
    14:57:20.910390 00:21:70:07:9c:92 > 00:04:e2:61:04:a5, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 55105, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.98.1491 > 192.168.0.1.443: F, cksum 0xde41 (correct), 1:1(0) ack 0 win 65535
    14:57:21.728977 00:21:70:07:9c:92 > 00:04:e2:61:04:a5, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 128, id 55112, offset 0, flags [DF], proto TCP (6), length 48) 192.168.0.98.1519 > 192.168.0.1.443: S, cksum 0x19da (correct), 1073717224:1073717224(0) win 65535 <mss 1460,nop,nop,sackok="">
    14:57:21.729069 00:04:e2:61:04:a5 > 00:21:70:07:9c:92, ethertype IPv4 (0x0800), length 62: (tos 0x0, ttl 64, id 30838, offset 0, flags [DF], proto TCP (6), length 48) 192.168.0.1.443 > 192.168.0.98.1519: S, cksum 0x6e87 (correct), 1713391449:1713391449(0) ack 1073717225 win 65228 <mss 1456,sackok,eol="">
    14:57:21.729475 00:21:70:07:9c:92 > 00:04:e2:61:04:a5, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 55113, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.98.1519 > 192.168.0.1.443: ., cksum 0x9913 (correct), 1:1(0) ack 1 win 65535
    14:57:21.729608 00:21:70:07:9c:92 > 00:04:e2:61:04:a5, ethertype IPv4 (0x0800), length 135: (tos 0x0, ttl 128, id 55114, offset 0, flags [DF], proto TCP (6), length 121) 192.168.0.98.1519 > 192.168.0.1.443: P, cksum 0xb281 (correct), 1:82(81) ack 1 win 65535
    14:57:21.729630 00:04:e2:61:04:a5 > 00:21:70:07:9c:92, ethertype IPv4 (0x0800), length 54: (tos 0x0, ttl 64, id 39986, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.1.443 > 192.168.0.98.1519: ., cksum 0x9922 (correct), 1:1(0) ack 82 win 65439
    14:57:21.729868 00:04:e2:61:04:a5 > 00:21:70:07:9c:92, ethertype IPv4 (0x0800), length 948: (tos 0x0, ttl 64, id 63750, offset 0, flags [DF], proto TCP (6), length 934) 192.168.0.1.443 > 192.168.0.98.1519: P, cksum 0xa96b (correct), 1:895(894) ack 82 win 65520
    14:57:23.241938 00:21:70:07:9c:92 > 00:04:e2:61:04:a5, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 55117, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.98.1491 > 192.168.0.1.443: F, cksum 0xde41 (correct), 1:1(0) ack 0 win 65535
    14:57:24.729526 00:04:e2:61:04:a5 > 00:21:70:07:9c:92, ethertype IPv4 (0x0800), length 948: (tos 0x0, ttl 64, id 37198, offset 0, flags [DF], proto TCP (6), length 934) 192.168.0.1.443 > 192.168.0.98.1519: P, cksum 0xa96b (correct), 1:895(894) ack 82 win 65520
    14:57:28.013092 00:21:70:07:9c:92 > 00:04:e2:61:04:a5, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 128, id 55118, offset 0, flags [DF], proto TCP (6), length 40) 192.168.0.98.1491 > 192.168.0.1.443: F, cksum 0xde41 (correct), 1:1(0) ack 0 win 65535
    14:57:30.929487 00:04:e2:61:04:a5 > 00:21:70:07:9c:92, ethertype IPv4 (0x0800), length 948: (tos 0x0, ttl 64, id 41804, offset 0, flags [DF], proto TCP (6), length 934) 192.168.0.1.443 > 192.168.0.98.1519: P, cksum 0xa96b (correct), 1:895(894) ack 82 win 65520</mss></mss>
    

    Quelqu'un ayant eu un souci me "ressemblant" : http://forum.pfsense.org/index.php/topic,12330.0.html

    Autre post où on "suggère" d'assigner un VLAN à l'interface physique LAN (ce que je n'ai pas fait…c'est peut-être ça ?) :
    http://forum.pfsense.org/index.php/topic,8778.0.html

    Edit : Il y a du neuf : après divers diagnostics, nous avons pu déterminer que seules les connexions TCP d'un VLAN quelconque vers le PfSense ne passaient pas. Du PfSense vers un ordinateur d'un VLAN quelconque, aucun problème. Ca ressemblerait à un problème de Firewall ou de tag cette histoire …



  • (Quatre posts d'affilée, on va m'en vouloir…désolée).

    Bonsoir à tous. Je quitte le boulot (^^) après divers diagnostics.

    Ayant découvert que le TCP ne passait pas dans le sens VLAN -> PfSense (uniquement si destiné à PfSense !!), j'ai fait énormément d'analyses Wireshark (via un port monitor). J'en arrive à une conclusion très simple : lorsque je demande une connexion SSL à l'interface Web de PfSense ("Client Hello" dans le protocole SSL), PfSense émet en retour une trame ("Server Hello") sur le VLAN par défaut.

    Forcément, je n'utilise pas le VLAN par défaut. La trame est donc droppée purement et simplement par le switch, et si j'ose dire, on en arrive à un beau dialogue de sourds. Ceci est valable pour toute connexion TCP.

    Maintenant la question qui fâche : ce comportement est-il normal ? Est-ce un bug ? Ou bien un simple paramètre qui m'aurait échappé ? Je précise que si on se connecte sur un port du switch affilié au VLAN par défaut, tout fonctionne.

    Je vous donne, ci-dessous, une map logique du réseau faite en cinq minutes et décrivant le souci...merci à tous pour votre précieuse aide.



  • normal si la carte logique LAN de pfsense est associée à une carte physique (dans le menu assign) et non à un VLAN (onglet vlan du menu assign).



  • En d'autres termes, si l'interface web me renvoie des trames TCP non taguées, c'est à cause de ça ? J'avais déjà essayé d'associer la carte logique à un VLAN particulier. Je crois que je vais le refaire ^^. La question est, à quel VLAN ? Soit je supprime totalement la notion de lien "physique" entre mon PfSense et mon switch, soit je taggue ma carte logique sur mon VLAN par défaut…je vais faire ça et je vois si ça change quelque chose.



  • 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 30

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

    @ccnet:

    … 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_pfSense

    Si 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

    @ccnet:

    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

    @ccnet:

    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 supprimer

    Il 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

    @ccnet:

    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

    @ccnet:

    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

    @ccnet:

    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.


Locked