OPNsense & pfSense KPN/Telfort IPTV how-to

[stormfly]

Zojuist de bugs doorgenomen die nog spelen in de nieuwe PFsense versie 23.01 en het lijkt er op dat de IGMP proxy een flinke bug heeft waardoor tv kijken onmogelijk gemaakt kan worden.

Bron 1: https://forum.netgate.com...gmp-proxy-stops-tv-stream
Bron 2: https://redmine.pfsense.org/issues/13929

• Bij mijn intel NUC6i5 was het niet mogelijk om het multicast verkeer over de ene interface te versturen, zowel met OPNsense als pfSense ging het niet goed. De oplossing was op deze NUC een hypervisor te installeren en daarna losse interfaces toe te kennen: Vlan 34 internet, Vlan 4 IPTV en een LAN interface met de overige vlans. In VMware dan dus 3 losse fysieke interfaces waar van er slechts één een trunk is.
• Het verhaal over dat je verschillende MAC adressen op VLAN 4 en VLAN6 (KPN) moet gebruiken geldt alleen voor Telfort. Bij KPN en XS4ALL maakt dat niet uit en mogen beide hetzelfde MAC hebben omdat het via PPPoE verloopt.
• Vergeet niet om DNS en ICMP (ping naar de gateway) toe te staan op de STB LAN interface en te zorgen dat je DNS forwarder als je die gebruikt ook luistert op de interface. Tevens zorgen dat de DNS resolvers die je meegeeft ook allemaal werken. Als je primaire resolver niet werkt geeft dat zwart beeld op de oudere HD ontvanger (Arris VIP2952v2) ook al werkt de secundaire wel gewoon.
• Als je net als ik werkt met een "router on a stick" bijvoorbeeld een Intel NUC met slechts 1 UTP port. Dan "vliegt" je internet eruit zodra je een IP adres op het IPTV WAN vlan 4 hebt ontvangen. Dit heeft ermee te maken dat KPN unieke mac adressen per vlan wil zien. Dat is met een patch in opnsense op te lossen. https://forum.opnsense.org/index.php?topic=21705.0
• Bij OPNsense heb je een uitgaande rule nodig op het WAN VLAN4 waarin IGMP options aanstaat, anders stopt de stream na 5 minuten.
• Als je vlan 4 koppelt en je internet "vliegt eruit" dan kan er een probleem zijn met het gebruik van de default interface in je router. Deze moet vanzelfsprekend op de vlan 6 (KPN) of 34 interface zijn ingesteld, zie de screenshots hieronder. Soms kiest hij vlan4 als uitgang.

Zelf gebruik ik Telfort:

• Vlan 34 internet
• Vlan 4 IPTV

Bij KPN

• Vlan 6 internet
• Vlan 4 IPTV

Eerst wat achtergrond: een STB dient ge-nat te worden voor internettoegang (netflix) via de WAN VLAN6 interface of VLAN34 (Budget/Telfort). En zodra de STB bij de IPTV backend servers (213.75.112.0/21) wil komen dient hij genat te worden achter de VLAN4 KPN interface. Door het ontvangen van de TV routes via DHCP zal dit automatisch plaatsvinden, er is geen default route bekend op deze interface.

KPN gebruikt drie reeksen waar vanuit multicast verkeer verstuurd kan worden, vroeger was dit er slechts 1 en dat is verwarrend als je een oudere guide gebruikt.
10.0.0.0/8 voor software updates
213.75.0.0/16
217.166.0.0/16

Omdat ik zo min mogelijk onderhoud naar de toekomst wil, heb ik de IGMP proxy voorzien van een default route configuratie. Dat kan helaas niet in OPNsense en pfSense maar met een trucje wel. De default route 0.0.0.0/0 bestaat in feite uit 0.0.0.0/1 & 128.0.0.0/1.

De micro basis stappen staan hier uitgelegd:https://venxir.tweakblogs.net/blog/12507/kpn-glasvezel-via-pfsense ik ga er vanuit dat je weet hoe je een interface aanmaakt in OPNsense etc.


Als e.a werkt qua routering en nat kan je vanaf je testmachine de volgende testen doen:
-Ping 213.75.112.1 dit is het IPTV subnet.
-Ping 1.1.1.1 het normale internet
-Ping Tweakers.net om dns te testen

Update november 2021

Update november 2021
KPN stuurt via VLAN4 geen gateway meer mee, daardoor worden er geen automatische NAT rule aangemaakt en stagneert het TV verkeer. Het toevoegen van een handmatige NAT rule lost deze error 561 op.




Als het dan nog niet werkt dan kunnen het alleen nog firewall rules zijn of multicast fw rules.

WAN configuratie

Plaats op de VLAN4 WAN interface een DHCP configuratie met de volgende parameters. Je krijgt hier een DHCP adres van KPN.

Ter controle kan je valideren of de interface werkt via het interface overview menu.


Als de configuratie juist is krijg je de classless routes binnen, te controleren via System -> routes -> status

LAN configuratie

Maak een LAN interface aan voor je IPTV clients. In mijn netwerk gebruik ik hiervoor een apart vlan zodat dit VLAN geen ander verkeer hoeft te vervoeren. Wel zo overzichtelijk met troubleshooten of het maken van schone packetcaptures.
Op deze LAN interface hoef je vandaag (juli 2020) geen specifieke parameters meer uit te delen aan je STB IPTV kastjes, verstandig is wel om de KPN dns servers mee te geven op het STB vlan. Dit voorkomt in de toekomst ook weer onderhoud, of problemen.

NAT configuratie

De routering (routes verkregen door de classless-route optie via dhcp) bepaalt dat alleen het IPTV verkeer via VLAN4 gaat lopen. Al het andere IP-verkeer gaat via VLAN6. Een full nat (zonder destination filter) kan daarom zonder probleem worden toegepast op VLAN4 (= WANIPTV). Dus source address = any. Dit voorkomt problemen als KPN weer iets aanpast.

Firewall configuratie

Bij OPNsense heb je ook een uitgaande IGMP options rule nodig, anders stopt de stream na 5 minuten.

IP options vinkje is alleen nodig bij de IGMP accept regels en dan beide richtingen op. Dus zowel IPTV_STB -> IPTV WAN als IPTV WAN -> IPTV_STB

IGMP-proxy configuratie

pfSense werkende configuratie

Let op gebruik van de juiste quotes

VLAN4 DHCP instellingen om een IP adres vanuit KPN te verkrijgen:

code:

dhcp-class-identifier "IPTV_RG"
subnet-mask, routers, classless-routes

Check hierna of je de routes ontvangt en een IP krijgt op je vlan 4 interface.



Daarna kan je NAT instellen, verkeer naar dit subnet moet via de vlan4 interface afgehandeld worden. Dit kan ook via de normale route tabel verlopen, ik specificeer het graag ivm multi ISP verbindingen alhier.


Om te voorkomen dat al je internet verkeer naar vlan4 wordt gestuurd dien je de prioriteiten in te stellen zodat de vlan4 interface niet het woord (active) bevat.




Het is verstandig om de default interface (uitgang) op je router te specificeren, dat voorkomt uitdagingen waarbij vlan 4 of vlan 6/34 met elkaar vermengen.

FW rules, bij de IGMP rules dien je onder ADVANCED IP options aan te vinken.



Zelfde voor het WAN:bij de IGMP rules dien je onder ADVANCED IP options aan te vinken.

Vigor 165 config

[ Voor 184% gewijzigd door stormfly op 08-02-2023 10:51 ]

[ik222]

Ik maak even puntsgewijs wat opmerkingen.

- Het verhaal over dat je verschillende MAC adressen op VLAN 4 en VLAN6 moet gebruiken geldt alleen voor Telfort. Bij KPN en XS4ALL maakt dat niet uit en mogen beide hetzelfde MAC hebben.

- Wat betreft NAT, ik zou gewoon al het verkeer wat via WAN VLAN 4 naar buiten gaat NAT'ten. Dat voorkomt onnodige aanpassingen als er iets wijzigt. Routering bepaalt immers al dat alleen het juiste verkeer via VLAN4 naar buiten gaat.

- IP options vinkje is alleen nodig bij de IGMP accept regels en dan beide richtingen op. Dus zowel STB LAN -> IPTV WAN als IPTV WAN -> STB LAN.

- Vergeet niet om DNS en ICMP (ping naar de gateway) toe te staan op de STB LAN interface en te zorgen dat je DNS forwarder als je die gebruikt ook luistert op de interface. Tevens zorgen dat de DNS resolvers die je meegeeft ook allemaal werken. Als je primaire resolver niet werkt geeft dat zwart beeld op de oudere HD ontvanger (Arris VIP2952v2) ook al werkt de secundaire wel gewoon.

