Filtrage en mode transparent pour une DMZ

forus

Alors je vous expose mon problème.

La machine pfsense a 2 cartes réseaux. l'une connecté a un switch sur lequel est brancher 2 routeurs différent et la deuxieme pate est connectée sur le switch de DMZ.
Cette dmz est composé de deux plage d'adresse ip publique pour prendre des exemple on va dire 50.10.20.XX et 60.10.20.XX

un petit schéma pour comprendre
__ __________ _
| |<-routeur1 :50.10.20.177 | | | |
| | |S| | | |S |–--------| | serveur1 : 50.10.20.179
_|---------------|W| BGE0 | | RL0 |W | ||
_ |I |-------------- | pfsense |-----------|I |
/ |--------------- |T| (wan)| | (lan) |T | __
| | |C| | | |C | | |
|| |H| |________| |H dmz|----| |
^ ||
|| routeur2 : 60.10.20.94 serveur2 : 60.10.20.91

niveau de la configuration, j'ai suivi le tutoriel de conf de pfsense en mode transparent.
BGE0 et RL0 on des adresse ip 50.10.20.181 et 50.10.20.178 mais apparament c'est sans incidence car il se base sur les adresses mac
tout m'avai l'air de marcher sauf que :

machine source -> machine destination
ping routeur1 -> serveur1 ok
ping serveur1 -> routeur1 ok

ping routeur2 -> serveur2 ok
ping serveur2 -> routeur2 nok ! !
et encore plus bizarre, quand je lance le ping depuis le routeur2 et que en même temps je lance le "ping serveur2 -> routeur2" celui ci répond!!!
si je stop le ping depuis routeur2 le serveur2 cesse de recevoir des réponses.... !?!?

autre information, j'ai pour valider en un premier temps que le "mode transparent" fonctionne bien comme un fils, mis 2 règles de firewall disant "tout se qui vien de wan vers lan passe" et "tout se qui viens de lan vers wan passe"

qui pourrai m'éclairer sur ce problème?
PI : les routeur et serveurs sont pour la phase de configuration sont en faite des pc configuré a l'image des futurs éléments, mais normalement aucun impact.
autre information, cette architecture et validée, puisque déjà en oeuvre avec un autre os que freeBSD.

ccnet

LAN (RLO) est bien "Bridge with WAN" dans sa définition ?
Comment serveur2 sait il atteindre le routeur 2 qui est dans la même plage d'adresse que lui alors que wan est en 50.x.y.z ?

forus

Bonjour,

alors, maintenant que je suis a coté du labo de test, je viens de vérifier, et, comme indiqués dans le tutoriel, l'interface lan est bien configurée en "bridge with WAN"

la "magie" de se fonctionnement est basée sur le mode transparent, le firewall doit se comporter comme un fil. pour cela j'ai bien vérifier auparavant que les cartes réseaux était compatibles avec le mode "Promiscuous" qui fonctionne si j'ai bien compris via requete ARP et adresses mac.

Juve

Je valide le fonctionnement du pont. Lorsque pfsense est en mode pont c'est effectivement comme si on traversait un simple fil.
PAr défaut le pont n'est pas filtrant. si l'on veut filtrer ce qui passe à travers il faut aller dans le menu "Advanced" et activer l'option "Enable filtering bridge".
J'ai un certains nombre de ponts filtrants en production qui fonctionnent sans aucun soucis.

Pour votre problème, vérifiez la configuration IP de routeur2 et plus particulièrement son masque réseau.

forus

donc j'ai vérifier la config de mes 4 postes de test, et elle est a l'identique de celle des machines en place actuellement.

J'ai donc continué de creusé se problème, et je me suis dit, essayons le monde à l'envers.
A partir de la configuration de pfsense actuelle, j'ai tenté de changer juste 2 paramètres :

BGE0 est désormais l'interface assigné comme "lan" et RL0 est maintenant le "wan".
Le cablage reste identique, ce qui donne :

__ __________ _
| |<-routeur1 :50.10.20.177 | | | |
| | |S| | | |S |–--------| | serveur1 : 50.10.20.179
_|---------------|W| BGE0 | | RL0 |W | ||
_ |I |-------------- | pfsense |-----------|I |
/ |--------------- |T| (lan) | | (wan) |T | __
| | |C| | | |C | | |
|| |H| |________| |H dmz|----| |
^ ||
|| routeur2 : 60.10.20.94 serveur2 : 60.10.20.91

maintenant le résultat de mes test donne exactement le meme problème, mais dans le sens inverse....
ping routeur2 -> serveur2 nok
ping serveur2 -> routeur2 ok

avec la même "solution temporaire" en lancant le ping ok...

sa ressemble a un problème de routage, mais alors pourquoi le problème s'inverse en changeant l'assignation des interfaces?

ccnet

@ccnet:

Comment serveur2 sait il atteindre le routeur 2 qui est dans la même plage d'adresse que lui alors que wan est en 50.x.y.z ?

