La Fibre
Datacenter et équipements réseaux => Routeurs => 
Remplacer la Bbox par un routeur => Discussion démarrée par: mirtouf le 02 mars 2019 à 13:13:11
-
Forumeuses, forumeurs,
Faisant suite à mon message indiquant les données techniques nécessaires pour se passer de la bbox (routeur) (https://lafibre.info/remplacer-bbox/retro-ingenierie/), je donne ici les grandes lignes nécessaires pour récupérer l'accès internet et les flux TV + replays (moyennant peut-être une bidouille, vous verrez cela à la fin de ce message). Pour le téléphone, il faudra pousser un peu plus loin les investigations pour obtenir le mot de passe et sans nul doute implèmenter le système anti-rejeu mis en place par ByTel.
1. Internet
Une simple requête dchp sur le vlan 100 permet de récupérer une IP publique. Il serait préférable de marquer p6 les requêtes dhcp comme le fait la bbox si d'aventure Bouygues était plus regardant sur la connexion d'appareils tiers sur son réseau (coucou Orange).
De manière optionnelle, vous pouvez cloner l'adresse MAC de la bbox et donner l'option " dhcp-class-identifier "BYGTELIAD" " dans l'interface de configuration de l'interface WAN.
Rien de plus n'est demandé avec pfsense pour avoir un accès internet fonctionnel. Je vous laisse choisir les serveurs DNS, NTP, etc. de votre choix.
(https://imgur.com/IApqFdi.png)
Pour avoir la TV, il faut désactiver la protection contre les adresses bogons (0.0.0.0 est source IGMP) !
2. TV
Pour la TV, je recommande que la miami utilise les DNS Bouygues pour éviter d'éventuels problèmes. Cela peut se faire via une interface réseau dédiée ou un règle d'adressage statique.
Pour la suite, il faut ajouter des règles de filtrage en entrée pour autoriser les messages IGMP ainsi que les flux UDP multicast. En option, les messages IGMP seront à marquer p3 pour faire comme la bbox. Pour ce faire il faut utiliser les règles flottantes dans pfsense (j'ai aussi marqué p6 les requêtes ICMP en sortie pour faire comme la bbox) sans oublier d'activer l'option "Allow IP options" pour IGMP et les flux UDP.
(https://imgur.com/5aTuPjO.png)
TV_prefixes:
- 89.86.96.0/24
- 89.86.97.0/24
- 176.165.8.0/24
- 193.251.97.0/24
TV_sources_ports:
(https://imgur.com/C5AoyZe.png)
Pour les flux UDP (seul le trafic en entrée depuis les réseaux et les ports spécifiés est autorisé):
(https://imgur.com/A8CCLPG.png)
Pour l'IGMP (on autorise le trafic en entrée depuis tout le monde, 0.0.0.0 est source):
(https://imgur.com/Mi143sX.png)
Il reste ensuite IGMP proxy à activer, dans mon cas, j'ai isolé le boitier TV sur une interface dédiée (OPT2 et non LAN) mais le raisonnement reste le même:
(https://imgur.com/0xGo2Ly.png)
Maintenant, cela doit marcher, vous devriez avoir accès à la TV. Si cela ne fonctionne pas, vous avez une façon d'identifier la cause du problème plus loin.
Côté OPT2 (ou LAN), il faut également cocher l'option "Allow IP options" dans les règles pfsense par défaut.
3. Replays & VOD
Pour les replays du NAT (plutôt du PAT mais bon) suffit, il faut rediriger les ports UDP vers la miami de cette façon:
(https://imgur.com/ErZZmgV.png)
en n'oubliant pas de cocher d'activer l'option Create new associated filter rule
avec VOD_replay:
- 212.195.48.0/24
- 212.195.244.0/24
- 62.34.201.0/24
- 194.158.119.0/24
- 195.36.152.0/24
4. Téléphone
Nope, toujours pas.
5. Debug multicast
Si la TV ne fonctionne pas, il faut regarder si:
- rien n'est bloqué côté firewall (igmpproxy agit comme un proxy donc les règles de filtrage se font uniquement en entrée, rien n'est forwardé)
- igmpproxy tourne bien
- les annonces igmp sont bien reçues car sans elles aucune route mutlicast ne sera insérée dans la table de routage (netstat -g), pour ce faire un petit
tcpdump -li igb0.100 igmp où igb0.100 est l'interface WAN
Si vous avez ceci en sortie:
23:40:27.703941 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:40:28.304010 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:40:36.703955 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:40:38.103922 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:40:40.903937 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:40:41.503930 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)
23:40:49.913925 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v3 report, 1 group record(s)c'est le même problème que moi, la solution sera donnée juste un peu plus loin. ;D
par contre si vous avez ceci:
23:24:57.374650 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
23:24:58.145961 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 232.0.64.232: igmp v2 report 232.0.64.232
23:24:59.545937 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 239.192.152.143: igmp v2 report 239.192.152.143
23:25:00.346953 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 239.255.3.22: igmp v2 report 239.255.3.22
23:25:01.546956 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
23:25:06.950954 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 224.0.0.252: igmp v2 report 224.0.0.252
23:27:02.394776 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
23:27:03.423947 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 239.255.3.22: igmp v2 report 239.255.3.22
23:27:06.625959 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
23:27:08.425946 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 239.192.152.143: igmp v2 report 239.192.152.143
23:27:09.827008 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 224.0.0.252: igmp v2 report 224.0.0.252
23:27:10.026947 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 232.0.64.232: igmp v2 report 232.0.64.232
23:29:07.462388 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
23:29:08.498940 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 239.192.152.143: igmp v2 report 239.192.152.143
23:29:13.903939 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 232.0.64.232: igmp v2 report 232.0.64.232
23:29:15.105936 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 239.255.3.22: igmp v2 report 239.255.3.22
23:29:15.305935 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
23:29:16.105935 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 224.0.0.252: igmp v2 report 224.0.0.252
23:30:27.152191 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave 232.0.64.232
23:30:39.904391 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave 239.255.3.22c'est que votre firewall est trop restrictif au niveau UDP car vous recevez bien les requêtes IGMP. Cela peut-être dû à une erreur de votre part ou à des préfixes qui ne sont pas listés ici (seul gartox et moi-même avons confirmé les préfixes balançant des flux multicast).
Si vous envoyez des requêtes IGMP sans réponse de la part de l'OLT (?), essayez ceci:
- installation pimd
pkg add http://pkg.freebsd.org/FreeBSD:11:amd64/release_2/All/pimd-2.3.2.txz
- arrêt igmpproxy
/usr/local/sbin/pfSsh.php playback svc stop igmpproxy
- configuration pimd, /usr/local/etc/pimd.conf (igb0.100 côté WAN et igb2 pour la TV)
# These two are only needed if pimd is stared with -N flag
phyint igb0.100 enable igmpv2
phyint igb2 enable igmpv2
# Used for more complex topologies, but is OK to keep anyway
spt-threshold packets 0 interval 100
# These two are requried in case more PIM routers are available
bsr-candidate priority 5
rp-candidate time 30 priority 20
Cela ne fonctionne pas mais ce n'est pas grave, faites tourner 10 secondes, tuez pimd et relancez igmpproxy
/usr/local/sbin/pfSsh.php playback svc start igmpproxy
Cela devrait maintenant marcher, c'est le mieux que j'ai pour le moment à proposer.
J'ai donc bidouillé un script Q&D qui tourne dans ma crontab:
#!/bin/sh
route1=$(netstat -g | grep 232)
hote1=Bouygtel4K-numérodesérie
ping1=$(ping -c 3 -W 1 $hote1)
rping1=$(echo $?)
if ([ -z "$route1" ] && [ $rping1 -eq 0 ]); then
echo "Stopping IGMPproxy"
/usr/local/sbin/pfSsh.php playback svc stop igmpproxy
sleep 3
echo "Starting pimd for debugging and letting it run for 7 seconds"
/usr/local/sbin/pimd -N -c /usr/local/etc/pimd.conf
sleep 7
echo "Stopping pimd"
killall pimd
sleep 1
echo "Starting again IGMPproxy"
/usr/local/sbin/pfSsh.php playback svc start igmpproxy
exit 1
else
echo "Nothing to do for IGMPproxy"
exit
fiLa grosse limitation du truc est que si la bbox est up et fait autre chose (replays, application, etc.) ou en veille, je suis dans l'impossibilité de savoir s'il est utile de relancer le script. En effet, au-delà de 5 minutes, sans mise à jour de la table de routage, il sera de nouveau impossible de regarder la TV...
Je ne suis pas assez calé pour comprendre les raisons de ce phénomène qui n'est pas apparu chez tivoli ou gartox. J'avais eu le même comportement avec un PC GNU/Linux, EdgeOS ou RouterOS.
6. Mises à jour Miami
Selon toute vraisemblance, il faut activer upnp pour que la bbox puisse faire ses mises à jour via le service TR-069 de Bouygues.
Je n'ai pas encore pu confirmer cette hypothèse, il faudra voir avec le temps si la Miami reste bloquée à une certaine version logicielle sans l'upnp actif.
7. Révisions
20190302. Premier message
20190304. Les images sont affichées, correction de typos
20190311. Ajout d'une recommandation d'utiliser les DNS Bouygues pour la Miami
-
Réservé
-
Merci
-
Bonjour, tout d'abord merci pour ce super tuto. De mon coté j'obtiens aucun signal sur la tv sur laquelle est branchée ma box. Elle reste bloqué à deux led allumé (bas et milieu) et une qui clignotte (haut).
En faisant un dump j'obtiens ça :
root@OPNsense:~ # tcpdump -li igb1_vlan100 igmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb1_vlan100, link-type EN10MB (Ethernet), capture size 262144 bytes
10:43:41.688227 IP proXX-hXX-XX-XX-XX-XX.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
10:43:53.732663 IP proXX-hXX-XX-XX-XX-XX.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave 224.0.0.251
10:43:56.488492 IP proXX-hXX-XX-XX-XX-XX.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
10:44:06.562548 IP proXX-hXX-XX-XX-XX-XX.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave 224.0.0.251
10:44:13.388953 IP proXX-hXX-XX-XX-XX-XX.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
10:44:15.682199 IP proXX-hXX-XX-XX-XX-XX.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave 224.0.0.251
10:44:19.883133 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
10:45:04.189152 IP proXX-hXX-XX-XX-XX-XX.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
10:45:13.003270 IP proXX-hXX-XX-XX-XX-XX.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave 224.0.0.251
10:45:17.089114 IP proXX-hXX-XX-XX-XX-XX.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
10:45:29.331982 IP proXX-hXX-XX-XX-XX-XX.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave 224.0.0.251
10:45:34.289179 IP proXX-hXX-XX-XX-XX-XX.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
10:45:51.450734 IP proXX-hXX-XX-XX-XX-XX.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave 224.0.0.251
10:45:54.489830 IP proXX-hXX-XX-XX-XX-XX.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
10:46:03.515718 IP proXX-hXX-XX-XX-XX-XX.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave 224.0.0.251
10:46:07.189736 IP proXX-hXX-XX-XX-XX-XX.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
10:46:10.858859 IP proXX-hXX-XX-XX-XX-XX.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave 224.0.0.251
une idée de quoi cela peut venir?
-
Salut, en mode normal, seule la LED du milieu est allumée (du moins sur la 4k).
Donc le problème ne vient pas des réglages firewall, je dirais à vue de nez que c'est plus un problème lié au serveur dhcp avec une miami qui reste plantée lors de sa phase d'initialisation mais il faudra plus d'information pour statuer.
-
Merci pour ta réponse, j'ai maintenant uniquement la led du milieu allumé. Par contre des messages d'erreur sur toutes les chaines :
Oups, je ne reçois plus la chaine ARTE HD! Merci de vérifier les branchements de vos équipements (F3411).
J'ai toujours les mêmes logs. Est ce que tu aurais une idée?
-
Il faut regarder :
- le filtrage UDP en entrée et IGMP
- la configuration du proxy IGMP
-
J'ai fait toutes ces confs :
(https://i.ibb.co/tZCpSpC/2019-03-10-160916.png) (https://ibb.co/0BJykyJ)
(https://i.ibb.co/3r26RcX/2019-03-10-161007.png) (https://ibb.co/VjRnwTy)
(https://i.ibb.co/KyXytRZ/2019-03-10-161101.png) (https://ibb.co/2KyKzm2)
Tu vois un truc qui manquerait car la j'ai vérifié trois fois et je vois pas ce qui peut clocher.
Je devrais avoir quoi dans les logs? ce que j'ai posté comme logs te semble correct?
-
Et la conf igmp proxy :
(https://i.ibb.co/WkwxdfJ/2019-03-10-161837.png) (https://ibb.co/bsZWyX9)
-
Il faut regarder si quelque chose bloque au niveau du pare-feu et regarder si les routes sont mises à jour via netstat -g
-
IPv4 Multicast Forwarding Table is empty
C'est normal?
-
nope, cela veut dire que soit le trafic IGMP est bloqué, soit igmpproxy ne tourne pas correctement soir il faut employer ma bidouille.
-
Les seuls choses que je vois de bloqué dans les logs en UDP c'est de l'IP V6 donc rien à voir?
-
Je ne comprends pas: si je suis ce que tu as noté :
par contre si vous avez ceci:
23:24:57.374650 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
23:24:58.145961 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 232.0.64.232: igmp v2 report 232.0.64.232
23:24:59.545937 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 239.192.152.143: igmp v2 report 239.192.152.143
23:25:00.346953 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 239.255.3.22: igmp v2 report 239.255.3.22
23:25:01.546956 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
23:25:06.950954 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 224.0.0.252: igmp v2 report 224.0.0.252
23:27:02.394776 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
23:27:03.423947 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 239.255.3.22: igmp v2 report 239.255.3.22
23:27:06.625959 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
23:27:08.425946 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 239.192.152.143: igmp v2 report 239.192.152.143
23:27:09.827008 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 224.0.0.252: igmp v2 report 224.0.0.252
23:27:10.026947 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 232.0.64.232: igmp v2 report 232.0.64.232
23:29:07.462388 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
23:29:08.498940 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 239.192.152.143: igmp v2 report 239.192.152.143
23:29:13.903939 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 232.0.64.232: igmp v2 report 232.0.64.232
23:29:15.105936 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 239.255.3.22: igmp v2 report 239.255.3.22
23:29:15.305935 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
23:29:16.105935 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > 224.0.0.252: igmp v2 report 224.0.0.252
23:30:27.152191 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave 232.0.64.232
23:30:39.904391 IP plh29-h01-176-133-x-y.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave 239.255.3.22c'est que votre firewall est trop restrictif au niveau UDP car vous recevez bien les requêtes IGMP. Cela peut-être dû à une erreur de votre part ou à des préfixes qui ne sont pas listés ici (seul gartox et moi-même avons confirmé les préfixes balançant des flux multicast).
Cela voudrait dire que mon firewall est trop restrictif? donc je devrait voir des choses bloqué dans les logs. Or je n'ai rien. Je t'avoue que je ne comprends pas du coup...
-
IGMP est un protocole réseau différent de l'UDP, il faut filtrer sur ce protocole pour être sûr.
Il va falloir lancer igmpproxy de cette façon après l'avoir désactiver dans opnsense:
/usr/local/sbin/igmpproxy -d -vvvv /var/etc/igmpproxy.conf
De toute façon, les routes multicast doivent être connues avant de pouvoir espérer recevoir les flux UDP.
Ce qui est inquiétant est qu'aucune demande de route vers 232.0.0.0/16 et 239.255.0.0/16 ne semble sortir de ton réseau
-
j'ai essayé de filtré les logs sur igmp mais ça me sort rien. Il faut que je fasse quoi ? Je lance juste ta commande et je retest?
-
Je ferais:
- désactiver igmpproxy
- lancer un mode debug du programme
- vérifier que les routes multicast sont à jour
Il faut aussi vérifier que la version d'igmpproxy fournie est suffisamment récente, la version 0.1 a trop de bugs.
-
alors pour la version d'igmp proxy :
os-igmp-proxy (installed) 1.3_2
DOnc si je comprends bien :
-je désactive igmpproxy
-je lance ta commande : usr/local/sbin/igmpproxy -d -vvvv /var/etc/igmpproxy.conf
-je lance netstat -g pour voir si j'ai des routes multi cast
C'est bien ça?
-
oui, pfsense et opnsense n'ont pas les mêmes patches à priori mais la même base (0.2.1).
-
Je viens de tester ta ommande cependant ça ne fonctionne pas car je n'ai pas le fichier de conf /var/etc/igmpproxy.conf
J'ai loupé un truc?
-
bah il faut trouver où opnsense stocke le fichier de configuration.
-
j'ai trouvé :
/usr/local/etc/igmpproxy.conf
Par contre j'ai toujours un problème :
MC-Router API already in use; Errno(48): Address already in use
Tu vois de quoi ça vient?
-
igmppropxy tourne toujours (ou tout autre programme manipulant les routes multicast).
-
j'essaye de kill le procees mais impossible il change en permanence de PID :
53258: No such process
Tu aurais pas une idée?
-
Aucune idée, soit un script soit un watchdog qui tourne sont mes intuitions.
-
Et bien ça devient compliqué... je crois que je vais être obligé de remettre la box... :(
-
Bonjour, et tout d'abord merci pour ce tuto très intéressant ;D !
J'avais tenté de faire fonctionner la TV sous pfSense il y a bientôt 2 ans lorsque le FTTH est arrivé chez moi (pas de vlan 100 unique à l'époque), mais sans succès... Tes explications m'ont redonné envie de tester mais malheureusement c'est toujours un échec :'(.
Je suis également sous Opnsense, et pour commencer je n'ai même pas de requête IGMP qui partent sur l'interface WAN, malgré avoir suivi chaque étape et un proxy IGMP qui semble bien actif...
La seule partie que je n'ai pas pu/su faire est "Côté OPT2 (ou LAN), il faut également cocher l'option "Allow IP options" dans les règles pfsense par défaut.", je n'ai pas trouvé des paramètre équivalent.
Voici les règles floating :
(https://i.ibb.co/485M6BY/1floating.png) (https://ibb.co/485M6BY)
Et la configuration du proxy IGMP :
(https://i.ibb.co/bg4NJ53/2igmpproxy.png) (https://ibb.co/bg4NJ53)
Voici le retour d'un tcpdump de l'interface WAN :
root@gorgon:~ # tcpdump -li igb0_vlan100 igmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on igb0_vlan100, link-type EN10MB (Ethernet), capture size 262144 bytes
20:16:39.571058 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
20:18:44.559037 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
20:20:49.546974 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
20:22:54.535672 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
Pourtant je vois bien arriver les requêtes côté LAN, donc à priori pas de souci au niveau de mon switch :
root@gorgon:~ # tcpdump -li lagg0_vlan20 igmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on lagg0_vlan20, link-type EN10MB (Ethernet), capture size 262144 bytes
20:24:31.510217 IP BouygtelTV-271011536111361 > 239.255.3.22: igmp v2 report 239.255.3.22
20:24:32.390169 IP BouygtelTV-271011536111361 > 239.255.255.250: igmp v2 report 239.255.255.250
20:24:36.880556 IP gorgon > all-systems.mcast.net: igmp query v2
20:24:36.884924 IP BouygtelTV-271011536111361 > 232.0.64.211: igmp v2 report 232.0.64.211
20:24:38.760386 IP BouygtelTV-271011536111361 > 239.255.255.250: igmp v2 report 239.255.255.250
20:24:41.400919 IP BouygtelTV-271011536111361 > 239.255.3.22: igmp v2 report 239.255.3.22
20:24:42.920940 IP gorgon > all-systems.mcast.net: igmp query v2
20:24:43.620302 IP BouygtelTV-271011536111361 > 239.255.255.250: igmp v2 report 239.255.255.250
20:24:45.935364 IP BouygtelTV-271011536111361 > all-routers.mcast.net: igmp leave 232.0.64.211
20:24:46.950855 IP BouygtelTV-271011536111361 > 239.255.3.22: igmp v2 report 239.255.3.22
20:24:48.924068 IP gorgon > all-systems.mcast.net: igmp query v2
20:24:49.334811 IP BouygtelTV-271011536111361 > 232.0.31.62: igmp v2 report 232.0.31.62
^C
12 packets captured
2681 packets received by filter
0 packets dropped by kernel
J'ai également tenté le lancement à part de igmpproxy en debug mais rien de plus parlant :
root@gorgon:~ # /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.
Config: Got a phyint token.
Config: IF: Config for interface igb0_vlan100.
Config: IF: Got upstream token.
Config: IF: Got ratelimit token '0'.
Config: IF: Got threshold token '1'.
Config: IF: Got altnet token 193.251.97.0/24.
Config: IF: Altnet: Parsed altnet to 193.251.97/24.
Config: IF: Got altnet token 176.165.8.0/24.
Config: IF: Altnet: Parsed altnet to 176.165.8/24.
Config: IF: Got altnet token 89.86.97.0/24.
Config: IF: Altnet: Parsed altnet to 89.86.97/24.
Config: IF: Got altnet token 89.86.96.0/24.
Config: IF: Altnet: Parsed altnet to 89.86.96/24.
IF name : igb0_vlan100
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 1
Allowednet ptr : 42a010
Config: Got a phyint token.
Config: IF: Config for interface lagg0_vlan20.
Config: IF: Got downstream token.
Config: IF: Got ratelimit token '0'.
Config: IF: Got threshold token '1'.
IF name : lagg0_vlan20
Next ptr : 0
Ratelimit : 0
Threshold : 1
State : 2
Allowednet ptr : 0
[...]
buildIfVc: Interface lo0 Addr: 127.0.0.1, Flags: 0xffff8049, Network: 127/8
buildIfVc: Interface igb0_vlan100 Addr: 176.159.xxx.xxx, Flags: 0xffff8943, Network: 176.159.xxx/20
buildIfVc: Interface lagg0_vlan20 Addr: 10.42.20.254, Flags: 0xffff8843, Network: 10.42.20/24
Found config for igb0_vlan100
Found config for lagg0_vlan20
Found upstrem IF #0, will assing as upstream Vif 22
adding VIF, Ix 0 Fl 0x0 IP 0x43a29fb0 igb0_vlan100, Threshold: 1, Ratelimit: 0
Network for [igb0_vlan100] : 176.159.xxx/20
Network for [igb0_vlan100] : 193.251.97/24
Network for [igb0_vlan100] : 176.165.8/24
Network for [igb0_vlan100] : 89.86.97/24
Network for [igb0_vlan100] : 89.86.96/24
adding VIF, Ix 1 Fl 0x0 IP 0xfe142a0a lagg0_vlan20, Threshold: 1, Ratelimit: 0
Network for [lagg0_vlan20] : 10.42.20/24
Got 262144 byte buffer size in 0 iterations
Joining all-routers group 224.0.0.2 on vif 10.42.20.254
joinMcGroup: 224.0.0.2 on lagg0_vlan20
Joining all igmpv3 multicast routers group 224.0.0.22 on vif 10.42.20.254
joinMcGroup: 224.0.0.22 on lagg0_vlan20
SENT Membership query from 10.42.20.254 to 224.0.0.1
Sent membership query from 10.42.20.254 to 224.0.0.1. Delay: 10
Created timeout 1 (#0) - delay 10 secs
(Id:1, Time:10)
Created timeout 2 (#1) - delay 21 secs
(Id:1, Time:10)
(Id:2, Time:21)
About to call timeout 1 (#0)
Aging routes in table.
Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 2 (#0)
SENT Membership query from 10.42.20.254 to 224.0.0.1
Sent membership query from 10.42.20.254 to 224.0.0.1. Delay: 10
Created timeout 3 (#0) - delay 10 secs
(Id:3, Time:10)
Created timeout 4 (#1) - delay 21 secs
(Id:3, Time:10)
(Id:4, Time:21)
About to call timeout 3 (#0)
Aging routes in table.
Current routing table (Age active routes):
-----------------------------------------------------
No routes in table...
-----------------------------------------------------
About to call timeout 4 (#0)
SENT Membership query from 10.42.20.254 to 224.0.0.1
Sent membership query from 10.42.20.254 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)
About to call timeout 5 (#0)
Aging routes in table.
J'imagine qu'il manque peut être quelque chose dans mes règles de filtrage côté LAN mais quoi ? J'ai tenté d'autoriser l'IGMP à destination de tout mais ça ne change rien...
Auriez-vous d'autres pistes à suivre ?
Merci d'avance :).
Edit : Le problème venait bien du "Allow options" sur la partie LAN... J'ai effectivement refait une règle autorisant l'IGMP en any/any sur le LAN, et le paramètre "Allow options" était bien là. Tout semble parfaitement fonctionner, aucun bug de zapping, et le flux tient plus de 5 minutes sur les quelques tests réalisés. Je n'ai pas testé la VOD mais tout est configuré pour que ça fonctionne normalement.
-
Il faut bien penser à positionner allowopts sur 1 sinon cela ne fonctionne pas.
Est-ce que les préfixes TV sont les bons pour toutes les chaînes ?
-
Oui c'était bien cela, j'ai rajouté un edit à mon premier post et tout est rentré dans l'ordre après avoir activé le "Allow options" côté LAN ;).
-
Oui c'était bien cela, j'ai rajouté un edit à mon premier post et tout est rentré dans l'ordre après avoir activé le "Allow options" côté LAN ;).
Possible de poster des captures d'écrans de ce fameux allow options svp car je trouve rien. Merci
-
(https://reho.st/https://screenshotscdn.firefoxusercontent.com/images/4ab3af4d-e704-4ef0-bb0d-a84a4b3a0e56.png)
-
ça marche! Merci beaucoup!
-
Salut,
J'ai un routeur pfsense qui tournait sans problème sur le vlan 100 depuis quelques mois.
Cependant depuis aujourd'hui 11h50 je n'ai plus d'IP publique. Quelqu'un subit-il quelque chose de similaire ?
ps je suis sur Paris 16.
-
Merci beaucoup ça fonctionne au oil .
Par contre avez vous réussi à récupérer lipv6 ?
Je suis opnsense et j’ai que lipv4 qui remonte ....
Merci
-
C'est simple, pas d'IPv6 en FTTH chez Bouygues.
La bbox fait bien un requête DHCPv6 (pensez à capturer le DUID, ça sera utile) sur la VLAN 100 mais c'est côté OLT que ça bloque.
ByTel proposera IPv6 avec un déploiement progressif fin 2019 ou début 2020.
-
Ah ok tout simplement ;)
Merci pour l’info, je viens de passer d’orange à Bouygues et je pensais que lipv6 était actif ;)
-
Mon infra est en place, quelqu'un s'est penché sur le coté Téléphone ? Je vais surement regarder de mon coté !
-
Nop :s
J’ai test de brancher bêtement la box (dhcp désactivé) sur mon routeur mais sans succès ....
-
J'avais décrit dans le topic épinglé une solution low cost:
la bbox est bonne poire et accepte de se connecter en local pour profiter du téléphone, il vous faut donc:
- un port libre sur votre routeur et la bbox connecté depuis son port WAN vers le routeur
- ledit port doit avoir une adresse IP (hors du LAN) non routable sur le VLAN 100
- un serveur dhcp qui écoute sur le vlan 100
- du forward IPv4
- des règles de firewall pour autoriser le trafic depuis la bbox vers la passerelle SIP Bouygues
Cela manque encore de tests, autres que "ça fonctionne chez moi".
-
Merci Mirtouf pour ces infos, je vais essayer ca :)
Par contre on connait la passerelle SIP et quel port elle utilise ?
-
Bouygues a plusieurs passerelles réparties sur ses pop en France, je me connecte sur asbcidf11.fai.bouygtel.net port 5060, c'est du SIP pur sucre correctement implèmenté.
Pour connaître la sienne il faut faire une capture.
-
Ah yes, merci encore :)
-
Messieurs, j'ai besoin de vos lumières.
J'ai changé mon p'tit boitier FW sous Opnsense ( remplacer par un qotom )
Tout a été remis en place, la miami démarre nickel mais le flux TV ne passe pas pour certaine chaine, par exemple W9 fonctionne mais pas C8 ....
J'ai fait le tour, bogon desactivé, Allow IP activé, aucun blocage UDP dans les log quand je vais sur C8 par exemple, je sèche ..
Peut-être des préfixes manquant ?
Netstat => IPv4 Multicast Forwarding Table is empty
tcpdump :
listening on igb0_vlan100, link-type EN10MB (Ethernet), capture size 262144 bytes
14:55:46.856039 IP i19-lef01-t2-62-e-e-e.ft.lns.abo.bbox.fr > 232.0.31.28: igmp v2 report 232.0.31.28
14:55:55.938774 IP i19-lef01-t2-62-e-e-e.ft.lns.abo.bbox.fr > all-routers.mcast.net: igmp leave 232.0.31.28
14:55:56.346083 IP i19-lef01-t2-62-e-e-e.ft.lns.abo.bbox.fr > 232.0.31.50: igmp v2 report 232.0.31.50
14:56:05.408454 IP i19-lef01-t2-62-e-e-e.ft.lns.abo.bbox.fr > all-routers.mcast.net: igmp leave 232.0.31.50
Pas de soucis coté Replay et VOD, tout est fonctionnel
EDIT : Apres un petit tour rapide des chaines, il y a que les chaines du groupe canal qui ne remontent pas ..
-
huh ?
une panne locale ?
Testé hier, j'avais les chaînes C+ comme toutes les autres. As-tu la chaîne 104 arrivée récemment ?
-
Yes j'ai bien la 104, il y a que la 8 et la 4 qui passe pas .... Bizarre ....
-
C'est étrange.
Est-ce un problème de route (table de routage non mise à jour) ou un problème de flux qui n'arrive pas (bloqué par le fw, autre) ?
-
L'analyse réseaux c'est pas mon dada lol ....
Mais quand je mets la 8 ou la 4 j'ai aucun flux de bloqué
Dans les routes opnsense j'ai les entré vpn, 2 adresse en 62.x.x.x (mon ip public vers lo0, l'autre vers mon igb0_vlan100) et 2 adresse en 194.x.x.x vers igb0_vlan 100
Je serais incapable de te dire si il en manque :s
-
Je parle du résultat des commandes:
netstat -g
ifmcstat
qui permettent de voir si la table est correctement renseignée.
Il faut aussi voir des éventuels flux UDP bloqués.
-
Aucun flux UDP bloqué j'ai laisser tourné 3 bonne minutes et tout est au vert ...
netstat -g ( j'etais sur la 8 )
IPv4 Virtual Interface Table
Vif Thresh Local-Address Remote-Address Pkts-In Pkts-Out
0 1 10.0.0.1 0 105398
1 1 62.x.x.x 105398 0
IPv4 Multicast Forwarding Table
Origin Group Packets In-Vif Out-Vifs:Ttls
89.86.97.6 232.0.64.201 95415 1 0:1
193.251.97.227 232.0.31.50 0 65535
ifmcstat
igb0:
inet6 fe80::xxxx:xxxx:xxxx:xxxx%igb0 scopeid 0x1
mldv2 flags=2<USEALLOW> rv 2 qi 125 qri 10 uri 3
group ff01::1%igb0 scopeid 0x1 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group ff02::2:xxxx:xxxx%igb0 scopeid 0x1 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group ff02::2:xxxx:xxxx%igb0 scopeid 0x1 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group ff02::1%igb0 scopeid 0x1 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group ff02::1:ixxxx:xxxx%gb0 scopeid 0x1 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
igb1:
inet 10.0.0.1
igmpv2
group 224.0.0.22 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group 224.0.0.2 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group 224.0.0.1 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
inet6 fe80::xxxx:xxxx:xxxx:xxxx%igb1 scopeid 0x2
mldv2 flags=2<USEALLOW> rv 2 qi 125 qri 10 uri 3
group ff01::1%igb1 scopeid 0x2 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group ff02::2:xxxx:xxxx%igb1 scopeid 0x2 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group ff02::2:xxxx:xxxx%igb1 scopeid 0x2 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group ff02::1%igb1 scopeid 0x2 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group ff02::1:xxxx:xxxx%igb1 scopeid 0x2 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
igb0_vlan100:
inet 62.x.x.x
igmpv2
group 224.0.0.252 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group 224.0.0.251 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group 239.0.0.250 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group 239.255.3.22 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group 224.0.0.1 mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
inet6 fe80::xxxx:xxxx:xxxx:xxxx%igb0_vlan100 scopeid 0xc
mldv2 flags=2<USEALLOW> rv 2 qi 125 qri 10 uri 3
group ff01::1%igb0_vlan100 scopeid 0xc mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group ff02::2:xxxx:xxxx%igb0_vlan100 scopeid 0xc mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group ff02::2:xxxx:xxxx%igb0_vlan100 scopeid 0xc mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group ff02::1%igb0_vlan100 scopeid 0xc mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
group ff02::1:xxxx:xxxx%igb0_vlan100 scopeid 0xc mode exclude
mcast-macaddr xx:xx:xx:xx:xx:xx
-
Tu as un abonnement à un autre flux en cours, je ne sais pas quel en est l'origine mais il faut investiguer car il te manque ceci sur igb0_100 :
group 232.0.31.50 mode exclude
mcast-macaddr 01:00:5e:00:1f:32
Chez moi:
netstat -g
IPv4 Virtual Interface Table
Vif Thresh Local-Address Remote-Address Pkts-In Pkts-Out
0 1 192.168.1.1 0 449295
1 1 176.133.x.y 449295 0
IPv4 Multicast Forwarding Table
Origin Group Packets In-Vif Out-Vifs:Ttls
193.251.97.227 232.0.31.50 354988 1 0:1
IPv6 Multicast Interface Table is empty
IPv6 Multicast Forwarding Table is empty
ifmcstat
igb1:
inet 192.168.1.1
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.251 mode exclude
mcast-macaddr 01:00:5e:00:00:fb
group 239.255.255.250 mode exclude
mcast-macaddr 01:00:5e:7f:ff:fa
group 224.0.0.1 mode exclude
mcast-macaddr 01:00:5e:00:00:01
inet6 fe80::290:87ff:fee0:193%igb1 scopeid 0x2
mldv2 flags=2<USEALLOW> rv 2 qi 125 qri 10 uri 3
group ff01::1%igb1 scopeid 0x2 mode exclude
mcast-macaddr 33:33:00:00:00:01
group ff02::2:1861:20ce%igb1 scopeid 0x2 mode exclude
mcast-macaddr 33:33:18:61:20:ce
group ff02::2:ff18:6120%igb1 scopeid 0x2 mode exclude
mcast-macaddr 33:33:ff:18:61:20
group ff02::1%igb1 scopeid 0x2 mode exclude
mcast-macaddr 33:33:00:00:00:01
group ff02::1:ffe0:193%igb1 scopeid 0x2 mode exclude
mcast-macaddr 33:33:ff:e0:01:93
lo0:
inet6 fe80::1%lo0 scopeid 0x6
mldv2 flags=2<USEALLOW> rv 2 qi 125 qri 10 uri 3
group ff01::1%lo0 scopeid 0x6 mode exclude
group ff02::2:1861:20ce%lo0 scopeid 0x6 mode exclude
group ff02::2:ff18:6120%lo0 scopeid 0x6 mode exclude
group ff02::1%lo0 scopeid 0x6 mode exclude
group ff02::1:ff00:1%lo0 scopeid 0x6 mode exclude
igb0.100:
inet 176.133.x.y
igmpv2
group 224.0.0.251 mode exclude
mcast-macaddr 01:00:5e:00:00:fb
group 232.0.31.50 mode exclude
mcast-macaddr 01:00:5e:00:1f:32
group 239.255.3.22 mode exclude
mcast-macaddr 01:00:5e:7f:03:16
group 224.0.0.252 mode exclude
mcast-macaddr 01:00:5e:00:00:fc
group 224.0.0.1 mode exclude
mcast-macaddr 01:00:5e:00:00:01
inet6 fe80::290:87ff:fee0:192%igb0.100 scopeid 0x9
mldv2 flags=2<USEALLOW> rv 2 qi 125 qri 10 uri 3
group ff01::1%igb0.100 scopeid 0x9 mode exclude
mcast-macaddr 33:33:00:00:00:01
group ff02::2:1861:20ce%igb0.100 scopeid 0x9 mode exclude
mcast-macaddr 33:33:18:61:20:ce
group ff02::2:ff18:6120%igb0.100 scopeid 0x9 mode exclude
mcast-macaddr 33:33:ff:18:61:20
group ff02::1%igb0.100 scopeid 0x9 mode exclude
mcast-macaddr 33:33:00:00:00:01
group ff02::1:ffe0:192%igb0.100 scopeid 0x9 mode exclude
mcast-macaddr 33:33:ff:e0:01:92
-
Après avoir refait le tour, la seule chose qui "pouvait" etre en cause etait le VLAN, j'ai forcer le P6 direct dessus( je sais pas si impact ), je l'ai remis par défaut (0 )
j'ai bien ca sur la 8 :
igb0_vlan100:
inet 62.x.x.x
igmpv2
group 232.0.31.50 mode exclude
mcast-macaddr 01:00:5e:00:1f:32
group 224.0.0.251 mode exclude
mcast-macaddr 01:00:5e:00:00:fb
group 239.255.3.22 mode exclude
mcast-macaddr 01:00:5e:7f:03:16
group 224.0.0.252 mode exclude
mcast-macaddr 01:00:5e:00:00:fc
group 224.0.0.1 mode exclude
mcast-macaddr 01:00:5e:00:00:01
IPv4 Virtual Interface Table
Vif Thresh Local-Address Remote-Address Pkts-In Pkts-Out
0 1 10.0.0.1 0 69408
1 1 62.x.x.x 69408 0
IPv4 Multicast Forwarding Table is empty
IPv6 Multicast Interface Table is empty
IPv6 Multicast Forwarding Table is empty
Mais toujours le problème de réception sur la chaine ...
Pas grave je regarderait depuis la tnt :)
Je sais pas analyser
Merci d'avoir pris le temps :)
-
Vérifie de nouveau le pare-feu.
Quel est le configuration de igmpproxy ?
-
Je vois rien, tout est au vert coté UDP
j'ai aucune règle sur le FW sauf celle pour faire fonctionner la télé et une pour le VPN.
Coté NAT j'ai 3 redirection de port pour mon serveur perso.
IGMP Proxy up
Name Type Values Description
WAN upstream 193.251.197.0/24, 176.165.8.0/24, 89.86.97.0/24, 89.86.96.0/24
LAN downstream
Par contre depuis le LAN vers l’extérieur j'ai pas mal de blocage sur l'adresse de la miami (en TCP)
EDIT: un blocage UDP mais en IPV6 sur le port 5353, mais rien a voir a mon avis car pas d'ipv6
LAN => Jun 30 17:25:31 [fe80::xxxx:xxxx:xxxx:xxxx]:5353 [ff02::fb]:5353 UDP Default deny rule
Au bout de quelques minutes je perds le group
group 232.0.31.50 mode exclude
mcast-macaddr 01:00:5e:00:1f:32
igb0_vlan100:
inet 62.x.x.x.x
igmpv2
group 239.255.3.22 mode exclude
mcast-macaddr 01:00:5e:7f:03:16
group 224.0.0.251 mode exclude
mcast-macaddr 01:00:5e:00:00:fb
group 224.0.0.252 mode exclude
mcast-macaddr 01:00:5e:00:00:fc
group 224.0.0.1 mode exclude
mcast-macaddr 01:00:5e:00:00:01
-
tcpdump depuis la 8
listening on igb0_vlan100, link-type EN10MB (Ethernet), capture size 262144 byte s
18:07:33.434752 IP OPNsense > 232.0.31.50: igmp v2 report 232.0.31.50
18:07:42.502470 IP OPNsensei > all-routers.mcast.net: igmp leave 232.0.31.50
18:07:57.629606 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
18:07:57.629662 IP OPNsense > 224.0.0.252: igmp v2 report 224.0.0.252
18:08:05.574616 IP OPNsense > 224.0.0.251: igmp v2 report 224.0.0.251
18:08:07.874617 IP OPNsense > 239.255.3.22: igmp v2 report 239.255.3.22
Ah !!
Log igmp :
Jun 30 18:09:52 igmpproxy[85726]: The source address 193.251.97.227 for group 232.0.31.50, is not in any valid net for upstream VIF[0].
MCM, Gulli, cstar meme combat :s
-
Donc voila, apres avoir fait :
root@OPNsense:/usr/local/etc # igmpproxy -d igmpproxy.conf
Et en allant sur une des chaines qui passaient pas
J'ai donc eu ça :
The source address 193.251.97.227 for group 232.0.31.50, is not in any valid net for upstream VIF[0].
The source address 193.251.97.227 for group 232.0.31.50, is not in any valid net for upstream VIF[0].
The source address 193.251.97.227 for group 232.0.31.50, is not in any valid net for upstream VIF[0].
The source address 193.251.97.227 for group 232.0.31.50, is not in any valid net for upstream VIF[0].
The source address 193.251.97.227 for group 232.0.31.50, is not in any valid net for upstream VIF[0].
The source address 193.251.97.227 for group 232.0.31.50, is not in any valid net for upstream VIF[0].
The source address 193.251.97.227 for group 232.0.31.50, is not in any valid net for upstream VIF[0].
Du coup j'ai rajouter l'ip dans l'upstream
Name Type Values Description
WAN upstream 193.251.197.0/24, 176.165.8.0/24, 89.86.97.0/24, 89.86.96.0/24, 193.251.97.227/32
LAN downstream 10.0.0.0/24
C'est passé instantanèment.
Merci Mirtouf pour le coup de main :)
-
Erreur de syntaxe, 193.251.197.0/24 n'a jamais été vu au contraire de 193.251.97.0/24.
-
Oui j’avais pas voulu dire que j’avais louché..... lol
Mais si on doit désigner un coupable, je dirais que c’est l’apéro ! ;)
-
Ola !
Mirtouf désolé encore mais :)
J'ai suivi les detaiuls pour le TEL et ca fonctionne a merveille en appel sortant....
Des que j'appel sur mon fixe, BOUM messagerie ...
Si as tout hasard tu as une idée ....
Merci ...
-
Aucune idée, s'il n'y a pas une redirection vers un numéro de téléphone, il faut une capture.
-
Pour capture ça, ça devrait le faire ?
tcpdump -st -s 0 -A -i igb2_vlan100 port 5060
Igb2 étant le 3 eme pour ou j’ai brancher la bbox
Car ça me sort rien, ça attend mais rien ne passe visiblement :s
-
Oui, pas mal.
-
Hello ,
Bon j’avais prévu de look un peu ce qu’il ce passe mais il s’avère que ça fonctionne....
La messagerie venait peut être dû soucis ou je ne sais quoi venant de Bouygues (ou pas)
Toujours est-il que ça fonctionne ....
Merci encore Mirtouf pour les toutes infos :)
-
Bonjour à tous,
Merci pour ce tuto !
Quelqu'un aurait-il la bonne configuration pour pimd ?
J'en profite pour vous donner ma méthode pour la VoIP (appels entrants et sortants OK) :
- J'utilise une interface dédiée sur mon routeur (APU4D4 + pfsense 2.4.5)
- J'assigne le VLAN100
- Je fixe une IP /24
- J'active un serveur DHCP (pensez à push les DNS Bouygues)
- J'autorise le traffic sur cette interface
- Branchez le port WAN de la Bbox sur l'interface dédiée
- La Bbox récupère une IP dans le /24 que vous avez configuré
- Normalement les appels sortants fonctionnent
- Pour les appels entrants, vous devez connaitre l'adresse IP du serveur VoIP
- Essayez d'appeler votre numéro avec votre mobile
- Vous tombez direct sur le répondeur
- Allez dans les logs du pare-feu
- Filtrez avec comme port source 5060
- Vous devriez avoir l'IP du serveur VoIP
- Un conseil, transformez cette IP /32 en réseau /24. Il arrive que l'adresse du serveur change mais elle sont toutes dans le même subnet
- Créez une règle NAT pour rediriger ce /24 vers l' IP de la Bbox (source ports 5060 (réseau /24), destination port 5060 (WAN adresse), redirection port 5060(BBox IP attribuée avec votre DHCP))
- Normalement c'est bon :)
Je vous remercie d'avance pour vos retours !
-
Pour pimd, je n'ai jamais réussi mais selon toute vraisemblance, il n'est pas fait pour cela.
Demain, je vais m'intéresser à ce que fait l'ONT (est-ce son IGMP snooping le problème ?).
Pour la téléphonie, c'est exactement ce qu'il faut faire. ;)
-
Bonjour Mirtouf,
Réponse très rapide ^^
pimd est maintenant disponible dans les "Available Packages"
On peut forcer l'IGMPv2, qui semble être la problématique pour IGMP Proxy ?
Saurais-tu nous expliquer le paramètre "RP Adresses" ?
Voici ma conf : /var/etc/pimd/pimd.conf
igmp-query-interval 12
igmp-querier-timeout 42
spt-threshold packets 0 interval 100
phyint igb0.100 enable igmpv2
phyint igb3 enable igmpv2
bsr-candidate priority 5
rp-candidate priority 20 time 30
PS : PIMD Multicast Routing. Lightweight, stand-alone implementation of Protocol Independent Multicast-Sparse Mode. Conflicts with Quagga OSPF. These packages cannot be installed at the same time.
-
Je n'ai aucune idée sur la configuration. J'avais compris que pimd était utilisé quand il fallait ajouter des routes multicast ce qui n'est pas le cas pour notre application.
Je peux uniquement dire qu'il faut forcer l'IGMPv2.
Je me sers uniquement de pimd comme une solution q&d pour réussir à utiliser igmpproxy.
Si tu maîtrises pimd, tu seras un héros. :)
-
Bonjour à tous,
Voici mes recherches :
Dans la configuration avancée "System Tunables" j'ai essayé d'ajouter :
net.inet.igmp.default_version=2
net.inet.igmp.sendra=0
net.inet.igmp.legacysup=1
Cela ne change rien
https://forum.netgate.com/topic/109715/change-carp-igmpv3-v2/2
https://forum.lissyara.su/viewtopic.php?f=4&t=35261
idem nada
j'ai tenté d'installer la version 0.1_5 qui (si je ne me trompe pas) ne supporte pas l'igmpv3
pkg add -f https://firmware.netgate.com/pkg/pfSense_factory-v2_4_3_amd64-pfSense_factory-v2_4_3/All/igmpproxy-0.1_5%2C1.txz
idem nada
sur la doc igmpproxy
https://www.freebsd.org/cgi/man.cgi?query=igmpproxy&apropos=0&sektion=0&manpath=FreeBSD+11.3-RELEASE+and+Ports&arch=default&format=html
/proc/sys/net/ipv4/conf/<ifname>/force_igmp_version
- can be set to control what IGMP version the kernel should use
on the upstream interface. Ex.: 'echo 2 >
/proc/sys/net/ipv4/conf/eth0/force_igmp_version' will force the
kernel to use IGMPv2 on eth0 (provided this is the upstream in-
terface).
quelqu'un aurait un equivalent pour pfsense ?
Merci d'avance ;)
-
C'est pourquoi je bidouille avec pimd pour réussir à faire fonctionner le proxy igmp.
-
Bonjour,
Quelqu'un aurait-il essayé avec OpenWRT ?
L'option : net.ipv4.conf.all.force_igmp_version=2 fonctionne mais je n'ai toujours pas de flux UDP :(
-
Bonjour,
J'essaye de remplacer la bbox par un routeur pfsense, internet fonctionne mais je n'arrive pas à faire fonctionner la TV.
J'ai bien les info sur le programme qui s'affiche quand je change de chaine mais pas de flux TV, j'ai une erreur F3411.
Le boitier TV est une miami 4K, branché sur un switch puis sur le pfsense, avec un bail DHCP static et les DNS bouygues (194.158.122.10 & 194.158.122.15).
J'ai d'abord essayé la config proposé dans le premier poste mais sans sucés. J'ai suis donc passé sur une config beaucoup moins restrictive pour essayer de faire fonctionner la TV.
J'ai une règles flottante qui autorise tout les protocoles dans toutes les directions (et any sources / any destinations) avec "allow options" appliqué sur toutes mes interfaces (images rule1.png & rule2.png en pièce jointe).
J'ai activé le proxy IGMP mais je n'ai mis aucun filtre de sous réseau en entrée (image igmp.png en pièce jointe).
Je reçoit bien les annonces IGMP au niveau de pfsense :
tcpdump -li igb0.100 igmp :
22:38:45.949762 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
22:39:33.393544 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > all-systems.mcast.net: igmp query v2
22:39:35.299424 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > pim-routers.mcast.net: igmp v2 report pim-routers.mcast.net
22:39:37.816642 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp v2 report all-routers.mcast.net
22:39:42.050409 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > igmp.mcast.net: igmp v2 report igmp.mcast.net
22:39:46.045450 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave all-routers.mcast.net
22:39:46.045671 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave igmp.mcast.net
22:39:46.045851 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave pim-routers.mcast.net
22:40:25.419908 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
22:40:27.211914 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > 225.0.71.1: igmp v2 report 225.0.71.1
22:40:31.052024 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > 239.255.3.22: igmp v2 report 239.255.3.22
22:40:35.852193 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > 232.0.64.201: igmp v2 report 232.0.64.201
22:40:44.898635 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > all-routers.mcast.net: igmp leave 232.0.64.201
22:40:45.402312 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > 232.0.64.202: igmp v2 report 232.0.64.202
22:40:50.939227 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
22:40:52.433345 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > 232.0.64.202: igmp v2 report 232.0.64.202
22:40:55.833915 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > 239.255.3.22: igmp v2 report 239.255.3.22
22:40:57.633328 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > 224.0.0.251: igmp v2 report 224.0.0.251
22:40:59.833725 IP sou06-h03-89-88-181-122.dsl.sta.abo.bbox.fr > 225.0.71.1: igmp v2 report 225.0.71.1
netstat -g :
IPv4 Virtual Interface Table
Vif Thresh Local-Address Remote-Address Pkts-In Pkts-Out
0 1 10.0.0.1 0 0
1 1 @PUBLICIP 0 0
IPv4 Multicast Forwarding Table
Origin Group Packets In-Vif Out-Vifs:Ttls
89.86.97.6 232.0.64.202 0 65535
IPv6 Multicast Interface Table is empty
IPv6 Multicast Forwarding Table is empty
Es que l'un d'entre vous aurais une idée de ce que je n'ai pas configuré correctement ?
-
Si je comprends bien, la Miami est sur un port réseau dédié.
Il faut vérifier:
- pas de blocage des bogons IPv4
- autorisation du trafic UDP vers 224.0.0.0/4 et du trafic IGMP
- "IP options" activé
Ensuite, il faut regarder les paquets bloqués par le fw.
-
La miami n'est pas directement branché sur un port dédié, il y a un switch avec d'autre équipements branché dessus. Mais cette configuration ne pose aucun problème quand j'utilise la bbox à la place du pfsense.
BBOX/PFSENSE ====> SW =====> MIAMI
Quand je regarde les logs du firewall, je vois que les paquets depuis le 224.0.0.0/4 ne sont pas bloqués.
L'"IP option" est bien activé dans la règle de firewall pfsense, c'est possible que le switch pose un problème a ce niveau ?
Je vais essayer de brancher la miami directement au pfsense pour voir si le switch pose un problème.
-
A quoi correspond l'interface OPT1 ?
-
OPT1 est l'interface sur laquelle est branché le switch avec la miami (c'est enfaite mon lan).
L'interface LAN est un autre subnet qui m'a servi à faire la première configuration de pfsense, il n'y a rien de branché dessus.
-
Je précise que j'ai bien désactivé la protection contre les bogons et les adresse ip privées sur toutes les interfaces.
J'ai aussi essayé la manip avec pimd mais pas plus de succès de ce coté la non plus.
-
Hello les fibrés ;)
Je vois pas mal de galère côté TV, on ne peu aujourd’hui plus en bénéficier avec un pfsense/opnsense aussi facilement qu’avant ?
Suite à déménagement je repasse chez bouygue abo Avec la box standard (pas la nouvelle), et je comptais remettre mon routeur.
Merci.
-
Plusieurs choses à vérifier:
- avoir la dernière version d'IgmpProxy
- être en mesure de marquer p3 les paquets IGMP en sortie
- avoir des règles autorisant le trafic multicast en entrée (UDP + IGMP)
et malgré cela avec pfSense, j'étais obligé d'utiliser un script qui lançait pimd, le tuait puis relançait igmpproxy.
Bref, à tester.
-
Bonjour,
Pour commencer merci.
En suivant ce tutoriel , j'ai réussi à configurer mon routeur OPNsense correctement, la TV et internet fonctionne correctement.
Ma config :
OPNsense 21.1
wan => vlan100 avec p6, spoof mac BBOX, dhcp-class-identier "BYGTELIAD"
BOX _TV => vlan60, spoof mac BBOX (apparemment inutile pour fonctionner)
proxy IGMP en v2 fonctionnel
Upnp fonctionnelle (je crois loll) WAN vers BOX_TV avec allow 1024-65535 192.168.60.0/24 1024-65535, et deny 0-65535 0.0.0.0/4 0-65535.
firewall :
régle configurer en flottante :
IGMP en p3 in/out
ICMP en p3 in/out
UPD pour TV_prefixe in/out
UPD pour VOD_replay in/out
regle de BOX_TV :
ipv4 tout autorisé en in
NAT :
VOD rediriger vers la miami
pas eu besoin de l'astuce avec pimd.
réglages persistants (redémarrage miami => TV toujours OK, redémarrage routeur => TV+INTERNET toujours OK, redémarrage miami + routeur => TV+internet toujours OK).
Je me doute que j'ai encore beaucoup à apprendre mais Il me reste cependant quelques questions.
Pour les règles sur l'interface BOX_TV je voudrais être plus restrictif mais grosse galère, loool
Pour ICMP, je voudrais aussi être plus sélectif, ça m’inquiète d'avoir ce protocole totalement ouvert sur l'interface WAN
De plus pour les règles flottantes, j'ai du mettre les mettre toutes en in/out et aussi insérer deux regles pour le DNS sinon la tv ne fonctionner pas ....
Pour finir j'ai "reset" la miami mais elle bloque à la tentative d'authentification, je peux rebrancher la bbox pour cette étape bien entendu mais n'y a-t-il pas une autre solution?
J'ai encore d'autres questions mais j’arrête la! (j'aime comprendre ce que je fais lool)
Cordialement
Clyds
-
Bonjour à tous,
J'aimerais mettre ma Bbox 4K derrière mon pfSense, le hic c'est que j'ai la BBox F@st 5688b (la fameuse Wifi 6 sans ONT séparé) de ce fait j'ai tout de même tenté le tuto sauf la première partie avec le VLAN 100 et l'ONT qui ne s'applique pas dans mon cas mais sans succès.
Est ce encore possible ou dois je simplement me faire une raison ?
Actuellement mon pfSense est hébergé dans une VM sur mon ESXi avec une carte réseau dédié au WAN sur laquelle la Bbox est branchée (configurée en DMZ avec l'@IP WAN de mon pfSense) et une carte réseau dédiée au LAN qui repart sur un switch et qui distribue au reste de mes équipements.
Merci pour l'aide que vous pourrez m'apporter :)
-
Bonjour,
Après pas mal de test j'ai réussi à avoir le flux TV, mais...^^
Exit pfsense pour Debian + igmpproxy avec v2 forcé.
La miami récupère bien le flux malheureusement ce n'est pas stable, je perds le flux au bout d'un certain temps (aléatoire ~5-10min).
J'ai fini par me procurer une AppleTV d'occas et installer l'application B.Tv
Cela fonctionne nickel, j'accède à toutes les chaînes de mon forfait.
-
Il faut forcer le marquage p3 (floating rules) des trames IGMP en sortie si cela coupe au bout de 5 minutes.
-
Bonjour à tous,
Je suis en train de migré d'un edgerouter vers pfsense et c'est pas simple...
J'ai tout suivi et refais 4x le tour, mais rien n'y fait, la TV ça ne veut pas.
Le seul truc d'un peu différent dans les différents messages par rapport au tuto c'est ça:
De plus pour les règles flottantes, j'ai du mettre les mettre toutes en in/out et aussi insérer deux regles pour le DNS sinon la tv ne fonctionner pas ....
Par contre je ne vois pas comment faire.
Le seul message que j'ai quand je fais le tcpdump, c'est ça:
00:16:58.822164 IP 0.0.0.0 > all-systems.mcast.net: igmp query v2
Merci pour vos pistes :)
-
réglages persistants (redémarrage miami => TV toujours OK, redémarrage routeur => TV+INTERNET toujours OK, redémarrage miami + routeur => TV+internet toujours OK).
...
Pour finir j'ai "reset" la miami mais elle bloque à la tentative d'authentification, je peux rebrancher la bbox pour cette étape bien entendu mais n'y a-t-il pas une autre solution?
...
Clyds
Bonjour Clyds :)
Tu sembles avoir réussi mais la fin de ton post indique le contraire... Je suis aussi sur Opnsense et je me demande si finalement c'est toujours d'actualité d'avoir la TV (IPTV HD et non le mode streaming)...
Bien à toi.
-
Salut,
J'utilise toujours les réglages, tout fonctionne même l'installation de la Box TV (installation de la box TV à correctement fonctionné 2 jours après alors que j'ai rien changé)!
Cordialement.
-
Bonjour,
Je viens de suivre la configuration.
Je n’ai aucun problème avec la partie Télévision par contre pour la partie REPLAY cela fonctionne à moitié.
Le REPLAY sur TF1 pas de problème et par exemple NRJ12 j'ai un code erreur C306-5 des que je lance un programme.
Cela provient-il de ma configuration à votre avis ?
Merci d'avance.
-
Bonjour,
est-ce que quelqu'un a réussi à appliquer ces paramètres à un routeur Asus ?
Je suis directement connecté à l'ONT avec un routeur Asus RT-AC86U mais je n'ai pas de télé et de téléphonie.
Merci
-
Je suis avec un routeur Asus aussi mais je n'arrive pas non plus à configurer correctement la TV.
-
Bonjour,
Je bypass depuis plusieurs année la BBox router, tout fonctionne nickel (Internet IPv4/IPv6 + TV Miami). Plus tordu, je voudrais bypasser la STB Miami avec ma Shield pour la TV Live, j'ai vu que certains s'en étaient sortis avec l'application B.live (https://sites.google.com/view/fengmi-4k-memo/apks-replay) qui a servi à une Beta Android TV en 2020 (classée sans suite à priori).
Actuellement, j'arrive bien à récupérer la liste des chaines TV une fois mes identifiants saisis (surtout bien utiliser l'@bbox.fr). Par contre, aucun live, la Shield ne fait d'IGMP Join. A la place, j'ai pu capturer une séquence MDNS, l'appli chercher à résoudre Bboxapi._http._tcp.local. Bien sûr, comme je n'ai pas de BBox, cette API ne répond pas (et pas de réponse DNS non plus).
Est-ce que quelqu'un a déjà cherché à reproduire cette API (qui semble ouverte https://dev.bouyguestelecom.fr/) ?
-
Pour répondre directement à mon message sur l'autre topic concernant le VLAN 200 et l'ONT : https://lafibre.info/remplacer-bbox/informations-de-connexion-ftth/168/
"Je viens de me faire livrer la fibre Bouygues, la configuration a été ultra simple, rien à redire à ce sujet, la config d'internet, les doigts dans le nez.
Sauf que je galère sur la TV, et il n'y a effectivement QUE France 2 qui fonctionne aussi, les autres chaines, wallouh.
J'ai repris 18 fois la conf de mon pfSense en version 2.6.0 mais rien à faire, et j'étais deja chez Orange avant, tout fonctionnait parfaitement, je connaissais donc la technique de l'IGMP Proxy, etc."
J’ai au final un souci, seule la chaine 2 fonctionne, les autres me disent qu'il y a une erreur de signal.
J'ai regardé dans mes States mais je ne vois rien qui serait bloqué de moi.
Pour le moment, j'ai fait un "States reset" et j'ai reboot le pfSense, je vais voir tout à l'heure ce que ça donne.
pfSense CE en version 2.6.0 sur une china made Fanless PC avec des cartes Intel Gigabit.
EDIT : j'ai revérifié toute ma config hier en passant dans System Logs > Firewall.
J'ai fait pété les règles de filtrages, et je voyais bien une IP bloquée + l'IGMP bloqué.
En refaisant les règles correctement, plus de blocage, mais toujours que la 2 qui fonctionne.
Le VOD/Replay fonctionne parfaitement, et ce matin je vois que la 14 fonctionne aussi.
Je n'y comprends plus rien, et je n'arrive pas à vérifier l'IGMP en SSH comme vous le faites...
-
Bonjour,
Je sollicite un petit coup de main de la communauté pour me passer de la Bbox Fit (Fast5330b) en raccordant la prise RJ45 de l'ONT sur le port RJ45 (igb0) d'un routeur Pfsense (2.6.0)
Ce que j'ai cru comprendre :
Il faut configurer un VLAN :
Balise VLAN : 100
priorité VLAN 802.1Q : 6
Ensuite modifier l'interface WAN(igb0) comme suit :
Config Ipv4 : DHCP
config Ipv6 : aucun
Adresse mac : celle de la box (étiquette au dos)
MTU : 1500
je coche config avancée
et dans envoyer options j'ajoute : dhcp-class-identifier « bygteliad »
je laisse le reste par défaut et j'assigne le VLAN100 à l'Igb0(WAN), et à ce moment l'adresse mac devient grisée et impossible d'utiliser celle inscrite précédemment, ça redevient celle correspondant à l'Igb0 d'origine.
Une fois que j'aurai résolu de souci, y'a t'il une config différente à faire sur le Firewall et/ou NAT de Pfsense par rapport a l'actuelle ? (BBox sur WAN)
Idem pour resolveur dns, comment dois-je le configurer du coup ?
Pour le téléphone, si c'est possible/facile, je veux bien un coup de main aussi, sinon je verrais plus tard.
Pour info je ne souhaite pas configurer la TV (pas dispo dans mon offre)
D'avance merci de votre aide,
-
Bonjour,
je viens de m'enregistrer sur ce forum pour avoir un peu d'aide. J'essaie desespérement de permettre à PFSense d'accéder à internet, sans passer par la bbox.
J'ai installé PFSENSE Sur une VM proxmox, j'ai bien 2 cartes réseaux, deux "bridge Linux" sur Promow représentant chacun 1 carte.
J'ai relié une des cartes avec le boitier ONT et l'autre avec un routeur netgear pour mon réseau LAN.
Dans PFSense, j'ai bien créé un VLAN 100 associé au WAN, et renseigné les exactes même valeurs sur le WAN que dans la première image de ce post.
L'addresse MAC de la carte WAN a été forcée à l'adresse de la bbox et j'envoie bien "BYGTELIAD" dans le dhcp-class-identifier
Et pourtant je n'ai pas accès à internet, je vois dans le dashboard PFSense que IP du WAN(vnet0.100) est 0.0.0.0...
Je n'ai pas testé TV ou autres, étant intéressé pour le moment que pas le net.
Ci-dessous quelques screenshot qui pourraient vous aider à m'indiquer le soucis.
-
finalement j'y suis arrivé sans trop savoir ce qui se passe. J'ai refais la machine et refais paramétrage (pour la nième fois) et là, boum ca a marché. Bref j'ai fait un snapshot de la machine pour ne pas avoir à regalérer ;-)
-
Bonjour jejesh26,
Je vois que tu as réussi a obtenir une IP publique sur ton wan et il semble que nous soyons que 2 a utiliser pfsense sans box... ;)
Aurais tu la gentillesse de bien vouloir détailler la façon de forcer l'adresse mac sur le wan avec un vlan stp ? (Voir post précédent pour les détails)
Merci de ton aide,
-
Bonjour
@ForNet29,
en fait meme sans mettre la mac address j'arrive à avoir internet. Je n'ai pas testé la TV ou autres services.
Sinon, comme j'utilise PROMOX et que PFSense est une VM de PROMOX, c'est au moment de crééer la VM que j'initialise la MAC Address du bridge WAN avec la valeur de la BOX.
Je ne saisis rien directement dans PFSENSE.
Si tu veux le faire dans PFSENSE, il faut (de mémoire) saisir la MAC Address dans l'interface WAN AVANT de l'associer au VLAN100. Sinon la MAC Address est grisée.
Voila
Cdlt
-
Merci pour ta réponse,
malheureusement, c'est bien ce que j'ai tenté de faire, à plusieurs reprises, mais comme indiqué dans mon premier message, la case redevient grisée dès que j'assigne le VLAN !! :(
Et pas d'IP publique avec la MAC d'origine, j'ai du louper un truc qq part.
-
Hello,
Avec le spoof de l'adresse MAC, vous n'avez pas besoin d'attendre la fin de l'ancien lease.
Ou attendre 1h de souvenir.
-
Salut
Je viens de passer de Sosh à BBox
IPV4 impec
par contre j'aimerais obtenir une IPV6, il y a une config spécial à mettre en place ?
Ma Box obtient bien une ipv6
Jan 3 14:49:52 dhcp6c 12039 Sending Solicit
Jan 3 14:49:50 dhcp6c 12039 status code for NA-0: no addresses
Jan 3 14:49:50 dhcp6c 12039 dhcp6c Received REQUEST
Jan 3 14:49:50 dhcp6c 12039 Sending Request
Jan 3 14:49:49 dhcp6c 12039 Sending Solicit
Jan 3 14:49:47 dhcp6c 12039 status code for NA-0: no addresses
Jan 3 14:49:47 dhcp6c 12039 dhcp6c Received REQUEST
Jan 3 14:49:47 dhcp6c 12039 Sending Request
Jan 3 14:49:46 dhcp6c 12039 Sending Solicit
Jan 3 14:49:44 dhcp6c 12039 status code for NA-0: no addresses
Jan 3 14:49:44 dhcp6c 12039 add an address 2001:861:xxxx:xxxx:xxx:xxxx:xxxx:d15b/64 on re1
Jan 3 14:49:44 dhcp6c 12039 dhcp6c Received REQUEST
Jan 3 14:49:44 dhcp6c 12039 Sending Request
Jan 3 14:49:43 dhcp6c 12039 Sending Solicit
Jan 3 14:49:42 dhcp6c 11486 skip opening control port
Jan 3 14:49:42 dhcp6c 11486 failed initialize control message authentication
Jan 3 14:49:42 dhcp6c 11486 failed to open /usr/local/etc/dhcp6cctlkey: No such file or directory
depuis pfsense
ping6 google.fr
PING6(56=40+8+8 bytes) 2001:861:xxxx:xxxx:xxx:xxxx:fe1d:d15b --> 2a00:1450:4007:813::2003
16 bytes from 2a00:1450:4007:813::2003, icmp_seq=0 hlim=120 time=12.262 ms
16 bytes from 2a00:1450:4007:813::2003, icmp_seq=1 hlim=120 time=12.250 ms
16 bytes from 2a00:1450:4007:813::2003, icmp_seq=2 hlim=120 time=12.318 ms
16 bytes from 2a00:1450:4007:813::2003, icmp_seq=3 hlim=120 time=12.372 ms
16 bytes from 2a00:1450:4007:813::2003, icmp_seq=4 hlim=120 time=12.406 ms
mais rien depuis client
Merci
-
Ca fonctionne avec ces paramètres
-
J'ai finalement réussi à configurer l'IPv6 de Bouygues sur mon routeur Pfsense, après beaucoup de tâtonnement...
Pour faire simple, il semble que les serveurs DHCPv6 de Bouygues n'acceptent que les Requests DHCPv6 seulement avec l'option ia-pd (requête de délégation de préfix). Si on demande dans la même requête un préfixe et une adresse IPv6 pour l'interface WAN (le cas général) avec l'option ia-na (demande d'adresse IPv6) activé alors on reçoit une réponse DHCPv6 avec l'option NoAddressAvailable et sans préfix. Dans les faits les serveurs DHCPv6 de Bouygues sont configurés pour utiliser la rfc6603 (cf. ref[4] et cf. le texte de la rfc ci-dessous), autrement dit la délégation de préfixe avec l'option OPTION_PD_EXCLUDE. Cela implique que le routeur demandant un préfix est en charge d'assigner une adresse IPv6 à l'interface WAN. Exemple, lors d'un échange DHCPv6 suivant la rfc6603, si un routeur reçoit un préfix /60 avec l'option OPTION_PD_EXCLUDE et il doit réserver un /64 dans son /60 afin d'assigner une adresse IPv6 a son interface WAN.
RFC6603 Prefix Exclude Option for DHCPv6-based Prefix Delegation
"
This specification defines a new DHCPv6 option, OPTION_PD_EXCLUDE
(67), that is used to exclude exactly one prefix from a delegated
prefix. The OPTION_PD_EXCLUDE is included in the OPTION_IAPREFIX
IAprefix-options field. There can be at most one OPTION_PD_EXCLUDE
option in one OPTION_IAPREFIX option. The OPTION_PD_EXCLUDE option
allows prefix delegation where a requesting router is delegated a
prefix (e.g., /56) and the delegating router uses one prefix (e.g.,
/64) on the link through which it exchanges DHCPv6 messages with the
requesting router with a prefix out of the same delegated prefix set.
"
Pour résumer, afin d'obtenir un préfix IPv6 chez Bouygues voici ci-dessous la configuration a appliquer:
1. Spoofer l'adresse MAC de la box
2. S'assuer que le DUID (DHCP Unique Identifier) correspond bien à l'adresse MAC de la bbox et activer IPv6 dans pfsense
* System/Advanced/Networking check Allow IPv6
* System/Advanced/Networking DHCP6 DUID sélectionner DUID-LL
* System/Advanced/Networking DUID-LL: l'adresse MAC de la box
* System/Advanced/Networking Do not allow PD: uncheck
3. Configurer DHCPv6 sur l'interface WAN (cf. figure ci-dessous):
* Request only an IPv6 prefix check (Option IA_PD sans l'option IA_NA dans la requête DHCPv6)
* DHCPv6 Prefix: 60
* Send IPv6 prefix hint: check
* Do not wait for a RA: check
* DHCP6 VLAN Priority: check (IC6)
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]).
Afin d'assigner une adresse IPv6 globale a l'interface WAN, il suffit de se connecter en ssh sur le firewall et d'assigner manuellement une adresse a l'interface WAN, seul solution que j'ai trouvé pour l'instant (mais plus d'info dans ref[1] et ref[2]).
# On assigne manuellement une adresse a notre WAN dans le /60 que nous avons recut de l'opérateur
$ ifconfig WAN.100 inet6 2000:xxxx:xxxx:xxxf::1 prefixlen 64
# On restart l'interface Pfsense
$ php -r 'include("gwlb.inc"); setup_gateways_monitor();'
Références
1. https://forum.netgate.com/topic/174980/fios-getting-56-pd-via-dhcp6-but-no-v6-is-assigned-to-wan/
2. https://github.com/luckman212/assign-gua-from-iapd
3. https://redmine.pfsense.org/projects/pfsense/roadmap
4. https://www.rfc-editor.org/rfc/rfc6603.html
5. https://redmine.pfsense.org/issues/13296
-
Le fait qu'aucune GUA ne soit assignée à l'interface WAN pose-t-il problème ? J'ai la même chose sur un routeur OpenWRT (chez Orange, pour le coup) et ca ne pose pas de souci particulier.
Pour les connexions initiées par le routeur lui-même (ICMPv6, NTP, résolution DNS, etc.), une adresse GUA configurée sur l'une des pattes LAN est utilisée.
Là, tu attribues un /64 jentier uste pour la patte WAN, c'est presque dommage. Ceci dit, si tu n'as pas besoin de ce /64, ca ne doit pas être bien méchant :)
-
Le fait qu'aucune GUA ne soit assignée à l'interface WAN pose-t-il problème ? J'ai la même chose sur un routeur OpenWRT (chez Orange, pour le coup) et ca ne pose pas de souci particulier.
Tu as raison le faite qu'aucune GUA ne soit assignée à l'interface WAN ne pose pas de problème particulier étant donné que le routage s'effectue sur la base dune adresses de Liens Local. Cependant, il peut être utile par exemple de pouvoir effectuer un ping sur l'adresse WAN depuis un réseau externe pour tester la connectivité de ton interface WAN (traceroute, etc). Mais comme tu le soulignes au prix d'un /64 pour adressé une interface.... >:(
-
Merci pour les précisions, au moins on sait précisément où on est avec les pratiques de ByTel.
-
Cependant, il peut être utile par exemple de pouvoir effectuer un ping sur l'adresse WAN depuis un réseau externe pour tester la connectivité de ton interface WAN (traceroute, etc). Mais comme tu le soulignes au prix d'un /64 pour adressé une interface.... >:(
En fait je sais même pas si c'est nécessaire. Puisque qu'on peut très bien atteindre le routeur de l'extérieur même si la GUA est du côté LAN.
La RFC 7404 (https://datatracker.ietf.org/doc/rfc7404/), qui discute de l'utilisation de link local uniquement entre routeurs semble confirmer qu'une seule GUA configurée sur l'interface de loopback (ou autre) suffit au bon fonctionnement :
The sending of ICMPv6 [RFC4443] error messages ("packet-too-big", "time-exceeded", etc.) is required for routers. Therefore, another interface must be configured with an IPv6 address that has a greater scope than link-local. This address will usually be a loopback interface with a global scope address belonging to the operator and part of an announced prefix (with a suitable prefix length) to avoid being dropped by other routers implementing ingress filtering [RFC3704]. This is implementation dependent. For the remainder of this document, we will refer to this interface as a "loopback interface".
-
En fait je sais même pas si c'est nécessaire. Puisque qu'on peut très bien atteindre le routeur de l'extérieur même si la GUA est du côté LAN.
Oui, je te confirme qu'on peut bien pinger mon routeur en utilisant les interfaces GUA configurées sur ses pattes LAN. Et il s'en sert aussi comme adresse source pour envoyer les ICMP error messages.
-
En fait je sais même pas si c'est nécessaire. Puisque qu'on peut très bien atteindre le routeur de l'extérieur même si la GUA est du côté LAN.
La RFC 7404, qui discute de l'utilisation de link local uniquement entre routeurs semble confirmer qu'une seule GUA configurée sur l'interface de loopback (ou autre) suffit au bon fonctionnement
Oui, en effet tu as raison. On peut parfaitement se passer d'avoir la GUA sur l'interface WAN. Je souhaitais juste signifier ici qu’avoir une GUA sur l'interface WAN est plus d'un choix d'architecture qu'un choix strictement fonctionnel. Par exemple, tu veux vouloir vouloir avoir un VPN qui répond uniquement sur l'interface WAN (et pas sur les autres interfaces internes), avoir un serveur DNS avec deux zones, une interne qui répond sur les interfaces internes, une externe qui répond sur l'interface WAN. Je ne suis pas certain d'avoir choisi les meilleurs exemples, mais il me semble que dans certains cas de figure on peut trouver des configurations qui nécessitent une GUA sur l'interface WAN. Cela n'enlève rien au fait que ce qui est préconisé par la RFC 7404 est tout à fait légitime, voir même le plus couramment utilisé que ce qui est préconisé par la RFC 6603.
-
Hello!
Tuto toujours aussi simple, pas de changements entre le moment ou il a été fait et ajd.
Pour la partie TV,
J'ai mes requetes IGMP qui passent sans soucis (jsuis sur opnsense)
Ma question: C'est possible de mettre en cache les requetes IGMP?
J'ai bien l'impression qu'a chaque reboot de la box TV il doive refaire ses requetes...
Ou alors y a t-il un moyen d'accéder plus rapidement aux chaines via IGMP?
Par ce que niveau rapidité, autant passer par l'iptv, mais avec un viel écran c'est pas possible ;D
EDIT: j'ai mis tousles parametres P6 la ou je pouvais les mettre et ca fonctionne mieux
Par contre toutes les 5 minutes, j'ai un cut qui se fait, la box détecte une déconnexion ethernet, le direct se stoppe, son avant vidéo, puis je suis obligé de refresh via la télécommande, des idées ?
-
Bonjour a toutes et tous,
Bbox, vient de me demander de changer de box internet parce que l'ancienne (2016) n'était plus compatible avec la télé, sur la mise à jour du 14 août 2023 (environ) (plus de TV.).
Je viens de procéder à son remplacement et j'ai toujours la même adresse ip public, donc je pense que l'adresse ip public est lié à l'ONT qui lui n'a pas été changer.
Au dernier test de changement de la box vers une PFsense, j'avais des problèmes de flux TV qui se coupait toutes les 1 à 5 minutes. J'ai lu quelque part que cela pouvait venir de l'ONT. Aucun problème de blocage de port TCP/UDP, je n'ai rien dans les logs du firewall.
Quelqu'un a trouver une solution ? mise a part pimd
-
Bonjour à tous,
Je viens de passer de free à bouygues.
J'ai configuré mon pfsense comme je l'ai vu sur la première page mais pfsense me montre que je suis hors ligne et avec des latences élevées.
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 ?
-
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 (https://lafibre.info/remplacer-bbox/ftth-vlan-100-reglages-pfsense-net-tv/msg1005713/#msg1005713) ?
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 !
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
-
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 (https://lafibre.info/remplacer-bbox/ftth-vlan-100-reglages-pfsense-net-tv/msg1005713/#msg1005713) ?
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.
-
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.
-
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.