[stormfly]

ik222 schreef op maandag 14 juni 2021 @ 19:12:
Ik maak even puntsgewijs wat opmerkingen.

- Het verhaal over dat je verschillende MAC adressen op VLAN 4 en VLAN6 moet gebruiken geldt alleen voor Telfort. Bij KPN en XS4ALL maakt dat niet uit en mogen beide hetzelfde MAC hebben.

- Wat betreft NAT, ik zou gewoon al het verkeer wat via WAN VLAN 4 naar buiten gaat NAT'ten. Dat voorkomt onnodige aanpassingen als er iets wijzigt. Routering bepaalt immers al dat alleen het juiste verkeer via VLAN4 naar buiten gaat.

- IP options vinkje is alleen nodig bij de IGMP accept regels en dan beide richtingen op. Dus zowel STB LAN -> IPTV WAN als IPTV WAN -> STB LAN.

- Vergeet niet om DNS en ICMP (ping naar de gateway) toe te staan op de STB LAN interface en te zorgen dat je DNS forwarder als je die gebruikt ook luistert op de interface. Tevens zorgen dat de DNS resolvers die je meegeeft ook allemaal werken. Als je primaire resolver niet werkt geeft dat zwart beeld op de oudere HD ontvanger (Arris VIP2952v2) ook al werkt de secundaire wel gewoon.

tnx! jij bedoeld dat door de classless routes via DHCP het verkeer al automatisch naar WAN vlan4 gaat. Omdat de default route daar ontbreekt gaat al het internet verkeer naar VLAN6 of 34.

Een full nat (zonder destinations filter) over vlan 4 en een full nat over vlan 6 zorgt er dan voor dat zowel TV als Netflix werken.

[ Voor 4% gewijzigd door stormfly op 16-06-2021 22:13 ]

[ik222]

stormfly schreef op woensdag 16 juni 2021 @ 22:04:
[...]


tnx! jij bedoeld dat door de classless routes via DHCP het verkeer al automatisch naar WAN vlan4 gaat. Omdat de default route daar ontbreekt gaat al het internet verkeer naar VLAN6 of 34.

Een full nat (zonder destinations filter) over vlan 4 en een full nat over vlan 6 zorgt er dan voor dat zowel TV als Netflix werken.

Klopt helemaal, je krijgt via DHCP specifieke routes voor verkeer over VLAN4 en de default route staat op je internet interface (anders zou je geen internet hebben). Dus je mag simpelweg alles wat over VLAN4 naar buiten gaat NAT'en.

[Pimmetje651]

met de nodige interesse ben ik mezelf aan het inlezen in "de move" van Ziggo naar KPN glas te maken. En daarbij gebruik te blijven maken van mijnh huidige PF/OPNsense Vm-etje.
Nu kan ik nergens eigenlijk terug vinden HOE ze de glasvezel komen afmonteren , en hoe je dus on je PF/OPNsense kan "prikken". Is het zo dat ze een soort convertor komen monteren die dat een UTP aansluiting heeft ( dus van glas naar UTP) of / kun je de glasvezel straks rechtstreeks in je ESXi server doen (wat mijn voorkeur zal hebben). Waarbij dus direct de vraag weer bij me opkomt: HOE hebben jullie die glasvezel (single mode volgens mij) in je NUC/ ESXi /HyperV of whatever server gestoken ?

[stormfly]

Pimmetje651 schreef op woensdag 23 juni 2021 @ 13:34:
met de nodige interesse ben ik mezelf aan het inlezen in "de move" van Ziggo naar KPN glas te maken. En daarbij gebruik te blijven maken van mijnh huidige PF/OPNsense Vm-etje.
Nu kan ik nergens eigenlijk terug vinden HOE ze de glasvezel komen afmonteren , en hoe je dus on je PF/OPNsense kan "prikken". Is het zo dat ze een soort convertor komen monteren die dat een UTP aansluiting heeft ( dus van glas naar UTP) of / kun je de glasvezel straks rechtstreeks in je ESXi server doen (wat mijn voorkeur zal hebben). Waarbij dus direct de vraag weer bij me opkomt: HOE hebben jullie die glasvezel (single mode volgens mij) in je NUC/ ESXi /HyperV of whatever server gestoken ?

@Barre73 heb jij beeld wat kpnnetwerk tegenwoordig gebruikt? Zijn dat GPON NTU’s op basis van UTP met monteurs App activatie?

Heb jij een oude post waarin je e.a uitlegt. Vandaag achterhaald dat ik ook glas heb per december💪

[ANdrode]

stormfly schreef op woensdag 23 juni 2021 @ 20:01:
[...]
@Barre73 heb jij beeld wat kpnnetwerk tegenwoordig gebruikt? Zijn dat GPON NTU’s op basis van UTP met monteurs App activatie?

Heb jij een oude post waarin je e.a uitlegt. Vandaag achterhaald dat ik ook glas heb per december💪

Weet je wat ze gaan uitrollen? GPON of AON?

offtopic:
Wat apart dat je dit nu pas hoort. Maar goed, glas = glas.

[stormfly]

ANdrode schreef op woensdag 23 juni 2021 @ 20:56:
[...]


Weet je wat ze gaan uitrollen? GPON of AON?

offtopic:
Wat apart dat je dit nu pas hoort. Maar goed, glas = glas.

Ik ben zelf met kpnnetwerk gaan bellen, die kunnen één stap verder in het systeem kijken dan de publieke postcode check. Erg fijn te woord gestaan!

Ik heb goede hoop dat @Barre73 jouw vraag kan beantwoorden?

[Barre73]

Ik kan een uitgebreid verhaal houden maar de kans is 99 procent dat het GPON is.
En in dat geval is het niet mogelijk zelf een glasvezel in je router te steken. De bijbehorende ONT is essentieel en kan niet worden vervangen voor iets anders. KPN ziet de ONT als deel van de aansluiting.
Vanaf de ONT is het een UTP naar je router. Die mag wel van je zelf zijn als je KPN als provider neemt. Alle benodigde instellingen daarvoor staan op de website van KPN.
Bij andere providers kan het even zoeken zijn, bijvoorbeeld hier op GoT.

[ Voor 19% gewijzigd door Barre73 op 24-06-2021 08:21 ]

[stormfly]

ik222 schreef op woensdag 16 juni 2021 @ 22:16:
[...]

Klopt helemaal, je krijgt via DHCP specifieke routes voor verkeer over VLAN4 en de default route staat op je internet interface (anders zou je geen internet hebben). Dus je mag simpelweg alles wat over VLAN4 naar buiten gaat NAT'en.

Ik zou toch nog graag even gebruik maken van je kennis, ik heb nu een IPTV decoder om e.a. te testen. Het bleek dat door multiwan e.a. niet lekker genat werd, dat is opgelost. Vanuit het IPTV segment kan ik pingen naar het TV segment.

 ping 213.75.112.1
PING 213.75.112.1 (213.75.112.1): 56 data bytes
64 bytes from 213.75.112.1: icmp_seq=0 ttl=61 time=16.014 ms
64 bytes from 213.75.112.1: icmp_seq=1 ttl=61 time=12.080 ms
64 bytes from 213.75.112.1: icmp_seq=2 ttl=61 time=10.477 ms
64 bytes from 213.75.112.1: icmp_seq=3 ttl=61 time=9.826 ms
64 bytes from 213.75.112.1: icmp_seq=4 ttl=61 time=9.991 ms

Ik stuur nu een STRING met quotes mee " dat moet voldoende zijn?


Ik stuur de Telfort/Budget Thuis DNS servers mee


En toch blijft hij snoeihard op code 301 hangen.... "laten van software op ontvanger lukt niet" terwijl er wel internet beschikbaar is en functioneel ook werkt in dat segment.

[stormfly]

Alles lijkt in de basis te werken alleen zodra hij het IGMP wil gaan doen met MC stagneert de communicatie.

[stormfly]

code:

##------------------------------------------------------
## Enable Quickleave mode (Sends Leave instantly)
##------------------------------------------------------
quickleave
phyint em0_vlan24 downstream ratelimit 0 threshold 1
altnet 172.16.24.0/24

phyint em0_vlan4 upstream ratelimit 0 threshold 1
altnet 213.75.0.0/21
altnet 10.151.216.0/21
altnet 217.166.0.0/16
altnet 224.0.0.0/4

[stormfly]

@ik222 ik ben zo benieuwd waar het nu scheef loopt.

IGMP LAN verkeer gesniffed op OPNsense (UniFi switches in het pad)



IGMP WAN verkeer de IGMP proxy lijkt te functioneren.

[ik222]

