Bonjour   ,
 
Mes VLANs ne communiquent pas entre eux avec OPNsense (Exemple : Un PC du Vlan20 (192.168.2.50, passerelle : 192.168.2.1) ne ping pas un serveur du Vlan10 (192.168.1.2)).
 
Avez-vous une idée ?
 
Une "connexion" a l'air pourtant bonne d'après le dernier affichage, je vous laisse regarder.
 

 



 
Merci beaucoup par avance de votre réponse qui m'aidera beaucoup !    
 
Voici le sujet initial : https://forum.opnsense.org/index.php?topic=9007.0
 
-
Même en essayant de faire une règle "any any" entre les VLANs, rien ne se fait.  
 
Un problème de routage ? Mais OPNsense est normalement fait pour le faire tout seul donc je suis vraiment perdu, je n'arrive pas à trouver la cause

Première chose, vérifier que tes passerelles sur tes 2 PCs soit correctes.
 
Sinon une case à cocher importante pour la communication entre les réseau (je n'ai plus le nom, elle se trouve dans la partie Pare-feu -> paramètre avancé) bloque les communication interne. Il faut penser à la décocher.

Encore une chose, dans tes règles, une seule règle avec la bonne source suffit. Exemple : dans l'onglet VLAN10, une règle de cette source vers ta destination; et pareil de l'autre coté

 
Bah mon PC-test du VLAN20 a bien la passerelle qui est l'interface LAN2 (VLAN20) sur le FW.  
EDIT: Le PC du VLAN20 ping bien sa passerelle et ping bien la passerelle du VLAN10, mais ne sort donc pas sur le réseau du VLAN 10.
Et le serveur que je souhaite contacter est le DHCP qui se trouve sur le LAN (VLAN10) et qui n'a pas la bonne passerelle (il a pour le moment le FW de production).
 
Mais du VLAN10, de l'interface du FW (192.168.1.69) je peux ping le DHCP ; 192.168.1.2.
Du VLAN20, de l'interface du FW (192.168.2.1), je ne peux ping le DHCP car il cherche à passer que par 192.168.2.1 et il ne va pas chercher la passerelle du VLAN10....
 
Oh, une case à cocher ? Effectivement, je n'ai pas fait ce type de réglage, je vais chercher ça de suite! Merci beaucoup pour l'information ! En espérant que ce soit ça car je désespère doucement  
 
-
-

 
Règles VLAN 10
Source : VLAN 10  
Destinataire : VLAN 20
 
Règles VLAN 20
Source : VLAN 20
Destinataire : VLAN 10
 
Comme ceci ?
Il ne faut pas autoriser en source le VLAN qu'on souhaite faire communiquer si le traffic vient de celui-ci ?
(C'est ce pourquoi j'ai fait les deux règles au départ)
 
-
-
Une option te parle ?
 
http://zupimages.net/viewer.php?id=18/29/jw36.png
 
http://zupimages.net/viewer.php?id=18/29/60dp.png
 
http://zupimages.net/viewer.php?id=18/29/qfdk.png
 
Sachant que j'aimerais juste faire communiquer ces deux VLANs entre eux qui sont sur la même interfaces/sous-interfaces, mais les autres VLANs seront indépendant, malgrès qu'ils soient sur la même interface/sous-interface. Donc ensuite, ce sera les règles du Firewall qui délimiteront tout ça  

Il s'agit de la case à cocher sur le troisième screen, "contourner les règle pare-feu sur la même interface". Il faut la cocher (j'avais inverser du coup lol) si tu veux communiquer sur la même interface.
Cependant, dans ton cas, tu travaille normalement sur 2 interfaces différentes, donc elle ne devrait pas agir.
 
Pour tes règles parefeus, oui c'est bien comme ça. En réalité tu peux même mettre en source "all" (ce qui permet d'autoriser également les sous-réseau de cette interface.
Il gère les règle par "Interface", ce qui fait que un "all" dans ta source n'autorisera en réaliter que le traffice venant de cette interface. D'où le fait qu'une règle autoriser la source VLAN20 dans ton interface VLAN10 n'est pas utile