Je vous repose la question, car je crois aussi que c'est un problème de routage plutôt que strictement Pfsense. L'inversion de la configuration et ses conséquences me le laisse penser.

forus

Tout d'abord, merci pour votre aide, et je sens que je vais bien progresser si je résoud se problème.

Pour vous répondre, je pense que la machine qui émet, ne se "pose pas de question" car devant atteindre une machine sur le même réseau.
les paquets ICMP arrivent donc sur le cable, je les voit passer sur les captures wireshark.
Ils arrivent donc sur la carte réseau de mon interface wan.
c'est à cet endroit que je sèche.

En arrivant sur cette interface, ma machine pfsense sait dire "prend le bridge, passe par rl0, et tu sera sur le bon segment"
pour la réponse, cette même machine doit conserver une association adresse mac/adresse IP coté "wan" un court laps de temps, permettant à la réponse de repasser par le même pont.

d'un autre coté, j'ai remarqué sur les captures whireshark, que du coté lan, pfsense envoye des requete arp tel que :
source : adresse mac / destination : broadcast / protocol ARP / Info : Who has $adresse_ip_de_sa_gateway

Aussi on peut visualiser ces paquets :
coté WAN :
"5","1.291339","00:0f:1f:d6:e1:a3","Spanning-tree-(for-bridges)_00","STP","Conf. Root = 32768/00:0f:1f:d6:e1:a3 Cost = 0 Port = 0x8001"

coté LAN :
"8","4.054149","00:30:84:3e:c3:26","Spanning-tree-(for-bridges)_00","STP","Conf. Root = 32768/00:0f:1f:d6:e1:a3 Cost = 0 Port = 0x8002"

Résultat du ifconfig sur la machine pfsense :

# ifconfig
bge0: flags=28943 <up,broadcast,running,promisc,simplex,multicast,ppromisc>mtu 1500
        options=18 <vlan_mtu,vlan_hwtagging>inet6 aaaa::18b:1fff:fed6:e1a3%bge0 prefixlen 64 scopeid 0x1
        inet 50.10.20.181 netmask 0xfffffff8 broadcast 50.10.20.183
        ether 00:0f:1f:d6:e1:a3
        media: Ethernet autoselect (none)
        status: no carrier
rl0: flags=28943 <up,broadcast,running,promisc,simplex,multicast,ppromisc>mtu 1500
        options=8 <vlan_mtu>inet6 aaaa::230:54eb:fa3e:c326%rl0 prefixlen 64 scopeid 0x2
        inet 50.10.20.178 netmask 0xfffffff8 broadcast 50.10.20.183
        ether 00:30:84:3e:c3:26
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
pflog0: flags=100 <promisc>mtu 33208
enc0: flags=0<> mtu 1536
lo0: flags=8049 <up,loopback,running,multicast>mtu 16384
        inet6 ::1 prefixlen 128
        inet6 aaaa::1%lo0 prefixlen 64 scopeid 0x5
        inet 127.0.0.1 netmask 0xff000000
pfsync0: flags=41 <up,running>mtu 2020
        pfsync: syncdev: lo0 syncpeer: 224.0.0.240 maxupd: 128
bridge0: flags=28943 <up,broadcast,running,promisc,simplex,multicast,ppromisc>mtu 1500
        ether 62:28:48:e0:4a:28
        priority 32768 hellotime 2 fwddelay 15 maxage 20
        member: rl0 flags=7 <learning,discover,stp>port 2 priority 128 path cost 55 forwarding
        member: bge0 flags=7 <learning,discover,stp>port 1 priority 128 path cost 55 disabled</learning,discover,stp></learning,discover,stp></up,broadcast,running,promisc,simplex,multicast,ppromisc></up,running></up,loopback,running,multicast></promisc></full-duplex></vlan_mtu></up,broadcast,running,promisc,simplex,multicast,ppromisc></vlan_mtu,vlan_hwtagging></up,broadcast,running,promisc,simplex,multicast,ppromisc>

En comparaison avec le système actuellement en place :

br0       Link encap:Ethernet  HWaddr 00:10:1F:0A:21:AE
          inet addr:50.10.20.181  Bcast:50.10.20.183  Mask:255.255.255.248
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:948091 errors:0 dropped:0 overruns:0 frame:0
          TX packets:68800 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:59465889 (56.7 MiB)  TX bytes:7978385 (7.6 MiB)

eth0      Link encap:Ethernet  HWaddr 00:10:1F:0A:2D:BA
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1012971603 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1780892410 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:3504756610 (3.2 GiB)  TX bytes:425173179 (405.4 MiB)
          Interrupt:12

eth1      Link encap:Ethernet  HWaddr 00:10:1F:0A:21:AE
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1776905582 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1016539812 errors:0 dropped:0 overruns:2 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:299333187 (285.4 MiB)  TX bytes:3698492994 (3.4 GiB)
          Interrupt:5 Base address:0x2000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

bon j'avoue, je commence a avoir des migrainnes…...

ccnet