Dat lijkt allemaal goed als ik even snel kijk. Zie je iets geblokkeerd worden in je firewall logs wellicht?

[stormfly]

ik222 schreef op woensdag 30 juni 2021 @ 22:28:
Dat lijkt allemaal goed als ik even snel kijk. Zie je iets geblokkeerd worden in je firewall logs wellicht?

Nee eigenlijk niets. Kan het zijn dat een stb eerst geactiveerde moet worden in een experia box? Dan ben ik wel benieuwd waar de stb naar toe connect.

[ik222]

stormfly schreef op woensdag 30 juni 2021 @ 22:36:
[...]


Nee eigenlijk niets. Kan het zijn dat een stb eerst geactiveerde moet worden in een experia box? Dan ben ik wel benieuwd waar de stb naar toe connect.

Nee dat moet niet nodig zijn, bij mijn XS4ALL verbinding is nog nooit de originele Fritbox online geweest. Heb inmiddels al meerdere nieuwe STB's zonder issues achter pfSense voor de eerste keer geïnstalleerd dus.

Laat je actieve routes en NAT regels eens zien en gooi voor de test eens even je firewall 2 kanten op volledig open?

[ Voor 10% gewijzigd door ik222 op 30-06-2021 22:46 ]

[stormfly]

ik222 schreef op woensdag 30 juni 2021 @ 22:44:
[...]

Nee dat moet niet nodig zijn, bij mijn XS4ALL verbinding is nog nooit de originele Fritbox online geweest. Heb inmiddels al meerdere nieuwe STB's zonder issues achter pfSense voor de eerste keer geïnstalleerd dus.

Zal morgen nog eens testen met een floating allow all.

IGMP proxy ziet er functioneel uit hè? Geef jij de optie 60 mee als string met “ “ of als text?

[ik222]

stormfly schreef op woensdag 30 juni 2021 @ 22:46:
[...]


Zal morgen nog eens testen met een floating allow all.

IGMP proxy ziet er functioneel uit hè? Geef jij de optie 60 mee als string met “ “ of als text?

Als text en dan zonder quotes, maar geen idee of dat verschil maakt...

IGMPProxy lijkt me inderdaad goed te werken dus dat zal het niet zijn.

[stormfly]

ik222 schreef op woensdag 30 juni 2021 @ 23:42:
[...]

Als text en dan zonder quotes, maar geen idee of dat verschil maakt...

IGMPProxy lijkt me inderdaad goed te werken dus dat zal het niet zijn.

Die OPTION 60 is eruit bij de orginele EB DHCP offers.



Hieronder een capture van de EB dan lijkt alles direct te werken, je ziet na het verzoek tot joinen op de .6 group dat er direct MC gaat lopen om de software te downloaden.



Hieronder de FW ruleset, zou je nog eens een blik willen werpen? Pingen naar het IPTV segment lukt dus nat etc is in orde.

[stormfly]

<knip>

[ Voor 98% gewijzigd door stormfly op 02-07-2021 18:41 ]

[stormfly]

Heb het nu met een vyatta router op VMware direct werkend, uitgesloten zijn nu: UniFi switch laag, Vigor 165, vlan setup. Kijk al geruime tijd zonder hakkelen of stotteren TV.

Dit moet aan OPNsense liggen, nog 1x ff goed vastbijten ;P

[ Voor 4% gewijzigd door stormfly op 02-07-2021 18:40 ]

[Kabouterplop01]

Weet je zeker dat het 213.75 subnet niet te klein is? Ik weet uit ervaring dat het netwerk eigenlijk een /16 is. Jij hebt /21 (dat scheel nogal wat hosts en bereik )

[stormfly]

Kabouterplop01 schreef op vrijdag 2 juli 2021 @ 18:58:
Weet je zeker dat het 213.75 subnet niet te klein is? Ik weet uit ervaring dat het netwerk eigenlijk een /16 is. Jij hebt /21 (dat scheel nogal wat hosts en bereik )

Het is lastig reverse engineering toe te passen. De IPTV_RG optie voor de STB is ook achterhaald blijkt uit mijn snif actie.

De specifieke routes voor vlan 4 komen tegenwoordig automatisch mee met de DHCP request. Dat is een 213.75.112.0/21 netwerk dat is door KPN automatisch aangeleverd. Dat kunnen we als feit beschouwen.

Ik doorgrond niet waarom iemand heeft bedacht dat dit subnet ook relevant is 217.166.0.0/16? Misschien alleen voor KPN en niet voor Telfort zoals bij mij? Waarom levert KPN dit subnet dan ook niet aan via de bovenstaande optie.

MC streams krijg je zodra je er om vraagt via IGMP. Ongeacht de source, die mag overal vandaan komen lijkt mij.

De MC source komt niet uit de automatisch aangeleverde /21. Ik had misschien in het begin de fw rules gelimiteerd.

[ Voor 11% gewijzigd door stormfly op 02-07-2021 19:27 ]

[ik222]

Sorry ik heb even weinig tijd gehad om te reageren. Maar 213.75.0.0 moet je inderdaad als /16 definiëren voor je firewall regels. Je krijgt een static route voor een /21 omdat je alleen daarheen routes nodig hebt maar er liggen multicast sources buiten die /21...

[stormfly]

Met deze methode heb ik toch een 0.0.0.0/0 in de IGMP proxy gekregen, dat heeft vayatta ook (de werkende setup)

Krijg even geen tijdslot om het beeld te onderbreken ;-) om het te testen.

Ik kwam deze logs tegen, dat gaf de reden tot het bovenstaande onderzoek.

code:

Jul  2 20:35:33 OPNsense igmpproxy[15574]: The source address 217.166.226.126 for group 224.0.252.126, is not in any valid net for upstream VIF[0].
Jul  2 20:35:33 OPNsense igmpproxy[15574]: The source address 213.75.167.58 for group 224.3.2.6, is not in any valid net for upstream VIF[0].
Jul  2 20:35:34 OPNsense igmpproxy[15574]: The source address 217.166.226.126 for group 224.0.252.126, is not in any valid net for upstream VIF[0].
Jul  2 20:35:34 OPNsense igmpproxy[15574]: The source address 213.75.167.58 for group 224.3.2.6, is not in any valid net for upstream VIF[0].
Jul  2 20:35:35 OPNsense igmpproxy[15574]: The source address 217.166.226.126 for group 224.0.252.126, is not in any valid net for upstream VIF[0].
Jul  2 20:35:36 OPNsense igmpproxy[15574]: The source address 213.75.167.58 for group 224.3.2.6, is not in any valid net for upstream VIF[0].

@Kabouterplop01 daar is ook ineens het antwoord op de 217.166.0.0 reeks ;-)

[Kabouterplop01]

Check: Goed getroubleshoot lijkt me!

[ Voor 25% gewijzigd door Kabouterplop01 op 03-07-2021 12:17 . Reden: denkfout, ben benieuwd ]

[stormfly]

@Coolhva @ik222

Omdat OPNsense nog steeds niet werkt heb ik twee alternatieven in een VM gebruikt. Vayatta en pfSense beide voorzien in een goede multicast TV beleving. Alles functioneert naar wens.

Het is dus echt een bug/probleem in OPNsense, zouden jullie nog 1x mee willen kijken naar de config voor ik een bug open bij OPNsense?

De foutmelding bij de STB is 561, het lijkt erop dat er op het LAN geen UDP multicast data zichtbaar is. Wat op zich opmerkelijk is want op het WAN komt deze MC data wel binnen, na een IGMP verzoek.

Zien jullie een ontbrekende FW rule? Alle segmenten, internet en 213.75.112.0/21 zijn allemaal bereikbaar via icmp. Routing en NAT zijn uitgesloten, het moet een probleem zijn met de igmp proxy of een UDP MC fw rule?

Gebaseerd op deze bron werken deze rules in pfSense feilloos.
http://un.geeig.net/openbsd-vdsl.html

tcpdump capture, gelijktijdig op vlan4 en vlan25 https://www.dropbox.com/s...zIsLhWiyTNpIhdUmJBSa?dl=0

[...]
pass in on $WANINT inet proto igmp to 224.0.0.0/4 allow-opts
pass in on $WANINT inet proto udp  to 224.0.0.0/4
[...]
pass out on $WANINT inet proto igmp from $WANIP to 224.0.0.0/4 allow-opts
[...]
pass in on $LANINT inet proto igmp from $SETTOPBOX to 224.0.0.0/4 allow-opts
pass in on $LANINT inet proto udp  from $SETTOPBOX
pass in on $LANINT inet proto tcp  from $SETTOPBOX
[...]
pass out on $LANINT inet proto igmp from $LANIP to 224.0.0.0/4 allow-opts
pass out on $LANINT inet proto udp to 224.0.0.0/4