Encore une chose, si il s'agit d'une machine virtuelle. Il faut absolument cocher une case à cocher dans la partie "Interface->Setting" : Disable Hardware cheksum offload

D'accord...
 
Du coup, vu que le VLAN10 et le VLAN20 sont chacune une interface, bien qu'elles soient sur la même sortie (bce1), ça ne devrait rien faire. J'ai quand même essayé, sans résultat
 
OPNsense est installé sur un serveur HP, donc en physique.
 
Les règles sont en any any actuellement, donc tout devrait normalement passer...
Le port du switch où est relié bce1 du Firewall est en mode tagued (trunk) pour justement faire passer les VLANs voulu, un soucis à ce niveau là sinon ?
 
-
-
Je viens de faire quelques tests d'ICMP :
 
Du VLAN 10:
Je peux ping l'interface du VLAN 10 des switchs (192.168.1.109/192.168.1.110)
Je peux ping l'interface du VLAN 20 des switchs (192.168.2.109/192.168.2.110)
Je peux ping des machines du VLAN10.
Je ne peux pas ping des machines du VLAN20.
Je peux ping les interfaces du Firewall de chaque VLAN.
 
Du VLAN 20 :
Je peux ping l'interface du VLAN 10 des switchs (192.168.1.109/192.168.1.110)
Je peux ping l'interface du VLAN 20 des switchs (192.168.2.109/192.168.2.110)
Je peux ping des machines du VLAN20.
Je ne peux pas ping des machines du VLAN10.
Je peux ping les interfaces du Firewall de chaque VLAN.
 
Mais du coup, pourquoi je ne peux pas ping certains autres "postes/serveurs" ?
 
Les équipements sont sur l'ancien FW, ils ont donc 192.168.1.1 en passerelle avec le WAN etc...
Mais vu que le "nouveau" FW est en 192.168.1.69, même sans le WAN, il devrait pouvoir ping le réseau tout de même, non ?
 
En espérant me faire comprendre, mais je n'arrive pas à savoir d'où viendrait le réglage manquant
 
-
-
 

 

 
Je vous met ce qui peut vous être utile, je cherche un peu de partout...

Si tes règles sont en any partout, faut vraiment vérifier tes passerelles par défaut sur tes postes des 2 cotés.
 
Je vois pas trop ce qui peut te gâcher.
 
