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

Julia

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 =/.

Julia

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]".

ccnet

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 ?

Julia

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.

ccnet

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

Julia

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.

Julia

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.

Julia

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

Juve

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.

Julia

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 !

Juve

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.

Julia

Salut,

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

Julia

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.

Julia

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 …

Julia

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

Juve

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

Julia

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.

Julia

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.

Julia

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

Julia

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