pfSense kan een OUT richting op de interface plaatsen, dat moet via een floating rule. Om dit 100% gelijk te houden heb ik deze ook floating gemaakt in OPNsense (op de interface zelf werkt het ook niet)

Voor de volledigheid dan nog de pfSense werkende FW rules + igmp proxy

[stormfly]

*crap ik zie een typo in de IGMP proxy config staan /32 ipv /1. Nog steeds ben ik benieuwd of een FW rule de UDP flow op het client lan kan blokkeren?

EDIT: nee ook nu maakt het niets uit, typo gecorrigeerd en OPNsense laat geen TV beelden door. Wel is nu het MC verkeer zichtbaar op het LAN. Klopt ook wel want 213.x.x.x. valt in 128.0.0.0/1 als daar een typo in zat werden deze streams van het LAN weg gefilterd.

[ Voor 49% gewijzigd door stormfly op 04-07-2021 21:56 ]

[ik222]

Met die typo in de IGMPProxy config werkt het sowieso niet. Maar sowieso, 217.166.0.0/16 en 213.75.0.0/16 in de upstream subnets is voldoende.

Verder snap ik niet wat je met die floating rules wilt bereiken. Simpelweg firewall regels op de interfaces moet voldoende zijn.

[stormfly]

ik222 schreef op zondag 4 juli 2021 @ 21:57:
Verder snap ik niet wat je met die floating rules wilt bereiken. Simpelweg firewall regels op de interfaces moet voldoende zijn.

Klopt maar er zijn ook OUT rules nodig, OPNsense kan deze wel direct op het interface plaatsen. Maar pfSense kent alleen IN op interface niveau, en OUT alleen op floating niveau.

Vandaar dat ik het gelijk gemaakt heb, op interface niveau werkt het ook al een week niet

[ik222]

Waarvoor heb je die OUT regels nodig dan?

Wat ik zelf doe is op de STB LAN interface:
- Eerst ICMP en DNS naar de firewall toestaan.
- Daarna al het andere verkeer naar mijn interne subnets blokkeren.
- Dan IGMP inclusief options met als destination 224.0.0.0/4 toestaan
- En als laatste al het andere uitgaande verkeer zonder opties toestaan.

Op de ITV WAN interface sta ik enkel 2 dingen toe:
- IGMP inclusief options vanaf 10.0.0.0/8 met als destination 224.0.0.0/4
- UDP vanaf 213.75.0.0/16 en 217.166.0.0/16 met als destination 224.0.0.0/4

Dat is alles wat je aan firewall regels nodig hebt voor IPTV.

[stormfly]

ik222 schreef op zondag 4 juli 2021 @ 21:57:
Met die typo in de IGMPProxy config werkt het sowieso niet. Maar sowieso, 217.166.0.0/16 en 213.75.0.0/16 in de upstream subnets is voldoende.

Klopt dat is in theorie voldoende, ik probeer tot een ontwerp te komen waarin zo min mogelijk reverse engineering zit. Als je de igmp proxy op je STB LAN subnet als downstream configureert en upstream "any" dan heb je hier in de toekomst 0,0 onderhoud aan. Ook als KPN nieuwe reeksen toevoegt, we weten immers de reeksen niet. Een ripe allocatie van /16 hoeft niet te zeggen dat KPN ook exact die /16 gebruikt voor IPTV, kan ook een /21 zijn etc etc. Bijvoorbeeld Telfort DNS 213.75.63.78 valt als in 213.75.0.0/16, als we deze details niet kunnen onderscheiden of reverse engineering toe kunnen passen is 0.0.0.0/0 veiliger als upstream in de igmp proxy.

ik222 schreef op zondag 4 juli 2021 @ 22:33:
Waarvoor heb je die OUT regels nodig dan?

Wat ik zelf doe is op de STB LAN interface:
- Eerst ICMP en DNS naar de firewall toestaan.
- Daarna al het andere verkeer naar mijn interne subnets blokkeren.
- Dan IGMP inclusief options met als destination 224.0.0.0/4 toestaan
- En als laatste al het andere uitgaande verkeer zonder opties toestaan.

Op de ITV WAN interface sta ik enkel 2 dingen toe:
- IGMP inclusief options vanaf 10.0.0.0/8 met als destination 224.0.0.0/4
- UDP vanaf 213.75.0.0/16 en 217.166.0.0/16 met als destination 224.0.0.0/4

Dat is alles wat je aan firewall regels nodig hebt voor IPTV.

Goede vraag, ik denk om de multicast gerelateerde informatie te sourcen vanaf de lokale interfaces. In pfSense zie je mooie counters per rule en die lopen wel op, al is het maar een hele beperkte hoeveelheid data.

[stormfly]

@ik222 weet je waar het mis gaat? Het gaat mis op de enkele NIC in de Intel NUC. Daar kan OPNsense helemaal niet mee overweg. Als je de NUC voorziet van pfSense PLUS of CE, dan komt er wel beeld maar stottert het enorm.

Zet je OPNsense of pfSense op een VM met losse interfaces, gaat multicast als een zonnetje ;-)

[Coolhva]

stormfly schreef op maandag 5 juli 2021 @ 22:25:
@ik222 weet je waar het mis gaat? Het gaat mis op de enkele NIC in de Intel NUC. Daar kan OPNsense helemaal niet mee overweg. Als je de NUC voorziet van pfSense PLUS of CE, dan komt er wel beeld maar stottert het enorm.

Zet je OPNsense of pfSense op een VM met losse interfaces, gaat multicast als een zonnetje ;-)

Heb je een USB LAN adapter die je kan testen op je NUC? Ik weet niet zeker of het de enkele interface is, of iets anders op de NUC.

"The absence of evidence is not evidence of absence"

[stormfly]

Coolhva schreef op dinsdag 6 juli 2021 @ 11:39:
[...]


Heb je een USB LAN adapter die je kan testen op je NUC? Ik weet niet zeker of het de enkele interface is, of iets anders op de NUC.

"The absence of evidence is not evidence of absence"

Nee die zou ik even aan moeten schaffen, gezien het feit dat het goed werkt met losse NIC's. Blijft dat wel mijn denkrichting.

[ANdrode]

stormfly schreef op dinsdag 6 juli 2021 @ 11:57:
[...]


Nee die zou ik even aan moeten schaffen, gezien het feit dat het goed werkt met losse NIC's. Blijft dat wel mijn denkrichting.

Een USB 3 NIC is voor zulke gevallen best handig. Zelfs als WAN interface zijn ze eigenlijk best geschikt.

offtopic:
Afhankelijk van type NUC is een thunderbolt adapter ook een optie

[Arno-]

Deze maand ben ik overgestapt van KPN naar een andere provider (beiden VDSL2).

@stormfly Graag zou ik nog iets toevoegen aan de eerste post.
KPN: PPPoE
Telfort: DHCP

Zelf heb ik een configuratie die ik zou willen gebruiken:
Vigor 165: Bridged
pfSense/OPNsense op VM

Nu gebruik ik:
Vigor 165 in Routing mode.
pfSense/OPNsense op VM.

Beide hebben een ander probleem.

Bridged: DHCP op *sense werkt niet (FAIL).
KPN configuratie werkte alleen met pfSense.
Met OPNsense had ik alleen internet.

Routed: Of internet werkt of iptv. Beide tegelijk is nog niet gelukt.
Weet ook niet zeker of dat kan met de Vigor 165.
Theoretisch zou het moeten kunnen met twee LAN poorten.

Heeft iemand een werkende configuratie met deze hardware/software?
Mijn voorkeur gaat uit naar een oplossing met het modem in bridged mode.

[stormfly]

Arno- schreef op zondag 11 juli 2021 @ 11:11:
Deze maand ben ik overgestapt van KPN naar een andere provider (beiden VDSL2).

@stormfly Graag zou ik nog iets toevoegen aan de eerste post.
KPN: PPPoE
Telfort: DHCP

Zelf heb ik een configuratie die ik zou willen gebruiken:
Vigor 165: Bridged
pfSense/OPNsense op VM

Nu gebruik ik:
Vigor 165 in Routing mode.
pfSense/OPNsense op VM.

Beide hebben een ander probleem.

Bridged: DHCP op *sense werkt niet (FAIL).
KPN configuratie werkte alleen met pfSense.
Met OPNsense had ik alleen internet.

Routed: Of internet werkt of iptv. Beide tegelijk is nog niet gelukt.
Weet ook niet zeker of dat kan met de Vigor 165.
Theoretisch zou het moeten kunnen met twee LAN poorten.