PS: Quand tu regarde tes logs bloquer, tu peux cliquer sur un bouton qui permet de créer une règle auto pour passer, tu peux derrière comparer cette règle pour voir.

 
Justement, les logs montrent que la requête ICMP passerait alors qu'elle ne passe pas, j'ai du mal à voir ce qui cloche...
( => http://image.noelshack.com/fichier [...] nse-fr.png )
 
Pour les passerelles, le poste sur le VLAN20 a bien 192.168.2.1 (l'interface du FW).
Après, le poste du VLAN10 (192.168.1.2 par exemple) a la passerelle du FW en prod, donc n'a pas connaissance de ce nouveau FW ni de ces routes mais la requête ICMP devrait tout de même passer non ?
 
Après, via l'outil de diagnostic, je peux utiliser l'IP du FW 192.168.1.69 qui est le VLAN10 pour tenter de ping le PC du VLAN20 qui lui, est en fixe (192.168.2.50/24 ou 192.168.2.51/24 selon ce que j'avais mis, je ne sais plus) avec la bonne passerelle (192.168.2.1) et là, cela ne passe pas quand même.
 
-
-
Je viens de faire un test sur un poste du VLAN10 en paramétrant comme passerelle celle du VLAN10 du nouveau Firewall (192.168.1.69).
(Il avait la passerelle du Firewall de Production (192.168.1.1))
 
Du coup, suite à ça, mon PC-test du VLAN20 (192.168.2.51/24) peut ping cet autre PC (192.168.1.32/24) !
Pas le DHCP (192.168.1.2) car il a actuellement la passerelle de l'ancien Firewall).
 
C'était donc bien une histoire de passerelle, mais je ne pensais pas qu'il aurait fallut changer la passerelle de production pour effectuer des tests de ping vu que c'était le même réseau
 
Du coup, je pense que mon problème est résolu ^^
Il faudra que je coupe le Firewall de production, que je branche mon WAN sur le nouveau et que je change son IP avec celle de l'ancien Firewall.
 
En tout cas, Merci de ton aide Spardhas !

J'ai lu un peu en diagonale, mais clairement tu devrais revoir/apprendre les bases (que ce soit en réseau ou en Firewall) pour comprendre ce que tu fais avec ton équipement (cf le coup de la règle avec en source le vlan10 sur les règles du vlan20..). Ca ne pourra t'être que bénéfique
 
Dans l'état tu aurais un simple routeur ou ta box opérateur directement connecté cela ne changerai rien...
 
Bon courage =)

 
Oui, ça m'arrive d'être ailleurs le temps de comprendre puis après une période d'inactivité, il faut toujours se remettre dedans ^^.
 
Concernant le Firewall, c'est mes premiers pas là dessus. Lors de mon BTS, je n'y avais pas touché.
Et effectivement, je pensais qu'il aurait fallu cibler les réseaux source qui se connectent à l'interface en question, mais en faite non, si j'ai bien compris, on autorise uniquement ce qu'on souhaite faire à partir de l'interface en question.
 
Merci

Afin de comprendre, il me suffit juste d'autoriser (ou de bloquer) ce que je souhaite à partir de l'interface en question.
 
J'ai donc désactivé les règles qui pointent en source une autre interface.
Je prend l'exemple de la DMZ et d'un LAN.
Je souhaite que la DMZ n'y accède pas, mais que le LAN accède à la DMZ.
 
De ce fait, est-ce que ces règles sont correctes ?
 
(Interface des Règles VLAN10)

 

 
PS: Une règle qui bloque un traffic suivi d'une règle qui autorise le traffic de partout (comme la capture ci-dessus) est "bon", ou je dois d'abord stipuler la règle qui autorise le traffic de partout suivi de celles qui bloquent certains traffic ?
 
Merci encore et désolé pour mes bases qui ne sont pas top en ce moment.

Alors, dans ton premier screen, ta troisième règle ne sert à rien car la deuxième indique déjà un accès à tout depuis ton VLAN 10. De plus, comme je t'avais dit, si un jour tu compte avoir des sous-réseaux, il vaut peut-être mieux mettre "ANY" en source. Cette règle étant utiliser uniquement avec en source "tout ce qui vient de l'interface VLAN10", c'est inutile de spécifier "VLAN10 net" en source.
 
Deuxième point :
J'imagine que ton VLAN50 est ta DMZ, donc moi personnellement j'ai plus tendance à créer un alias avec les réseaux RFC, soit :
10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
Ensuite tu supprimes toutes tes règles de DMZ et tu ne créer qu'une règles indiquant en "Destination" vers ton alias RFC1918.
Avec ça, ta DMZ pourra aller sur internet seulement et toutes tes autres interfaces bloqueront implicitement le traffic venant de ta DMZ.

D'accord.
Pour le any, on ne sait pas encore si nous autorisons le VLAN10 à communiquer avec tout le monde ou seulement avec le VLAN20, du coup, pour le moment on a laissé les deux, mais ce que tu dis est vrai.
 
Ok pour ta précision pour la DMZ.
 
Une règle qui bloque un traffic suivi d'une règle qui autorise le traffic de partout (comme la capture ci-dessus) est "bon", ou je dois d'abord stipuler la règle qui autorise le traffic de partout suivi de celles qui bloquent certains traffic ?

Alors oui, dans le principe c'est bon, les règles vont du haut vers le bas, donc oui ça bloquera, mais c'est pas correct dans le sens ou si par exemple, un sous-réseau est créer en dessous de VLAN10, la DMZ y aura accès car tu bloque le "VLAN 10 net" et non un possible sous-réseau.
 
D'où le principe de créer l'alias RFC1918 et de n'autoriser que le traffic vers ces destinations. Tu seras au moins certain que ta DMZ ne pourra aller sur aucune autre interface (réseau et sous réseau compris)

Évidemment il s'agira de supprimer tes règles de blocage qui ne serviront plus à rien.

un firewall on bloque par défaut et on autorise au besoin, pas l'inverse

 
Exactement ce que j'essaie de lui faire comprendre, inutile de créer des règles de blocage car c'est déjà par défaut. Il faut juste autoriser les bonnes choses, d'où l'alias RFC1918.

je vois pas non plus l'intérêt de ton alias

Dans OPNSense tu as 2 manières d'autoriser le flux de ta DMZ vers Internet uniquement :
 
*En créant l'alias comme je l'indique et créer une règle d'autorisation en destination vers cette alias.
*En créant une règle inverse, c'est à dire autoriser les flux vers tous, sauf vers un réseau en question. Le problème de cette règle est qu'elle est pas super gérable avec plusieurs interfaces.
 
L'utilisation de l'alias RFC1918 est la manière la plus aisé de créer une DMZ dans OPNsense, une seule règle suffit à bien sécuriser cette DMZ.
Implicitement, toutes les autres interfaces bloqueront par défaut les flux de la DMZ, du coup, avec une seule règle, toutes mes interfaces présentes et futurs sont automatiquement protégés

Non, aucun intérêt ton alias. Tu déclares ce que tu autorises, point. Pas besoin d'avoir tout le RFC1918. Et internet c'est pas 0.0.0.0/0 minus RFC1918 hein

Alors on va se calmer, je t'ai pas agressé...
 
*J'ai effectivement inversé un truc, tu dois créer une règle inverse de tout, sauf RFC1918.*
 
Apparemment tu dois revoir tes bases parce que si tu met 0.0.0.0/0, tu autorise en "ANY", c'est à dire sur l'ensemble des réseaux, y compris tes réseaux internes.
En gros tu ouvres tout tes réseaux à ta DMZ...
 
OPNsense n'a pas de destination par interface, donc il travaille avec l'ensemble des interfaces, donc 0.0.0.0/0 est bien dans un réseau LAN comme 192.168.1.0/24.
 
Créer l'Alias te permet d'être certain que ta DMZ ne travaille qu'avec des adresses publics.

je t'agresse pas…
 
je voulais dire c'est PAS 0.0.0.0/0 minus RFC1918.
J'ai jamais dit de mettre 0.0.0.0/0 hein.
 
127.0.0.0/8
169.254.0.0/16
toutes les ip multicast, reserved and co t'en fait quoi avec ton alias ?
Bref ton alias ne sert à rien, tu déclares ce que tu veux ouvrir c'est tout

Tu peux rajouter les adresse réservé dans ton alias, aucun problème.
 
Le soucis est qu'il faut bien une destination dans ta règle, tu mettrais quoi toi pour pas qu'elle impacte tes réseaux LAN ?
 
Si tu met 0.0.0.0/0 tu ouvre pour tous les réseaux, y compris ton LAN, donc déjà celle-ci est exclu.

le but est de faire communiquer vlan10 avec 20 donc suffit d'autoriser ce flux.

Non mais ça c'est réglé déjà, il avait une deuxième question sur comment gérer sa DMZ, et les règles qu'ils nous à montrer ne sont pas super top. Le but étant d'optimiser ça.

faudrait savoir les flux qu'il veut autoriser surtout là ya rien de défini proprement

Il a tout bien expliqué :
Tout autoriser depuis VLAN10 vers VLAN20
Tout autoriser depuis VLAN20 vers VLAN10
Tout autoriser depuis VLAN10 et 20 vers DMZ (VLAN50)
DMZ uniquement vers Internet
 
Soit le plus simple comme je disais :
Règle dans Interface VLAN10 = Any vers VLAN20
Règle dans Interface VLAN10 = Any vers VLAN50
Règle dans Interface VLAN20 = Any vers VLAN10
Règle dans Interface VLAN20 = Any vers VLAN50
Règle dans Interface VLAN50 = Any vers Inverse RFC1918
 
Tu peux rajouter dans ton Alias RFC1918 les adresse réservé, aucun problèmes, c'est même d'autant plus correct.
Avec ça, il a toute les règles pour bien commencer

D'accord, merci pour tous vos messages, il faudra que je regarde tout ça du coup.
 
En dehors de ce que j'ai listé, j'ai des règles NAT qui ciblent certains serveurs en DMZ, et d'autres qui ciblent d'autres serveurs.
Et vu que je n'ai aucune connaissance pour le moment, j'ai bloqué les réseaux auquel je ne souhaite pas que la DMZ accède, puis j'ai autoriser de DMZ à "any".
 
Sinon, autre chose, pour le VLAN10 par exemple, actuellement c'est le VLAN10 en source (donc pareil que "any" en vous lisant) et en destinataire "any" pour que le VLAN10 puissent communiquer avec tous les autres réseaux.
 
Si je souhaite autoriser une interface à communiquer uniquement avec Internet, qu'est ce que je dois cibler en destinataire ? (Comme pour la DMZ, avec ton exemple d'alias ?)
(J'ai tenté de cibler "WAN net" mais Internet n'était pas là ^^ (C'est pour l'interface WiFi par exemple malgrès que l'interface WiFi ait l'accès à tout actuellement...)
 
Et encore autre chose, il y a une règle de "any" à "VLAN"X" Adresse", à quoi cette règle sert-elle ? Si je comprends bien, cela cible explicitement l'adresse de l'interface du VLAN, soit, la passerelle du VLAN en question pour accéder à la configuration du Firewall ? Ou je me trompe ?
 
-
Désolé pour certaines questions, je reprend ce réseau avec des notions qui sont en cours de construction pour certaines choses.

 
Comme indiqué plus haut, tu n'as normalement pas besoin de bloquer, par défaut c'est bloqué. Je reprends encore ce qu'on dit depuis le début, tu ne déclare que ce que tu veux autoriser. C'est à dire dans ton interface DMZ, une seule règle de "ANY" vers Inverse de RFC1918. Cette règle autorisera ta DMZ à aller vers Internet et les autres chemin sont bloqué par défaut.
 
Tu peux créer une règle supplémentaire pour le DNS, selon comment tu veux que soit gérer les DNS de tes appareils dans ta DMZ. Je m'explique, un serveur dans ta DMZ, si il a en DNS 8.8.8.8, aucun problème avec la règle unique cité plus haut. Par contre, si tu souhaite mettre en DNS, ton parefeu, il faudra autoriser depuis l'interface DMZ le protocole DNS vers destination "Parefeu Adresse".
J'espère que tu as compris =)
 

 
Oui tu peux remplacer le VLAN10 par any en source, car c'est tout le flux qui vient de ton interface VLAN10, cela prendra en compte tes (peut-être) futurs sous-réseaux. TOUJOURS penser au futurs possibilités et prendre de l'avance sur la facilité de gestion derrière.
 

 
Tu fais la même règle que je t'ai expliqué pour ta DMZ, une destination Inverse vers RFC1918.
Destination "WAN Net" ne fonctionnera pas car il prend en compte l'adresse WAN que tu as, exemple : 194.2.50.50/30, ton "WAN Net" correspond à 194.2.50.49 à 194.2.50.50. Tu comprends donc que ce n'est pas Internet entièrement mais seulement que 2 IP possibles.
 

Cette règle est une règle Anti-Lockout qui se crée toute seule (C'est une case à cocher dans les paramètre système qui gère ça). Elle te permet de te connecter depuis tes différentes Interfaces à la gestion de ton Pare-Feu.
Dans le principe on désactive cette case à cocher et on crée manuellement ces règles, car une DMZ n'est pas censé avoir accès à ton Parefeu.

D'accord, merci pour toutes tes réponses