Essayons d'y voir clair. La configuration actuelle est elle bien celle ci (la seconde) ?

__ __________ _
| |<-routeur1 :50.10.20.177 | | | |
| | |S| | | |S |–--------| | serveur1 : 50.10.20.179
_|---------------|W| BGE0 | | RL0 |W | ||
_ |I |-------------- | pfsense |-----------|I |
/ |--------------- |T| (lan) | | (wan) |T | __
| | |C| | | |C | | |
|| |H| |________| |H dmz|----| |
^ ||
|| routeur2 : 60.10.20.94 serveur2 : 60.10.20.91

Qui et en bridge avec qui ? l'ip sur l'interface non bridgée est bien 50.x.y.z ?
Si RL0 est en bridge avec Lan, je serai curieux de voir le résultat d'un traceroute, depuis serveur 2, vers 60.10.20.94.
Je comprend bien que si Wan est en pont (demi pont en fait) avec Lan, la requête arp parvient jusqu'à Lan (BGE0). Mais cette dernière interface n'est pas un demi pont me semble t il, et n'est pas dans le même sous réseau que Router 2. Il y a là un point dont je ne suis pas très sûr et que j'essaye de comprendre. Intéressant.

forus

Alors non, la deuxième solution était plus la pour vérifier que le pb vienne de la machine pfsense plutot que de la conf de mes "routeur"/"serveurs".

je remet le bon schéma :
__ __________ _
| |<-routeur1 :50.10.20.177 | | | |
| | |S| | | |S |–--------| | serveur1 : 50.10.20.179
_|---------------|W| BGE0 | | RL0 |W | ||
_ |I |-------------- | pfsense |-----------|I |
/ |--------------- |T| (wan)| | (lan) |T | __
| | |C| | | |C | | |
|| |H| |________| |H dmz|----| |
^ ||
|| routeur2 : 60.10.20.94 serveur2 : 60.10.20.91

alors j'ai suivi le tutoriel suivant : http://pfsense.trendchiller.com/transparent_firewall.pdf
extrait :
After saving is complete you go to the Interfaces tab and chose the LAN-Interface. Bridge the LAN-Interface with the WAN-Interface and disable the FTP Helper. The IP you enter here will be ignored when you activate the bridge mode. You better should not use the same IP on both interfaces, because it can cause BSD-internal problems. The management IP given in the WAN-settings will be assigned to the bridge interface, which will be created when activating the bridge

c'est donc comme indiqué dans le tuto rl0(interface LAN) qui est bridgé avec wan et les deux interfaces ont une adresse ip en 50.x.y.z et je tiens a signaler qu'il n'y a plus d'adresse ip en 60.x.x.x de disponibles...

le linux en place actuellement a un adresse ip sur le bridge uniquement pour l'administration.
les deux interfaces le constituant en sont dépourvue.

alors depuis 60.10.20.94 vers 60.10.20.91:
Avec un maximum de 30 sauts.
1 <1ms <1ms <1ms 60.10.20.91
Itinéraire déterminé

et dans l'autre sens, depuis serveur2 une liste de "délai d'attente de la demande dépassé"
et la, "bizzarerie" supplémentaire, lorsque l'on lance un ping depuis 60.10.20.94 -t, dans les 5-10 secondes qui suivent on obtient
1 <1ms <1ms <1ms 60.10.20.94

Sinon autre point, le "nez dans le guidon", je n'avais pas remarquer ceci du résultat du ifconfig :

bridge0: flags=28943 <up,broadcast,running,promisc,simplex,multicast,ppromisc>mtu 1500
        ether 62:28:48:e0:4a:28
        priority 32768 hellotime 2 fwddelay 15 maxage 20
        member: rl0 flags=7 <learning,discover,stp>port 2 priority 128 path cost 55 forwarding
        member: bge0 flags=7 <learning,discover,stp>port 1 priority 128 path cost 55 [b]disabled[/b]</learning,discover,stp></learning,discover,stp></up,broadcast,running,promisc,simplex,multicast,ppromisc>

disabled que j'ai changé en forwarding…
sans avoir plus d'effets...

autre info, lorsque je lance le ping "ouvrant la route", depuis 60.10.20.94, je le coupe, et, j'ai fait des test, j'ai 14secondes pendant lesquelles on peut encore amorcer un ping ok en partant de 60.10.20.91....

et j'avais oublier de préciser hier quand j'ai poster, mais j'ai remarqué ce paramètre : fwddelay 15
ne sachant pas trop se que c'est j'ai penser qu'il aurai put y avoir un rapport avec les 14sec de mémorisation de la route, j'ai donc ramener cette valeur a 2 pour tester, mais sa n'a aucun effet.

forus

bon un reboot du lundi matin, et désormais tout est ok…..

j'arrive même depuis serveur1 a atteindre routeur2.... o_O

j'ai fait un grand nombre de test/modif, donc je ne saurai pas trop dire pourquoi sa marche maintenant....

merci quand même pour votre aide qui m'a permis de me poser les bonnes questions.