Heeft iemand een werkende configuratie met deze hardware/software?
Mijn voorkeur gaat uit naar een oplossing met het modem in bridged mode.

Ik draai ook alles met de Vigor 165. Je moet voor Vlan 34 en vlan 4 aparte NICs maken in VMware. De KPN centrale kan niet omgaan met twee dezelfde mac adressen ondanks dat ze in verschillende vlans zitten. Heb je beide vlans al eens getest? Is je Vigor goed geconfigureerd, als vlan bridge waarbij hij alle vlans en 1:1 doorzet?

Als e.a werkt qua routering en nat kan je vanaf je testmachine de volgende testen doen:

-Ping 213.75.112.1 dit is het IPTV subnet.
-Ping 1.1.1.1 het normale internet
-Ping Tweakers.net om dns te testen

Als het dan nog niet werkt dan kunnen het alleen nog firewall rules zijn of multicast fw rules.

Deel maar screenshot dan kunnen we kijken. Ik zal de hoofdpost ook aanpassen met pfSense screenshots en OPNsense screenshot.

Bij mij werkt het nu, maar ik ga toch voor NLziet met AppleTV.

[stormfly]

Arno- schreef op zondag 11 juli 2021 @ 11:11:
Deze maand ben ik overgestapt van KPN naar een andere provider (beiden VDSL2).

@stormfly Graag zou ik nog iets toevoegen aan de eerste post.
KPN: PPPoE
Telfort: DHCP

Zelf heb ik een configuratie die ik zou willen gebruiken:
Vigor 165: Bridged
pfSense/OPNsense op VM

Nu gebruik ik:
Vigor 165 in Routing mode.
pfSense/OPNsense op VM.

Beide hebben een ander probleem.

Bridged: DHCP op *sense werkt niet (FAIL).
KPN configuratie werkte alleen met pfSense.
Met OPNsense had ik alleen internet.

Routed: Of internet werkt of iptv. Beide tegelijk is nog niet gelukt.
Weet ook niet zeker of dat kan met de Vigor 165.
Theoretisch zou het moeten kunnen met twee LAN poorten.

Heeft iemand een werkende configuratie met deze hardware/software?
Mijn voorkeur gaat uit naar een oplossing met het modem in bridged mode.

screenshots allemaal bijgewerkt.

[Arno-]

Modem in bridged mode werkt nu :-) .

pfSense:
De volgende wijzigen heb ik gemaakt.
- Default gateway niet op Automatic maar handmatig op WAN_GW.
- De interfaces IPTV en STB zijn beide disabled.

Alleen internet werkt nu.
Voor de VM's gebruik ik Proxmox met PCI passthrough dus interfaces hebben eigen poort/mac adres.

Weer een stapje dichterbij. Nu nog IPTV.

[MisteRMeesteR]

Titelfix iov TS

[Arno-]

IPTV interface erbij zorgt ervoor dat internet niet meer werkt.

pfSense krijgt wel (tweede) ip adres voor iptv maar internet werkt direct niet meer.
Na reboot pfSense ook geen ip adres meer op wan interface.
De configuratie van pfSense terugzetten die werkte (zie vorige post) helpt niet.

Weet iemand waarom?
Nu weer terug naar modem in routed mode. Anders heb ik geen internet.

[KernelPanic]

Arno- schreef op zondag 11 juli 2021 @ 17:24:
IPTV interface erbij zorgt ervoor dat internet niet meer werkt.

pfSense krijgt wel (tweede) ip adres voor iptv maar internet werkt direct niet meer.
Na reboot pfSense ook geen ip adres meer op wan interface.
De configuratie van pfSense terugzetten die werkte (zie vorige post) helpt niet.

Weet iemand waarom?
Nu weer terug naar modem in routed mode. Anders heb ik geen internet.

Ander mac adres op IPTV interface?

[Arno-]

Arno- schreef op zondag 11 juli 2021 @ 16:36:
...
Voor de VM's gebruik ik Proxmox met PCI passthrough dus interfaces hebben eigen poort/mac adres.
...

Ja.

[stormfly]

Arno- schreef op zondag 11 juli 2021 @ 19:38:
[...]

Ja.

Dat denk ik niet, anders had hij niet "eruit geklapt". De enige reden dat dit gebeurd is dat je hetzelfde mac gebruikt in zowel vlan 4 als 6. Of een config fout.

Waar je ook moet doen is de gateway prioriteit verlagen, zodat de gateway prio van vlan 34 beter is dan die van vlan 4.

Zal het in de guide opnemen. Zie hieronder de dropdown, die moet dan op de vlan 34 interface staan.

[ Voor 54% gewijzigd door stormfly op 11-07-2021 20:29 ]

[stormfly]

@Arno-
Hoe ziet dit scherm er bij jou uit?



bij OPNsense is het overzichtelijker ivm de prio's

[ Voor 33% gewijzigd door stormfly op 11-07-2021 20:46 ]

[Arno-]

@stormfly Bedoel je dit?
Mijn gateway overzicht ziet er anders uit (pfSense 2.5.2)

Bij vlans zie ik wel een prioriteit.

Omdat ik nu met de routed configuratie werk heb ik de gateway gegevens weggelaten.

[Arno-]

Mijn mac adressen zijn verschillend. (NB Routed config dus geen vlan 34). Anders heb ik geen internet.
IPTV en STB zijn nu disabled.

[ Voor 3% gewijzigd door Arno- op 11-07-2021 21:40 ]

[stormfly]

Arno- schreef op zondag 11 juli 2021 @ 21:39:
Mijn mac adressen zijn verschillend. (NB Routed config dus geen vlan 34). Anders heb ik geen internet.
IPTV en STB zijn nu disabled.
[Afbeelding]

Nee je MAC adressen zijn hetzelfde, je plakt namelijk vlan 4 "op" igb0 wat ook je WAN interface is. Beide NICS gaan naar buiten toe met het MAC van igb0. Vlan 4 mag je overal opzetten behalve igb0 ;-)

Als je hier geen vlan 34 gebruikt ben ik benieuwd of je vigor wel in volledige bridge staat?

Ik begrijp niet helemaal wat je met routed setup bedoeld?

[Arno-]

> Ik begrijp niet helemaal wat je met routed setup bedoeld?
Mijn modem staat nu in routed mode. Anders heb ik geen internet.

> Nee je MAC adressen zijn hetzelfde, je plakt namelijk vlan 4 OP igb0 wat ook je WAN interface is.
Shit. Dat had ik zelf moeten zien. Bedankt.

Maar hoe moet ik dan pfSense configureren?
Als ik mijn modem in bridged modus zet heb ik één ethernet kabel vanaf het modem naar pfSense.
Moet ik dan MAC spoofing gebruiken?

[stormfly]

Arno- schreef op zondag 11 juli 2021 @ 22:48:
> Ik begrijp niet helemaal wat je met routed setup bedoeld?
Mijn modem staat nu in routed mode. Anders heb ik geen internet.

> Nee je MAC adressen zijn hetzelfde, je plakt namelijk vlan 4 OP igb0 wat ook je WAN interface is.
Shit. Dat had ik zelf moeten zien. Bedankt.

Maar hoe moet ik dan pfSense configureren?
Als ik mijn modem in bridged modus zet heb ik één ethernet kabel vanaf het modem naar pfSense.
Moet ik dan MAC spoofing gebruiken?

Die ene kabel stop je in een managed switch waar je vlan 4 en vlan 34 in aangemaakt hebt. Dan ga je vanaf je virtuele hypervisor 3 NIC's aan de pfSense VM uitdelen:

LAN vlan 1,2,3,4,5 etc
WAN vlan 34
WAN_IPTV vlan4

[Arno-]

Wat hardware betreft heb ik het iets anders gedaan maar het komt op hetzelfde neer.

De WAN/LAN/STB kabels heb ik aangesloten op de VM host.
Deze ethernet poorten heb ik toegekend aan de VM guest.
In de VM guest zijn de vlans (34/4) geconfigureerd.

In pfSense hebben de vlans nu verschillende mac adressen.
Internet verbinding in eigen LAN en IPTV werken nu.

Behalve het opstarten van (en downloaden software naar) de STB.
Daarvoor moet ik de EB aansluiten. Wat niet praktisch is.
Ik heb geen idee welk netwerk verkeer de firewall rules door moeten laten.
Ik kan er geen lijn in kunnen ontdekken. Een keer is het downloaden van software gelukt, Daarna niet meer.

In OPNsense werkt internet wel en IPTV niet.
Na het lezen van de eerste post heb ik nog 'allow options' aangezet bij igmp verkeer van iptv en stb interface.
Dat helpt niet.
Heeft iemand nog een idee wat ik kan checken?

