Auteur Sujet: [FTTH - VLAN 100] Réglages pfsense net + TV  (Lu 67138 fois)

0 Membres et 1 Invité sur ce sujet

jinbeman

  • Abonné Bbox fibre
  • *
  • Messages: 47
  • Cachan (94)
[FTTH - VLAN 100] Réglages pfsense net + TV
« Réponse #108 le: 13 février 2024 à 22:05:40 »
Hello,

Est-ce que quelqu'un aurait un lien vers une doc qui permet de configurer correctement des règles de firewall sur opnsense/pfsense une fois la config ipv6 fonctionnelle telle que décrite ici ?
IPv6 est relativement nouveau pour moi, et je ne vois pas très bien comment tout cela s'articule entre les interfaces WAN / LAN et comment autoriser le trafic LAN tout en restreignant ce qui vient d'internet  :-\ (du coup en attendant j'ai un ipv6 fonctionnel, mais désactivé !).

dylanT

  • Abonné Bbox fibre
  • *
  • Messages: 4
  • Brest 29
[FTTH - VLAN 100] Réglages pfsense net + TV
« Réponse #109 le: 13 février 2024 à 23:03:11 »
Bonjour !
Malheureusement, je ne suis pas autorisé à spoofer l'adresse Mac. Le terrain est bloqué.

Avez-vous une idée de l'erreur que j'ai commise ?

Juste une petite de rien du tout, il est normal de ne pas pouvoir "spoofer" l'adresse mac dans un VLAN, mais par contre sur l'interface physique oui, il te suffit juste de la configurer (sans le VLAN 100) et tu pourras modifier l'adresse mac, et en suite la retirer la désactivé.

Si tu n'as rien compris, je te fais des screens

dylanT

  • Abonné Bbox fibre
  • *
  • Messages: 4
  • Brest 29
[FTTH - VLAN 100] Réglages pfsense net + TV
« Réponse #110 le: 13 février 2024 à 23:04:46 »
Hello,

Est-ce que quelqu'un aurait un lien vers une doc qui permet de configurer correctement des règles de firewall sur opnsense/pfsense une fois la config ipv6 fonctionnelle telle que décrite ici ?
IPv6 est relativement nouveau pour moi, et je ne vois pas très bien comment tout cela s'articule entre les interfaces WAN / LAN et comment autoriser le trafic LAN tout en restreignant ce qui vient d'internet  :-\ (du coup en attendant j'ai un ipv6 fonctionnel, mais désactivé !).

Bonjour,
Par défaut, tout le trafic entrant est bloqué, donc tout ce qui pourrais venir des adresse ipv6 est bloquer, donc tu peux les utiliser sans craintes.

jinbeman

  • Abonné Bbox fibre
  • *
  • Messages: 47
  • Cachan (94)
[FTTH - VLAN 100] Réglages pfsense net + TV
« Réponse #111 le: 14 février 2024 à 21:11:04 »
Bonjour,
Par défaut, tout le trafic entrant est bloqué, donc tout ce qui pourrais venir des adresse ipv6 est bloquer, donc tu peux les utiliser sans craintes.

En fait dès que je l'active, les machines répondent au ping depuis l'extérieur. Il me semble que c'est normal car les filtres OPNsense par défaut laissent passer l'ICMP, mais comme derrière je ne connais pas le comportement d'une interface configurée en track, et si l'on doit définir les règles sur l'interface WAN comme en IPv4 ou sur le LAN vu que c'est lui qui récupère le préfixe, je préfère commencer par comprendre avant d'activer.

jinbeman

  • Abonné Bbox fibre
  • *
  • Messages: 47
  • Cachan (94)
[FTTH - VLAN 100] Réglages pfsense net + TV
« Réponse #112 le: 26 avril 2024 à 21:17:27 »
Hello,

à tout hasard aucune nouveauté concernant le debug multicast ?

Je suis sous opnsense et au même stade que mentionné dans le tuto avec passage par pimd puis relance d'igmpproxy pour pouvoir changer de chaine.

Symnes

  • Abonné Bbox fibre
  • *
  • Messages: 607
  • Thouars - Deux-Sèvres (79)‌‌ ↓ 1Gbps | ↑ 700Mbps
    • Twitter
[FTTH - VLAN 100] Réglages pfsense net + TV
« Réponse #113 le: 06 octobre 2024 à 21:38:19 »
Maintenant il ne reste plus qu'a configuré DHCPv6 sur les autres interfaces de tel sorte qu'elles track l'interface WAN et le tour est joué. Vous devriez recevoir un préfix IPv6 et chaque interface interne à maintenaient une adresse IPv6 globale. Cependant, l'interface WAN elle par contre n'a toujours pas d'adresse globale. Une adresse Ipv6 globale est facultative sur l'interface WAN, car c'est l'adresse de lien local (fe80) est ce qui est utilisé pour la passerelle pour effectuer le routage dans ipv6. Là le problème est plus lié a Pfsense, qui n'assigne pas automatiquement une adresse à l'interface WAN quand il reçoit un préfix (cf. ref[1] pour plus d'information). Il semble que Pfsense plus 23.01 à de nombreux bugs plus ou moins liés à IPv6 qui seront corrigés dans la prochaine release (cf. ref[3]) et il semble que l'option DHCPv6 OPTION_PD_EXCLUDE ne soit pas encore prise en compte dans les implémentations du client DHCPv6 dans Pfsense/Freebsd, mais devrait être prochainement (cf. ref[5]).

Salut
J'ai essayé de mon coté de faire fonctionner l'IPv6, sans succès.
J'ai pas d'IPv6 au niveau des clients.
Voici ma config, est-ce que j'ai loupé un truc ? Une modif à faire coté DHCPv6 ?


Guillaume_B

  • Profil non complété
  • *
  • Messages: 2
  • 63
[FTTH - VLAN 100] Réglages pfsense net + TV
« Réponse #114 le: 18 octobre 2024 à 21:01:02 »
Bonjour,
J'ai mis en place mon opnsense il y a un an environ et j'ai pu enlever la bbox. La TV m'a pris un peu de temps à configuré mais j'ai fini par y arriver.
Mais depuis il m'arrive de temps en temps à perdre le fonctionnement TV. La dernière en date c'est ce lundi alors que le dimanche soir elle fonctionnait. La fois précédente c'était fin août au retour des vacances.
J'ai pu penser au problème des annonces igmp mentionné dans le premier post, mais l'auteur relate un problème après un arrêt long terme, hors entre dimanche et lundi il s'est écoulé peu de temps.
Bref, j'ai quand même tenté la manip : kill igmp proxy, run pimd, kill pimd et re-run igmp proxy. Ce n'est pas mieux.
Je sèche un peu sur la cause puisqu'il n'y a pas eu de modification de paramètre. Mais peut être une mise à jour. Et je sèche un peu sur la méthode pour rétablir (en panne depuis lundi).
Avez-vous des idées ?
Merci

EDIT :
En complément voici quelques infos et tests :
J'ai adressé :
- l'interface igc0 au WAN
- l'interface valn0.100 au vlan 100 à travers le port WAN
- l'interface igc3 au port où la TV est reliée

Voici mes rapports de test avec tcpdump :
root@OPNsense:~ # tcpdump -li igc3 igmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on igc3, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:51:27.152909 IP 192.168.200.10 > 239.255.255.250: igmp v2 report 239.255.255.250
15:51:31.340494 IP 192.168.200.1 > igmp.mcast.net: igmp v2 report igmp.mcast.net
15:51:32.832974 IP 192.168.200.10 > mdns.mcast.net: igmp v2 report mdns.mcast.net
15:51:37.057276 IP 192.168.200.1 > all-systems.mcast.net: igmp query v2
15:51:38.832999 IP 192.168.200.10 > mdns.mcast.net: igmp v2 report mdns.mcast.net
15:51:41.469710 IP 192.168.200.1 > igmp.mcast.net: igmp v2 report igmp.mcast.net
15:51:41.893685 IP 192.168.200.1 > all-routers.mcast.net: igmp v2 report all-routers.mcast.net
15:51:43.783067 IP 192.168.200.10 > 232.0.64.202: igmp v2 report 232.0.64.202
15:51:44.353037 IP 192.168.200.10 > 239.255.255.250: igmp v2 report 239.255.255.250
15:51:46.033060 IP 192.168.200.10 > 232.0.64.202: igmp v2 report 232.0.64.202
15:51:50.170032 IP 192.168.200.1 > all-systems.mcast.net: igmp query v2
15:51:51.953104 IP 192.168.200.10 > 239.255.255.250: igmp v2 report 239.255.255.250
15:51:52.433102 IP 192.168.200.10 > mdns.mcast.net: igmp v2 report mdns.mcast.net
15:51:52.593109 IP 192.168.200.10 > 232.0.64.202: igmp v2 report 232.0.64.202
15:51:52.837315 IP 192.168.200.10 > all-routers.mcast.net: igmp leave 232.0.64.202
15:51:52.837537 IP 192.168.200.1 > 232.0.64.202: igmp query v2 [gaddr 232.0.64.202]
15:51:54.806407 IP 192.168.200.1 > all-routers.mcast.net: igmp v2 report all-routers.mcast.net
15:52:00.280685 IP 192.168.200.1 > igmp.mcast.net: igmp v2 report igmp.mcast.net
15:52:02.041270 IP 192.168.200.1 > 232.0.64.202: igmp query v2 [gaddr 232.0.64.202]
15:52:08.744537 IP 192.168.200.1 > 232.0.64.202: igmp query v2 [gaddr 232.0.64.202]
15:52:14.821513 IP 192.168.200.1 > all-systems.mcast.net: igmp query v2
15:52:16.193272 IP 192.168.200.10 > 239.255.255.250: igmp v2 report 239.255.255.250
15:52:23.393328 IP 192.168.200.10 > mdns.mcast.net: igmp v2 report mdns.mcast.net
15:52:23.889710 IP 192.168.200.1 > igmp.mcast.net: igmp v2 report igmp.mcast.net
15:52:23.889740 IP 192.168.200.1 > all-routers.mcast.net: igmp v2 report all-routers.mcast.net
15:52:26.936482 IP 192.168.200.1 > all-systems.mcast.net: igmp query v2
15:52:30.843706 IP 192.168.200.1 > igmp.mcast.net: igmp v2 report igmp.mcast.net
15:52:33.633400 IP 192.168.200.10 > 239.255.255.250: igmp v2 report 239.255.255.250
15:52:35.251459 IP 192.168.200.1 > all-routers.mcast.net: igmp v2 report all-routers.mcast.net
15:52:35.553406 IP 192.168.200.10 > mdns.mcast.net: igmp v2 report mdns.mcast.net
15:52:38.568529 IP 192.168.200.1 > all-systems.mcast.net: igmp query v2
15:52:44.513487 IP 192.168.200.10 > mdns.mcast.net: igmp v2 report mdns.mcast.net
15:52:44.981437 IP 192.168.200.1 > igmp.mcast.net: igmp v2 report igmp.mcast.net
15:52:45.153481 IP 192.168.200.10 > 239.255.255.250: igmp v2 report 239.255.255.250
15:52:46.041676 IP 192.168.200.1 > all-routers.mcast.net: igmp v2 report all-routers.mcast.net
15:52:49.054522 IP 192.168.200.1 > all-systems.mcast.net: igmp query v2
15:52:51.324690 IP 192.168.200.1 > igmp.mcast.net: igmp v2 report igmp.mcast.net
15:52:53.443561 IP 192.168.200.10 > 232.0.64.202: igmp v2 report 232.0.64.202
^C
38 packets captured
120 packets received by filter
0 packets dropped by kernel


root@OPNsense:~ # tcpdump -li vlan0.100 igmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vlan0.100, link-type EN10MB (Ethernet), snapshot length 262144 bytes
root@OPNsense:/usr/local/etc # tcpdump -li vlan0.100 igmp
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on vlan0.100, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:51:32.833493 IP xxx > mdns.mcast.net: igmp v2 report mdns.mcast.net
15:51:43.783720 IP xxx > 232.0.64.202: igmp v2 report 232.0.64.202
15:51:52.837476 IP xxx > all-routers.mcast.net: igmp leave 232.0.64.202
15:52:01.018508 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
15:52:04.688709 IP xxx > 239.255.255.250: igmp v2 report 239.255.255.250
15:52:05.738732 IP xxx > mdns.mcast.net: igmp v2 report mdns.mcast.net
15:52:53.444180 IP xxx > 232.0.64.202: igmp v2 report 232.0.64.202
15:52:54.884048 IP xxx > all-routers.mcast.net: igmp leave 232.0.64.202
^C
5 packets captured
23929 packets received by filter
0 packets dropped by kernel

root@OPNsense:/usr/local/etc # /usr/local/sbin/igmpproxy -d -vvvv /usr/local/etc/igmpproxy.conf
Searching for config file at '/usr/local/etc/igmpproxy.conf'
Config: Quick leave mode enabled.
...
...
Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 232.0.64.24, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#1: Dst: 239.255.255.250, Age:1, St: I, OutVifs: 0x00000001, dHosts: yes
-----------------------------------------------------
About to call timeout 4 (#0)
SENT Membership query   from 192.168.200.1   to 224.0.0.1
Sent membership query from 192.168.200.1 to 224.0.0.1. Delay: 10
SENT Membership query   from 192.168.210.1   to 224.0.0.1
Sent membership query from 192.168.210.1 to 224.0.0.1. Delay: 10
Created timeout 5 (#0) - delay 10 secs
(Id:5, Time:10)
Created timeout 6 (#1) - delay 115 secs
(Id:5, Time:10)
(Id:6, Time:115)
RECV Membership query   from 192.168.200.1   to 224.0.0.1
RECV Membership query   from 192.168.210.1   to 224.0.0.1
RECV Membership query   from 192.168.210.1   to 224.0.0.1
RECV V2 member report   from 192.168.200.10  to 224.0.0.251
Should insert group 224.0.0.251 (from: 192.168.200.10) to route table. Vif Ix : 0
No existing route for 224.0.0.251. Create new.
Found existing routes. Find insert location.
Inserting after route 239.255.255.250
Inserted route table entry for 224.0.0.251 on VIF #0
Joining group 224.0.0.251 upstream on IF address xxx
Joining group 224.0.0.251 on interface vlan0.100

Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 232.0.64.24, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#1: Dst: 239.255.255.250, Age:1, St: I, OutVifs: 0x00000001, dHosts: yes
#2: Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
-----------------------------------------------------
RECV V2 member report   from xxx   to 224.0.0.251
The IGMP message was from myself. Ignoring.
RECV V2 member report   from xxx   to 224.0.0.251
The IGMP message was from myself. Ignoring.
RECV V2 member report   from 192.168.200.10  to 239.255.255.250
Should insert group 239.255.255.250 (from: 192.168.200.10) to route table. Vif Ix : 0
Updated route entry for 239.255.255.250 on VIF #0

Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 232.0.64.24, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#1: Dst: 239.255.255.250, Age:1, St: I, OutVifs: 0x00000001, dHosts: yes
#2: Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
-----------------------------------------------------
RECV V2 member report   from 192.168.210.1   to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V2 member report   from 192.168.210.1   to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V2 member report   from 192.168.200.10  to 232.0.64.24
Should insert group 232.0.64.24 (from: 192.168.200.10) to route table. Vif Ix : 0
Updated route entry for 232.0.64.24 on VIF #0

Current routing table (Insert Route):
-----------------------------------------------------
#0: Dst: 232.0.64.24, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
#1: Dst: 239.255.255.250, Age:1, St: I, OutVifs: 0x00000001, dHosts: yes
#2: Dst: 224.0.0.251, Age:2, St: I, OutVifs: 0x00000001, dHosts: yes
-----------------------------------------------------
RECV V2 member report   from 192.168.210.1   to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV V2 member report   from 192.168.210.1   to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV Leave message      from 192.168.200.10  to 224.0.0.2
Got leave message from 192.168.200.10 to 232.0.64.24. Starting last member detection.
counted 1 interfaces
quickleave is enabled and this was the last downstream host, leaving group 232.0.64.24 now
Leaving group 232.0.64.24 upstream on IF address xxx
Leaving group 232.0.64.24 on interface vlan0.100
Interface id 0 is in group $d
SENT Membership query   from 192.168.200.1   to 232.0.64.24
Sent membership query from 192.168.200.1 to 232.0.64.24. Delay: 10
Interface id 2 is in group $d
Created timeout 7 (#1) - delay 2 secs
(Id:5, Time:8)
(Id:7, Time:2)
(Id:6, Time:113)
RECV Leave message      from xxx   to 224.0.0.2
Got leave message from xxx to 232.0.64.24. Starting last member detection.
The found if for xxx was not downstream. Ignoring leave request.
RECV Leave message      from xxx   to 224.0.0.2
Got leave message from xxx to 232.0.64.24. Starting last member detection.
The found if for xxx was not downstream. Ignoring leave request.
RECV Membership query   from 192.168.200.1   to 232.0.64.24

et
netstat -g
IPv4 Multicast Forwarding Table is empty
« Modifié: 19 octobre 2024 à 16:07:29 par Guillaume_B »

Guillaume_B

  • Profil non complété
  • *
  • Messages: 2
  • 63
[FTTH - VLAN 100] Réglages pfsense net + TV
« Réponse #115 le: 19 octobre 2024 à 17:04:10 »
En faisant des tests j'ai changé les chaînes et deux chaînes se sont affichées et donc ajout dans la table de routage multicast :
IPv4 Multicast Forwarding Table
 Origin          Group             Packets In-Vif  Out-Vifs:Ttls
 89.86.96.3      232.0.32.15          5551    1    0:1
 89.86.96.3      232.0.32.14          1901    1    0:1


Mais la première à fonctionnée seulement quelques secondes avant de se couper à nouveau puis j'ai pu la remettre en zappant.

Je ne comprend pas trop mon soucis. Visiblement je reçois les annonces multicast :
16:54:31.029217 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
Le parefeu semble aussi correctement paramétré puisque fonctionnel de temps en temps.
Est-ce que ça pourrait être des problèmes de timeout ?

Pour les upstreams j'ai ça :
89.86.96.0/24, 89.86.97.0/24, 176.165.8.0/24, 193.251.97.0/24
Pas de raison que ces valeurs changent ?

al3x360

  • Abonné Bbox fibre
  • *
  • Messages: 4
  • CHÂTEAUROUX36
[FTTH - VLAN 100] Réglages pfsense net + TV
« Réponse #116 le: 20 octobre 2024 à 18:20:45 »
Hello,

Recement parti de Orange pour aller chez boyugues, j'ai bien Internet . Par contre : J'ai suivi le tuto, j'ai rien du tout qui marche concernant la TV. Quand je fais des TCPDUMP sur le Wan en VLAN 100 j'ai rien du tout concernant IGMP.

Je peux pas installer PIMD parce que le package existe plus . j'ai tenté l'install avec le package manager, mais quand je veux lancer la config avec la ligne de commande, j'ai acces denied.

Je ne comprends pas le sens des flux entrants et sortants. Il est écrit qu'il doit y avoir des flux en entrée et/ou en sortie et sur les captures c'est en direction : Any . Je vois pas trop d'où peux venir le problème . j'ai bien mis les préfixes TV et les ports J'ai reboot le routeur et la le decodeur 4K . mais rien n'y fait j'ai rien du tout en terme de signal et de packets qui transitent.

Quand je tente de lancer la commande avec -vvvv concernant igmpproxy je ne joints aucun réseau multicast . Avez vous une idée pour configurer la télé svp ?


EDIT j'ai réussi a installer PIMD et binder les interfaces en IGMPv2 , j'ai bien des réponses de ce type :

listening on re0.100, link-type EN10MB (Ethernet), snapshot length 262144 bytes

17:24:09.421750 IP xxx.abo.bbox.fr > all-systems.mcast.net: igmp query v2
17:24:12.995721 IP xxx.abo.bbox.fr > igmp.mcast.net: igmp v2 report igmp.mcast.net
17:24:16.595723 IP xxx.abo.bbox.fr > all-routers.mcast.net: igmp v2 report all-routers.mcast.net
17:24:18.195720 IP xxx.abo.bbox.fr > pim-routers.mcast.net: igmp v2 report pim-routers.mcast.net
17:24:25.447921 IP xxx.abo.bbox.fr > all-systems.mcast.net: igmp query v2
17:24:29.195721 IP xxx.abo.bbox.fr > all-routers.mcast.net: igmp v2 report all-routers.mcast.net
17:24:33.195718 IP xxx.abo.bbox.fr > igmp.mcast.net: igmp v2 report igmp.mcast.net

Par contre toujours rien concernant netstat -g

 "IPv4 Multicast Forwarding Table is empty"

Je ne comprends pas pourquoi c'est vide, j'ai fait des règles flottantes en any/any


EDIT 2 : J'ai fait des regles entrantes et sortantes en cos p3 pour UDP et IGMP, sur les règles flotantes, j'ai pas de lien en UDP... je vois pas de quoi ça peut venir .


avec la commande ifmcstate j'ai ça

re0.100:
        inet 62.x.x.x
        igmpv2
                group 224.0.0.22 mode exclude
                        mcast-macaddr 01:00:5e:00:00:16
                group 224.0.0.2 mode exclude
                        mcast-macaddr 01:00:5e:00:00:02
                group 224.0.0.13 mode exclude
                        mcast-macaddr 01:00:5e:00:00:0d
                group 224.0.0.1 mode exclude
                        mcast-macaddr 01:00:5e:00:00:01
        inet6 fe80::fabc:12ff:fe9a:45c6%re0.100 scopeid 0x9
        mldv2 flags=2<USEALLOW> rv 2 qi 125 qri 10 uri 3
                group ff01::1%re0.100 scopeid 0x9 mode exclude
                        mcast-macaddr 33:33:00:00:00:01
                group ff02::2:eea7:5734%re0.100 scopeid 0x9 mode exclude
                        mcast-macaddr 33:33:ee:a7:57:34
                group ff02::2:ffee:a757%re0.100 scopeid 0x9 mode exclude
                        mcast-macaddr 33:33:ff:ee:a7:57
                group ff02::1%re0.100 scopeid 0x9 mode exclude
                        mcast-macaddr 33:33:00:00:00:01
                group ff02::1:ff9a:45c6%re0.100 scopeid 0x9 mode exclude
                        mcast-macaddr 33:33:ff:9a:45:c6

que des modes excludes, est-ce que ça vous est déja arrivé ?

Édit 3 : J'ai un boîtier ONT de chez bouygues commandé après réception de la bbox et raccordement au réseau fibre BT : le câble est branché sur mon pfsense sur la pate WAN, on dirait que bouygues ne fait pas de trafic entrant si la bbox n'est pas détectée. Pourtant, j'ai spoofé la mac de la bbox.

Edit 4 : après plusieurs lectures sur d'autres sujet du Forum, j'ai vu que je pouvais regarder les logs du pare-feu et filtrer sur L'UDP pour voir ce qui bloquait, je vais faire des tests demain, mais je suis 99% sûr que les règles flottantes sont ignorées pour l'UDP. Je ne sais pas pourquoi :0


Edit 5 : Ce matin 21.10.2024 j'ai fait des tests, et je n'ai reçu aucune réponse IGMP, mes requetes sont OK elles passent, mais j'ai eu aucun signal UDP venant des prefixes TV . j'ai relancé plusieurs fois PIMD, arreté puis lancé IGMP Proxy, rien à faire, aucun signal sur la TV... alors que les logs d'hier montrent qu'une IP des prefixes envoyait des requetes multicast vers mon PFsense sur le port 8200. Je sèche complet

Edit 6 : après quelques recherche sur les build CE de pfsense, IGMP et IGMP proxy ont l'air d'etre un peu buggy. Et ça serait réparé dans la prochaine release en 2.8. D'autres personnes dans d'autres pays  ont aussi des problème avec IGMP et pfsense en 2.7. Certains disent qu'en 2.6 ça fonctionne. Ça vaut le coup d'essayer. Je ferais un retour  :)
« Modifié: 22 octobre 2024 à 06:16:42 par al3x360 »

Olivier34

  • Abonné Bbox fibre
  • *
  • Messages: 7
  • Monptellier (34)
[FTTH - VLAN 100] Réglages pfsense net + TV
« Réponse #117 le: 07 décembre 2024 à 15:57:21 »
Bonjour,

En creusant le sujet d'IGMPv3 (sur opnsense mais ça doit être similaire avec pfsense), j'ai trouvé les points suivants :
  • Dans le code de FreeBSD, il y a le commit suivant : https://github.com/freebsd/freebsd-src/commit/b94ec00ba73ef4769f62555bfcb840919143e198, qui permettra de respecter le choix net.inet.igmp.default_version. Malheureusement, ce commit ne fait pas partie des versions 13 ou 14 de FreeBSD. Car pour le moment même s'il est mis à 2, ça n'a pas d'impact
  • Lorsque FreeBSD voit passer une requête IGMPv2 alors il reste en IGMPv2 jusqu'au timeout. C'est de cette façon que l'astuce avec pimd fonctionne. Il envoie quelques requêtes en v2 et ça reste actif pendant un certain temps après la dernière requête. En effet celui-ci envoie des demandes en IGMPv2 et du coup FreeBSD reste en IGMPv2
  • ifmcstat permet d'afficher des informations sur la gestion des groupes multicast : https://man.freebsd.org/cgi/man.cgi?query=ifmcstat&sektion=8
  • igmpproxy n'envoie pas directement les trames IGMP mais fait appel à l'OS pour envoyer les demandes via les commandes "IP_ADD_MEMBERSHIP" et "IP_DROP_MEMBERSHIP" de la fonction setsockopt

Il est possible de savoir si on est en IGMPv2 ou IGMPv3 avec par exemple le code suivant avec "vlan00.100" l'interface du WAN :
if ifmcstat -i vlan00.100 -f inet | grep -q "igmpv3"; then
   echo "On est en IGMPv3"
fi

jinbeman

  • Abonné Bbox fibre
  • *
  • Messages: 47
  • Cachan (94)
[FTTH - VLAN 100] Réglages pfsense net + TV
« Réponse #118 le: 13 janvier 2025 à 09:31:23 »
Hello,

Effectivement de ce que je vois le commit est actuellement sur main mais n'a pas été pris dans le code source de la version 14 de freebsd, ce qui signifie qu'on peut l'attendre au plus tôt pour décembre de ce côté, et ensuite il faudra encore attendre une nouvelle version d'*sense basée sur cette version.  :-\