[ Voor 16% gewijzigd door Arno- op 12-07-2021 18:21 ]

[stormfly]

Arno- schreef op maandag 12 juli 2021 @ 17:20:
Wat hardware betreft heb ik het iets anders gedaan maar het komt op hetzelfde neer.

De WAN/LAN/STB kabels heb ik aangesloten op de VM host.
Deze ethernet poorten heb ik toegekend aan de VM guest.
In de VM guest zijn de vlans (34/4) geconfigureerd.

In pfSense hebben de vlans nu verschillende mac adressen.
Internet verbinding in eigen LAN en IPTV werken nu.

Behalve het opstarten van (en downloaden software naar) de STB.
Daarvoor moet ik de EB aansluiten. Wat niet praktisch is.
Ik heb geen idee welk netwerk verkeer de firewall rules door moeten laten.
Ik kan er geen lijn in kunnen ontdekken. Een keer is het downloaden van software gelukt, Daarna niet meer.

In OPNsense werkt internet wel en IPTV niet.
Na het lezen van de eerste post heb ik nog 'allow options' aangezet bij igmp verkeer van iptv en stb interface.
Dat helpt niet.
Heeft iemand nog een idee wat ik kan checken?

Hoe zien je fw rules eruit en je IGMP proxy configuratie? Screenshots bij voorkeur.

[Arno-]

[stormfly]

Arno- schreef op dinsdag 13 juli 2021 @ 13:09:
[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

Tnx voor het delen, ik kan heelveel details gaan benoemen maar ik vat het samen. Zet al jouw rules op OFF en pak die 4-5tal rules uit mijn screenshots en plak die erin. Grootste uitdaging dat je UDP (de multicast stream) naar 224.0.0.0/4 niet toe laat op je wan en stb interface.

Je hebt teveel zelf nagedacht, te weinig gelezen & gekopieerd, en nu is het chaos -> back to the basics.

PS: een protocol any rule voorkomt dat je TCP/UDP/ICMP apart hoeft te specificeren.


EDIT dat je software download niet werkt komt omdat je de IGMP proxy niet hebt ingesteld zoals in mijn voorbeeld. Als je toch perse met losse subnetten wilt werken moet je 10.0.0.0/8 nog toevoegen, daar komt de software vandaan. Lees ook de tekst in mijn uitleg over hoe je het jezelf gemakkelijker maakt door grotere ranges toe te voegen, dan ben je veel minder kwetsbaar voor wijzigingen aan de KPN zijde.

[ Voor 12% gewijzigd door stormfly op 13-07-2021 13:39 ]

[Arno-]

> Je hebt teveel zelf nagedacht, te weinig gelezen & gekopieerd, en nu is het chaos -> back to the basics.
Zeker chaos. Ik snap gewoon niet wat het netwerk verkeer zou moeten zijn. Dus idd back to basics.

Nieuwe setup voor mij:
pfSense laat ik zoals het nu is voor de VPN verbinding.

OPNsense 21.1.8_1-amd64 (nu zonder VPN)
Alle firewall rules van IPTV en STB verwijderd en overgenomen van de plaatjes.
Ook igmp proxy aangepast volgens plaatje (0.0.0.0/1, 128.0.0.0/1).
Switch tussen OPNsense en STB voor wireshark.

Het downloaden lukt nu.
Op 85% komt de foutcode 561.

In het edit gedeelte schrijf je dat de software van 10.0.0.0/8 komt.
Als ik kijk in wireshark dan zie ik 213.75.167.58 (udp) tijdens het downloaden.
Dat maakt het voor mij zo verwarrend.
In de firewall log zie ik niets wat wordt geblokkeerd (voor IPTV, wel voor inkomende verbindingen zoals ssh).

[Arno-]

[stormfly]

Arno- schreef op dinsdag 13 juli 2021 @ 18:11:
Het downloaden lukt nu.
Op 85% komt de foutcode 561.

In het edit gedeelte schrijf je dat de software van 10.0.0.0/8 komt.
Als ik kijk in wireshark dan zie ik 213.75.167.58 (udp) tijdens het downloaden.
Dat maakt het voor mij zo verwarrend.
In de firewall log zie ik niets wat wordt geblokkeerd (voor IPTV, wel voor inkomende verbindingen zoals ssh).

Volgens mij is die foutcode een stukje bereikbaarheid voor unicast, wil je eens een device in dat vlan stoppen en pingen naar:

1.1.1.1
213.75.112.1
tweakers.net

gaat dat allemaal goed?

[Arno-]

Nee. Pingen naar 213.75.112.1 gaat niet.

Extra NAT rule toegevoegd.
Bingo!

@stormfly Bedankt voor je geduld en je hulp.

Nu wil ik nog de VPN client weer terugzetten.
Dat moet lukken.

Update: VPN ook weer geconfigureerd. .

[ Voor 10% gewijzigd door Arno- op 13-07-2021 21:13 ]

[Arno-]

OPNsense:
De igmp proxy server stopt (soms?) bij het opstarten van de STB. Geen idee waarom.

Na handmatig herstarten in webinterface gaat het downloaden verder of is de stream te zien/horen.

[stormfly]

Arno- schreef op woensdag 21 juli 2021 @ 19:18:
OPNsense:
De igmp proxy server stopt (soms?) bij het opstarten van de STB. Geen idee waarom.

Na handmatig herstarten in webinterface gaat het downloaden verder of is de stream te zien/horen.

Wat zeggen logs? Ben zelf over naar pfSense.

[Lawrentium]

Ik loop sinds kort ook tegen problemen aan met KPN (ik zit nog op de oude Telfort config).

TV kijken werkt, maar sinds kort werken er een groot aantal zenders niet meer. Bijvoorbeeld RTL4, RTL5, SBS6, RTL7, en nog veel meer.

Ik vermoed dat ik een bepaalde IP range mis in mijn config, maar ik kom er inmiddels niet meer uit.

Zien jullie iets verkeerd staan? Alvast bedankt.

[stormfly]

Lawrentium schreef op zondag 5 september 2021 @ 12:16:
Ik loop sinds kort ook tegen problemen aan met KPN (ik zit nog op de oude Telfort config).

TV kijken werkt, maar sinds kort werken er een groot aantal zenders niet meer. Bijvoorbeeld RTL4, RTL5, SBS6, RTL7, en nog veel meer.

Ik vermoed dat ik een bepaalde IP range mis in mijn config, maar ik kom er inmiddels niet meer uit.

Zien jullie iets verkeerd staan? Alvast bedankt.

[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

In de start post zitten exacte kopieën van wat je dient te bouwen. Wat mij als eerste opvalt is dat je IGMP proxy allemaal losse subnetten bevat. Gemakkelijker is de grote subnetten eindigend op /1, dat scheelt je beheer als KPN iets wijzigt later.

Als je nu wel TV kunt kijken is het stap 2 om naar FW rules te kijken. Je hebt op je IPTV_WAN heel veel losse rules. Je kan hier 1x een IGMP rule van maken met source *any en dan dest 244.0.0.0/4 je weet immers niet waar de stream vandaan komt.

EDIT: bouw de howto van page 1 maar na, als het dan niet werkt is het fijner troubleshooten.

Ik zou dat eerst gelijk trekken:

[ Voor 8% gewijzigd door stormfly op 05-09-2021 12:39 ]

[Lawrentium]

Config is inmiddels identiek. Nog steeds dezelfe problemen.

Verschillende zenders doen het niet, daarnaast is het niet mogelijk te pauzeren/terug te kijken.

[Lawrentium]

Ben inmiddels wat verder. Alle zenders werken inmiddels stabiel na het aanpassen van de DNS servers voor IPTV_LAN.

Het enige wat nu niet werkt is het pauzeren en terugkijken.

[ik222]

Laten de firewall logs iets zien?

[stormfly]

Lawrentium schreef op zondag 5 september 2021 @ 20:59:
Ben inmiddels wat verder. Alle zenders werken inmiddels stabiel na het aanpassen van de DNS servers voor IPTV_LAN.

Het enige wat nu niet werkt is het pauzeren en terugkijken.

Je nat alles naar vlan 4, je mist internet in je stb vlan. Edit: keuze wordt gemaakt via routing.

[ Voor 22% gewijzigd door stormfly op 05-09-2021 22:23 ]

[Lawrentium]

stormfly schreef op zondag 5 september 2021 @ 22:04:
[...]


Je nat alles naar vlan 4, je mist internet in je stb vlan.

Volgens mij niet? Zie de laatste rij:
WAN 192.168.10.1/24 WAN_address

ik222 schreef op zondag 5 september 2021 @ 21:33:
Laten de firewall logs iets zien?

Dit valt me nu wel op, wat ik eerder niet zag staan.
Er wordt verkeer geblokkeerd naar 195.121.79.24:443 afkomstig van de STB.

[Lawrentium]

Inmiddels zijn de problemen weer terug. Ik snap er niets meer van. Bij het kiezen van RTL4 lijkt de STB vast te lopen voor circa 30 seconden. Daarna blijf je zwart beeld houden tot je een andere zender kiest.

Net even snel de Xperiabox geplaatst. Dan werkt RTL4 weer. Als ik deze dan weer vervang door m'n firewall blijft alles werken.

Niets te vinden in de firewall logs.

Is bij jullie in de STB het IP adres trouwens ook 0.0.0.0? Zodra ik de Xperiabox plaats krijg ik hier een 10.x.x.x range.

[casemodder]

Ik zal hem hier ook even posten om de info een beetje bij elkaar te houden.

Ben 3 dagen aan het vechten geweest met KPN IPTV wat ineens niet meer werkte op PFsense.

Oplossing:

Ik heb bij Outbound NAT een regel toegevoegd en ik kon 213.75.112.1 weer pingen, en werkte mijn STB's dus ook weer

Hoe het kan: geen idee ik had niets gewijzigd aan mijn setup maar goed het werkt weer dus

Als je KPN STB op 85% blijft hangen en volgt met error 561
check of je op het STB VLAN 213.75.112.1 kunt pingen zo niet check je firewall rules/NAT

[ik222]

casemodder schreef op zondag 7 november 2021 @ 13:13:
Ik zal hem hier ook even posten om de info een beetje bij elkaar te houden.

Ben 3 dagen aan het vechten geweest met KPN IPTV wat ineens niet meer werkte op PFsense.

Oplossing:

Ik heb bij Outbound NAT een regel toegevoegd en ik kon 213.75.112.1 weer pingen, en werkte mijn STB's dus ook weer

Hoe het kan: geen idee ik had niets gewijzigd aan mijn setup maar goed het werkt weer dus

Als je KPN STB op 85% blijft hangen en volgt met error 561
check of je op het STB VLAN 213.75.112.1 kunt pingen zo niet check je firewall rules/NAT

[Afbeelding]

Dat heeft er mee te maken dat KPN regio voor regio aanpassingen aan het doen lijkt in de DHCP server. Die stuurt voortaan in de DHCP Offer geen default gateway meer mee, en dat zorgt er dan weer voor dat pfSense niet meer automatisch een uitgaande NAT regel aanmaakt voor de IPTV interface. Hetgeen jij beschrijft is daarvoor dan dus inderdaad de oplossing.

Aanvullend hierop zijn er ook howto's in omloop geweest die bij de DHCP client de "routers" optie als required specificeren. Als je dat gedaan hebt moet je dat ook weghalen als required om na de aanpassing überhaupt nog een lease te krijgen.

[casemodder]

ik222 schreef op zondag 7 november 2021 @ 13:38:
[...]

Dat heeft er mee te maken dat KPN regio voor regio aanpassingen aan het doen lijkt in de DHCP server. Die stuurt voortaan in de DHCP Offer geen default gateway meer mee, en dat zorgt er dan weer voor dat pfSense niet meer automatisch een uitgaande NAT regel aanmaakt voor de IPTV interface. Hetgeen jij beschrijft is daarvoor dan dus inderdaad de oplossing.

Aanvullend hierop zijn er ook howto's in omloop geweest die bij de DHCP client de "routers" optie als required specificeren. Als je dat gedaan hebt moet je dat ook weghalen als required om na de aanpassing überhaupt nog een lease te krijgen.

Ik had inderdaad al een vermoeden dat mijn IPTV dhcp IP anders was als eerder. Dit sluit daar dus bij aan.

[Lakemond]

Okay.... sinds een paar dagen heb ik een uitdaging met mijn STB. Kon niet meer terug kijken en dus dacht ik: herstarten.. en sindsdien kom ik niet meer verder dan 85% en blijft deze hangen op een Fout 563.

Tot op heden (nu bijna 4 maanden) heeft deze configuratie zonder problemen gewerkt echter zit ik nu even met de handen in het haar vwb een oplossing.

Ik dacht dat voorgaande bericht mijn oplossing zou zijn... maar helaas niet.

Ik ben dus dringend op zoek naar mensen met een oplossing of vergelijkbaar recent probleem. Heb nu al aardig wat uurtjes er in zitten.

Overigens kleine toelichting op de setup:

FTU naar Dedicated PF sense Box.
Totaal 2 interfaces:
Interface 1: WAN -- > FTU
Interface 2: LAN --> Switch

[ Voor 12% gewijzigd door Lakemond op 10-11-2021 16:08 ]

[ik222]

Lakemond schreef op woensdag 10 november 2021 @ 16:06:
Okay.... sinds een paar dagen heb ik een uitdaging met mijn STB. Kon niet meer terug kijken en dus dacht ik: herstarten.. en sindsdien kom ik niet meer verder dan 85% en blijft deze hangen op een Fout 563.

Tot op heden (nu bijna 4 maanden) heeft deze configuratie zonder problemen gewerkt echter zit ik nu even met de handen in het haar vwb een oplossing.

Ik dacht dat voorgaande bericht mijn oplossing zou zijn... maar helaas niet.

Ik ben dus dringend op zoek naar mensen met een oplossing of vergelijkbaar recent probleem. Heb nu al aardig wat uurtjes er in zitten.

Heb je wel nog een IP adres op je IPTV interface (VLAN 4)?

[Lakemond]

@ik222

[Lakemond]

@ik222 Ik heb zoals je ziet wel een IP adres verkregen. Ik heb ook nog even een edit gedaan in mn opst met mijn setup. Ik draai PFsense 2.5.2 overigens

[ik222]

@Lakemond Oke dus dat is goed, maak ook eens een screenshot van je outgoing NAT configuratie? En check ook even of de route naar die specifieke /21 in je route tabel staat?

[ Voor 3% gewijzigd door ik222 op 10-11-2021 16:14 ]

[Lakemond]

@ik222

[Lakemond]

@ik222 route tabel

[ik222]

@Lakemond Ziet er ook allemaal goed uit... Er wordt ook niets relevante geblokkeerd volgens de firewall log? Anders voor de zekerheid sowieso je pfSense een keer herstarten. Heb één keer eerder gezien dat die de weg kwijt raakte na het aanpassen van NAT regels.

[Lakemond]

@ik222

en deze ook nog maar even:

[Lakemond]

@ik222 Na het aanmaken van de NAT rule niet opnieuw gestart (inmiddels eerder wel al vaker gedaan....) zal t even proberen je weet t nooit.

[ik222]

@Lakemond De 2e firewall regel moet als destination 224.0.0.0/4 hebben al doet die bij jou sowieso niets vanwege de regel erboven. En ook bij de onderste 2 regels moet de destination 224.0.0.0/4 zijn en dus niet /8 al zal ook dat je huidige issues niet verklaren verder.

En daarnaast, in dit verband zijn ook je uitgaande firewall regels mogelijk interessant.

[ Voor 14% gewijzigd door ik222 op 10-11-2021 16:35 ]

[Lakemond]

@ik222 geeft KPN recent iets gewijzigd? Ik vindt ze namelijk erg summier in hun informatievoorziening. Nou weet ik dat ze t liefst hebben dan je hun “eigen” hardware gebruikt. Maar er zou toch ergens een changelog moeten zijn. Hoe moet je dit anders weten

[ik222]

Lakemond schreef op woensdag 10 november 2021 @ 16:35:
@ik222 geeft KPN recent iets gewijzigd? Ik vindt ze namelijk erg summier in hun informatievoorziening. Nou weet ik dat ze t liefst hebben dan je hun “eigen” hardware gebruikt. Maar er zou toch ergens een changelog moeten zijn. Hoe moet je dit anders weten

Er is niets gecommuniceerd inderdaad, ik ben daar ook alleen achter gekomen toen ik ging troubleshooten omdat het stuk was...

Voor wat er nu anders is zie ik222 in "OPNsense & pfSense KPN/Telfort IPTV how-to" Maar voor zover ik kan zien heb jij de juiste aanpassingen gedaan.

[ Voor 15% gewijzigd door ik222 op 10-11-2021 16:38 ]

[stormfly]

Je kunt ook vergelijken met de start post.

[Lakemond]

ik222 schreef op woensdag 10 november 2021 @ 16:36:
[...]

Er is niets gecommuniceerd inderdaad, ik ben daar ook alleen achter gekomen toen ik ging troubleshooten omdat het stuk was...

Je zou dan zeggen dat er toch wat meer mensen last van moeten hebben.....

Stond deze NAT rule er eerst wel automatisch tussen dan?

Maar...... geloof het of niet ondertussen... ik denk dat de NAT aanapssing zonder reboot geen gek idee was.
Hij lijkt weer te leven

Dank voor je snelle reacties en meedenken.

Heb natuurlijk wel e.e.a. recht getrokken naderhand. Maar ga ervan uit dat de NAT icm reboot het gedaan heeft.

[ik222]

Goed dat het weer werkt

Het punt is dus dat pfSense in de automatic of hybrid stand alleen uit zichzelf regels aanmaakt voor interfaces waarop een default gateway gedetecteerd wordt. KPN stuurt dus sinds recente aanpassingen de routers optie niet meer mee in hun DHCP Offer waardoor dat dus niet meer vanzelf gebeurt voor die interface.

[stormfly]

ik222 schreef op woensdag 10 november 2021 @ 16:45:
Goed dat het weer werkt

Het punt is dus dat pfSense in de automatic of hybrid stand alleen uit zichzelf regels aanmaakt voor interfaces waarop een default gateway gedetecteerd wordt. KPN stuurt dus sinds recente aanpassingen de routers optie niet meer mee in hun DHCP Offer waardoor dat dus niet meer vanzelf gebeurt voor die interface.

Top dat je dit gevonden hebt, daarom ben ik zo trots op de startpost (mede door jouw hulp). Deze voorziet namelijk in allerhande aanpassingen, en voorkomt outages. Denk aan dit voorbeeld, maar ook aan het aanpassen van source subnetten, dat is bij de guide ook afgevangen door een wijdere range op te nemen.

Tik dit bewust een voor nieuwe gebruikers.

[Lakemond]

ik222 schreef op woensdag 10 november 2021 @ 16:45:
Goed dat het weer werkt

Het punt is dus dat pfSense in de automatic of hybrid stand alleen uit zichzelf regels aanmaakt voor interfaces waarop een default gateway gedetecteerd wordt. KPN stuurt dus sinds recente aanpassingen de routers optie niet meer mee in hun DHCP Offer waardoor dat dus niet meer vanzelf gebeurt voor die interface.

Leuk verhaal... toch jammer dat je daar "spontaan" achter moet komen.

Ik heb nu tijdens de troubleshooting op iedere firewall rule de IP options aangezet. Dus zowel op de LAN als ook op de IPTV rules.

Deze is toch in principe alleen nodig op de IGMP rule(s)?

[ik222]

Lakemond schreef op woensdag 10 november 2021 @ 16:51:
[...]


Leuk verhaal... toch jammer dat je daar "spontaan" achter moet komen.

Ik heb nu tijdens de troubleshooting op iedere firewall rule de IP options aangezet. Dus zowel op de LAN als ook op de IPTV rules.

Deze is toch in principe alleen nodig op de IGMP rule(s)?

Klopt, IP options hoeft alleen aan op de IGMP regels.

@stormfly Ik zou, in het kader van outages voorkomen, in de TS de destination nog naar any zetten op de outgoing NAT regel. Dat heeft namelijk geen zin en kan bij eventuele aanpassing van de classless routes wel voor issues zorgen.

[ Voor 20% gewijzigd door ik222 op 10-11-2021 16:57 ]

[Lakemond]

Deze zijn inmiddels aangepast.

@ik222 Overigens ben ik op diverse posts ooit afgegaan v.w.b. de IP reeksen 213.75.0.0 en 217.166.0.0 ik heb deze overigens ook nooit in de KPN informatie/documentatie gezien... is er een "goede" informatiebron voor deze zaken. Want de pagina van KPN met informatie voor je eigen router/firewall is wel heel summier.

[stormfly]

Lakemond schreef op woensdag 10 november 2021 @ 16:59:
[Afbeelding]

Deze zijn inmiddels aangepast.

@ik222 Overigens ben ik op diverse posts ooit afgegaan v.w.b. de IP reeksen 213.75.0.0 en 217.166.0.0 ik heb deze overigens ook nooit in de KPN informatie/documentatie gezien... is er een "goede" informatiebron voor deze zaken. Want de pagina van KPN met informatie voor je eigen router/firewall is wel heel summier.

Nee dat denk ik niet, het is vooral reverse engineering en Wireshark.

ik222 schreef op woensdag 10 november 2021 @ 16:52:
[...]

Klopt, IP options hoeft alleen aan op de IGMP regels.

@stormfly Ik zou, in het kader van outages voorkomen, in de TS de destination nog naar any zetten op de outgoing NAT regel. Dat heeft namelijk geen zin en kan bij eventuele aanpassing van de classless routes wel voor issues zorgen.

Ik heb al even TV via NLziet, kan het niet helemaal goed valideren. Als je source= STBvlan en destination= any neerzet dan is het internet in je STBvlan toch defect?

[Vorkie]

stormfly schreef op woensdag 10 november 2021 @ 19:14:
[...]


Nee dat denk ik niet, het is vooral reverse engineering en Wireshark.


[...]


Ik heb al even TV via NLziet, kan het niet helemaal goed valideren. Als je source= STBvlan en ook destination= any neerzet dan is het internet in je STBvlan toch defect?

Die routes komen van de dhcp op je IPTV wan. Op een Mikrotik neemt ie die automatisch mee.

Het is dus niet uit de lucht gegrepen :-)

[stormfly]

Vorkie schreef op woensdag 10 november 2021 @ 19:38:
[...]


Die routes komen van de dhcp op je IPTV wan. Op een Mikrotik neemt ie die automatisch mee.

Het is dus niet uit de lucht gegrepen :-)

Yes dat is hem, dat staat los van het verwijderen van de gateway op vlan 4? De route insert via DHCP bevat ook de next-hop?

[ik222]

stormfly schreef op woensdag 10 november 2021 @ 19:14:
[...]


Nee dat denk ik niet, het is vooral reverse engineering en Wireshark.


[...]


Ik heb al even TV via NLziet, kan het niet helemaal goed valideren. Als je source= STBvlan en destination= any neerzet dan is het internet in je STBvlan toch defect?

Nee want een NAT regel is geen routering. De routering wordt bepaald door de route die via RFC3433 gepusht wordt. De NAT regel zegt ook met een any bij destination alleen dat op alles wat over de IPTV naar buiten gerouteerd wordt ook NAT moet worden toegepast.

[ik222]

Lakemond schreef op woensdag 10 november 2021 @ 16:59:
[Afbeelding]

Deze zijn inmiddels aangepast.

@ik222 Overigens ben ik op diverse posts ooit afgegaan v.w.b. de IP reeksen 213.75.0.0 en 217.166.0.0 ik heb deze overigens ook nooit in de KPN informatie/documentatie gezien... is er een "goede" informatiebron voor deze zaken. Want de pagina van KPN met informatie voor je eigen router/firewall is wel heel summier.

Die reeksen zijn ook niet perse nodig. KPN zegt feitelijk alleen dat je IGMPProxy moet draaien en UDP verkeer moet toestaan. Feitelijk kun je dus ook gewoon 0.0.0.0/0 bij IGMPProxy invullen (al accepteert pfSense dat niet in de GUI) en dan in de firewall al het UDP verkeer toestaan. Dat is ook wat de Fritzbox of Experiabox doet. Alleen voor iets meer veiligheid kun je het dus beperken, met het risico dat je ze ooit moet aanpassen.

De /21 voor de routering krijg je verder dus netjes automatisch via DHCP mee.

[ANdrode]

ik222 schreef op woensdag 10 november 2021 @ 20:21:
[...]

Die reeksen zijn ook niet perse nodig. KPN zegt feitelijk alleen dat je IGMPProxy moet draaien en UDP verkeer moet toestaan. Feitelijk kun je dus ook gewoon 0.0.0.0/0 bij IGMPProxy invullen (al accepteert pfSense dat niet in de GUI) en dan in de firewall al het UDP verkeer toestaan. Dat is ook wat de Fritzbox of Experiabox doet. Alleen voor iets meer veiligheid kun je het dus beperken, met het risico dat je ze ooit moet aanpassen.

Dan split je hem in twee /1's. Past dat wel of is de restrictie slimmer

[ik222]

ANdrode schreef op woensdag 10 november 2021 @ 21:38:
[...]


Dan split je hem in twee /1's. Past dat wel of is de restrictie slimmer

Dat kan wel en is ook wat de meeste mensen doen Alleen het stomme is dat IGMPProxy zelf wel gewoon 0.0.0.0/0 accepteert volgens mij, beperking zit echt in pfSense.

[davidoffm]

delete; niet goed gekeken, verkeerde topic

[ Voor 110% gewijzigd door davidoffm op 11-11-2021 12:41 ]