KPN en PFsense

[Zaratrass]

Ik ben bezig om mijn eigen firewall aan te sluiten en de experiabox eruit te gooien.

Ik heb een oude Sophos gepakt en hierop Pfsense geinstalleerd, daarbij heb ik de handleiding van venxir gevolgd. Helaas blijft bij mij de IPtv het niet doen.

Wat ik heb gedaan:
2x de complete handleiding opnieuw gevolgd en geconfigureerd.
Alle reacties gelezen en kijken of ik daar wat andere instellingen moest invoeren.
Logs door genomen

Waar ik tegenaan loop

In de reacties van Venxir blog zie ik wel een paar log meldingen van gebruikers maar, echter kom ik die niet tegen.
Wel kom ik tegen: igmpproxy 92438 select() failure; Errno(4): Interrupted system call

Als ik deze melding google lijkt het erop dat de IGMP proxy niet lijkt te starten, maar dat durf ik niet met zekerheid te zeggen.

Wat ik anders heb is dat ik poort 3/4/5 in een een bridge_LAN heb staan en dat ik geen managed switch heb voor de firewall. De kabel van NTU heb ik rechtsstreeks op de WAN poort aangesloten.

Is er iemand die mij mogelijk in de goede richting kan helpen?


Ik werk op versie pfsense 2.4.4

extra

Het volgende heb ik zojuist nog gevonden:

Dec 27 16:39:39 IPTVWAN Default deny rule IPv4 (1000000103) 213.75.167.58:37287 224.3.2.6:9875 UDP

Die kwam omdat ik het subnet van 224.0.0.0 op /16 had gezet ipv /8

Dit probleem heeft het alleen niet opgelost

[ Voor 18% gewijzigd door Zaratrass op 27-12-2018 16:55 ]

[ik222]

Die handleiding is niet meer helemaal actueel, KPN heeft namelijk een paar maanden terug een extra subnet (een deel van 217.166.0.0/16) in gebruik genomen als multicast source voor de zenders. Dat /16 subnet moet je dus nog toevoegen aan de firewall + IGMPProxy configuratie.

Zie ik222 in "[KPN Glasvezel] Ervaringen & Discussie - Deel 2"

[Zaratrass]

ik222 schreef op donderdag 27 december 2018 @ 17:16:
Die handleiding is niet meer helemaal actueel, KPN heeft namelijk een paar maanden terug een extra subnet (een deel van 217.166.0.0/16) in gebruik genomen als multicast source voor de zenders. Dat /16 subnet moet je dus nog toevoegen aan de firewall + IGMPProxy configuratie.

Zie ik222 in "[KPN Glasvezel] Ervaringen & Discussie - Deel 2"

Ik heb het zojuist gewijzigd, helaas geen resultaat.
Nu wel meldingen in log.



extra
Ik heb de receiver van KPN al meer dan 2 jaar niet aangesloten gehad.

[ Voor 6% gewijzigd door Zaratrass op 27-12-2018 17:33 ]

[ik222]

Heb je 213.75.0.0/16 wel ook nog in de upstream subnets staan en staat je upstream interface überhaupt goed ingesteld? Je log meldingen lijken er namelijk op te duiden dat een van beide niet in orde is...

Post anders eens een screenshot van je IGMPProxy configuratie? En je hebt neem ik aan wel al netjes een 10.x.x.x adres gekregen vanuit KPN op em0.4?

[ Voor 13% gewijzigd door ik222 op 27-12-2018 17:48 ]

[Zaratrass]

ik222 schreef op donderdag 27 december 2018 @ 17:42:
Heb je 213.75.0.0/16 wel ook nog in de upstream subnets staan en staat je upstream interface überhaupt goed ingesteld? Je log meldingen lijken er namelijk op te duiden dat een van beide niet in orde is...

Post anders eens een screenshot van je IGMPProxy configuratie? En je hebt neem ik aan wel al netjes een 10.x.x.x adres gekregen vanuit KPN op em0.4?

Ik had die er wel uit gegooid. Ik heb wel een 10.x.x.x IP-adres

Onderstaande screens nadat ik 213.75.0.0/16 heb toegevoegd:

log:



IGMP:



firewall:



Ik heb er ATM wel een switch (netgear proSAFE GS108Ev3) tussen omdat m'n vriendin tv wil kijken.
IGMP snooping staat aan op de netgear

[ Voor 10% gewijzigd door Zaratrass op 27-12-2018 18:21 ]

[ik222]

IGMPProxy is nu goed en draait zo te zien.

Die onderste 2 regels kunnen weg, die heb je niet nodig. Bij de 2 regels daarboven moet je zorgen dat de destination 224.0.0.0/4 is en niet /8 zoals bij 1 regel staat. Op de bovenste regel kan je eventueel als source 10.0.0.0/8 invullen maar * werkt ook. Daarnaast hoeft "allow options" alleen op de bovenste IGMP regel aan. Daarmee zijn de ITVWAN firewall regels dan ook goed.

Maar hoe zien je firewall regels vanaf BRIDGELAN eruit? Je hebt daar ook een firewall regel nodig die IGMP inclusief options toestaat naar 224.0.0.0/4.

Als het dan nog niet werkt moet je even aangeven wat er precies niet werkt en welke foutcode je eventueel krijgt.

[Zaratrass]

ik222 schreef op donderdag 27 december 2018 @ 18:54:
IGMPProxy is nu goed en draait zo te zien.

Die onderste 2 regels kunnen weg, die heb je niet nodig. Bij de 2 regels daarboven moet je zorgen dat de destination 224.0.0.0/4 is en niet /8 zoals bij 1 regel staat. Op de bovenste regel kan je eventueel als source 10.0.0.0/8 invullen maar * werkt ook. Daarnaast hoeft "allow options" alleen op de bovenste IGMP regel aan. Daarmee zijn de ITVWAN firewall regels dan ook goed.

Maar hoe zien je firewall regels vanaf BRIDGELAN eruit? Je hebt daar ook een firewall regel nodig die IGMP inclusief options toestaat naar 224.0.0.0/4.

Als het dan nog niet werkt moet je even aangeven wat er precies niet werkt en welke foutcode je eventueel krijgt.

Heb ik aangepast. dit zijn de bridgelan FW rules.



Ik krijg code 561 op de receiver ben nu de volgende guide aan het volgen

edit:

Na een reset van de TV-receiver werkt het.

Bedankt voor de hulp!

Ik ga me eens verdiepen wat IGMP exact is!

[ Voor 6% gewijzigd door Zaratrass op 27-12-2018 19:38 ]

[marigo]

Zaratrass schreef op donderdag 27 december 2018 @ 16:34:

Wel kom ik tegen: igmpproxy 92438 select() failure; Errno(4): Interrupted system call

Wat heb je gefixt om deze melding niet meer te zien in "system logs"?
Ik heb dezelfde melding in OPNsense 19.1.10_1, maar wat ik ook probeer de melding blijft terug komen.

Ik heb nu wel even beeld, maar na 3 seconden heb ik een freeze.

[ik222]

@marigo Die regel zie je bijvoorbeeld al bij een herstart van IGMPProxy, die regel op zich in de logs duidt dus niet op een probleem.

Verder is het een beetje gissen zonder screenshots van je config. Maar heb je alle firewall rules en IGMPProxy config goed staan?

[marigo]

Ik zal even wat screenshots maken. Dus die melding kan ik negeren?

Igmp proxy:
https://imgur.com/a/74aRBqj

Fw rules IPTV-WAN:
https://imgur.com/Sy0djKK

Fw rule IPTV-LAN:
https://imgur.com/vh6jzR8

Ik heb IGMP snooping aan staan op mijn IPTV-LAN.
Met een packet capture zie ik ook geen IGMP berichten voorbij komen over de iptv-wan interface.

NAT-Rules:
https://imgur.com/j8Nxokz

IPTV WAN interface DHCP options:
https://imgur.com/4sHDKtr

[ Voor 85% gewijzigd door marigo op 03-09-2019 21:53 ]

[ik222]

Die melding op zich wel inderdaad, je ziet wel dat IGMPProxy gewoon netjes als service draait?

Heb je op de IGMP firewall regels "allow options" aan staan? Je hebt zo'n regel die expliciet ook options toestaat nodig voor IGMP. Zowel van IPTVWAN naar IPTVLAN als andersom.

Als het dan nog niet werkt, wat laten je firewall logs zien?

/Edit: Die outbound NAT rules kloppen niet zo te zien, je moet al het verkeer uitgaand NAT'en en niet alleen verkeer naar die 217.x subnets.

[ Voor 17% gewijzigd door ik222 op 03-09-2019 21:55 ]

[marigo]

Ik heb die "allow options" idd aan staan voor de IGMP rules.

Firewall logs laten het verkeer netjes door. Wordt voor deze interfaces niks geblockt.

Verschillende tutorials gevolgd, maar het licht gaat helaas nog niet aan.

[ik222]

Oke maar van LAN naar WAN zie ik geen specifieke IGMP rule? Ook die heb je nodig met options.

En je die outbound NAT rules al aangepast? Zie mijn edit hierboven, dat gaat zo niet werken.

[marigo]

van LAN naar WAN heb ik een * any voor de protocollen. Daar valt IGMP dan toch ook in?

NAT rule aangepast:
https://imgur.com/iHgCBZs

betere screenschot:
https://imgur.com/JzPodTf

Heb even beeld, dan een freeze en weer even beeld en dan stopt het.

[ Voor 30% gewijzigd door marigo op 03-09-2019 22:10 ]

[ik222]

Ja op zich wel, maar heb je daarop dan ook options aan staan?

[marigo]

Yep, options in "advanced options" staat aan.

Heb het net maar even tijdelijk opgelost door de Experiabox aan te sluiten met alleen Vlan4 op de trunk vd switch richting de WAN poort van de Experia. En de STB op een van de LAN poorten aan te sluiten.

Tv werkt dan iig. Weer tijdelijk voldaan aan de WAF.

Vanavond maar weer even verder klooien.

[marigo]

@ik222
Hoe heb jij die distance van de default route verhoogd in OPN- of PFsense die je krijgt van het IPTV netwerk.
Misschien dat het daar fout gaat.

[ik222]

marigo schreef op woensdag 4 september 2019 @ 20:23:
@ik222
Hoe heb jij die distance van de default route verhoogd in OPN- of PFsense die je krijgt van het IPTV netwerk.
Misschien dat het daar fout gaat.

Je krijgt als het goed is geen default route vanuit het IPTV netwerk, enkel een specifieke /21 (213.75.112.0/21) wordt via RFC3442 gepusht.

[ Voor 3% gewijzigd door ik222 op 04-09-2019 20:57 ]

[marigo]

Ik krijg deze route gepushed vanaf het IPTV netwerk:

ipv4 213.75.112.0/21 10.14.74.1 UGS 0 1500 vtnet6 IPTVWAN

Deze zie ik netjes in het "route" overzicht.
Volgens mij krijg ik die via de opties "subnet-mask, routers, classless-routes" welke onder "Request Options" in de DHCP client staan.

EDIT: Wat ik vanavond ook nog heb gezien is dat ik de STB ook nog bridged kan aansluiten, maar mis dan natuurlijk de Internet diensten.

Mijn interne netwerk voor de STB's is 10.0.100.0/24. Via de uitleg op netwerkje.com moet er voor dit source netwerk alleen geNAT worden voor de 213.75.112.0/21 en 217.166.0.0/16. Deze netwerken moeten dus bereikbaar zijn in het IPTV netwerk (VLAN4). Echter voor het 217.166.0.0/16 netwerk heb ik geen route staan die naar het IPTV netwerk, dus die wordt naar Internet geleid.

De STB's kunnen in het netwerk 10.0.100.0/24 gebruik maken van Internet.

[ Voor 52% gewijzigd door marigo op 04-09-2019 21:07 ]

[ik222]

Dat bridged gaat uitgefaseerd worden, KPN en XS4ALL hebben klanten die dat gebruiken recent al aangeschreven dat ze hun setup moeten aanpassen.

[marigo]

Ok, check. Het werkt nu wel via de experiabox, maar ben aan het zoeken waar het nu fout loopt.
Als het op mijn 2e STB nog even via bridged werkt, dan komt dat nu wel goed uit.

Kun je mss nog eens naar bovenstaande setup kijken?

[ Voor 13% gewijzigd door marigo op 04-09-2019 21:18 ]

[ik222]

Naar 217.166.0.0/16 heb je geen route nodig, daar zitten enkel multicast sources in. Dus je moet verkeer vanaf deze bronnen accepteren maar meer niet. Om dat te accepteren moet hij in je firewall rules en IGMPProxy config staan.

Verder je het beste simpelweg al het verkeer wat via ITVWAN naar buiten gaat NAT'en. In de praktijk is dat dan enkel verkeer waarvoor je de route hebt.

Maar als alles echt goed staat dan moet het werken zou ik zeggen. Al werk ik zelf met pfSense en niet met OpnSense.

[marigo]

Ok, dus de outbound rule zou er zo uit moeten zien?

Interface = IPTVWAN (Vlan4)
Source net = IPTVLAN (VLAN waar de STB in hangt)
Destination net = Any (alles wordt dan geNAT)
Translation taget = IP adres van IPTVWAN interface

[ik222]

marigo schreef op woensdag 4 september 2019 @ 21:41:
Ok, dus de outbound rule zou er zo uit moeten zien?

Interface = IPTVWAN (Vlan4)
Source net = IPTVLAN (VLAN waar de STB in hangt)
Destination net = Any (alles wordt dan geNAT)
Translation taget = IP adres van IPTVWAN interface

Ja dat is prima.

[marigo]

Hmmm, ok.

Ik denk dat het ook wel goed staat allemaal, maar dat er toch een issue is met igmpproxy.
Nog steeds heb ik even beeld en geluid, maar daarna bevriest alles.

On demand services werken wel zoals een film bekijken ofzo.

OPNsense draait bij mij in een kvm op Proxmox met vlan tagging en ik lees dat meer mensen hier wat problemen mee hebben.

https://forum.opnsense.org/index.php?topic=4824.0

[ik222]

Dat met VLAN tagging zou opgelost moeten zijn in de meest recente versie.

Kun je anders eens IGMPProxy stoppen en vanaf de CLI in interactive mode met alle debug output aan draaien? In die link staat hoe dat moet. Ben benieuwd naar de output, het probleem wat je hebt is 100% een IGMPProxy of firewall probleem en dat laatste lijkt het me niet gezien je screenshots.

[ Voor 26% gewijzigd door ik222 op 04-09-2019 22:03 ]

[marigo]

Hmm daar zie ik een hoop "ignoring" voorkomen.Ik ga hier wel verder induiken.
Het lichtje gaat bijna uit.

thx voor zover. het komt goed.

code:

root@opnsense:~ # igmpproxy -d -vvv /usr/local/etc/igmpproxy.conf
adding VIF, Ix 0 Fl 0x0 IP 0x0164000a vtnet2, Threshold: 1, Ratelimit: 0
adding VIF, Ix 1 Fl 0x0 IP 0xc14a0e0a vtnet6, Threshold: 1, Ratelimit: 0
joinMcGroup: 224.0.0.2 on vtnet2
joinMcGroup: 224.0.0.22 on vtnet2
RECV V2 member report   from 10.0.100.1      to 224.0.0.2
The IGMP message was from myself. Ignoring.
RECV V2 member report   from 10.0.100.1      to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV Membership query   from 10.0.100.1      to 224.0.0.1
Inserted route table entry for 224.3.2.6 on VIF #-1
RECV V2 member report   from 10.0.100.1      to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V2 member report   from 10.0.100.108    to 224.3.2.6
Updated route entry for 224.3.2.6 on VIF #0
Adding MFC: 213.75.167.58 -> 224.3.2.6, InpVIf: 1
joinMcGroup: 224.3.2.6 on vtnet6
RECV V2 member report   from 10.0.100.108    to 224.0.252.134
Inserted route table entry for 224.0.252.134 on VIF #0
joinMcGroup: 224.0.252.134 on vtnet6
RECV V3 member report   from 10.14.74.193    to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V3 member report   from 10.14.74.193    to 224.0.0.22
The IGMP message was from myself. Ignoring.
RECV V2 member report   from 10.0.100.1      to 224.0.0.2
The IGMP message was from myself. Ignoring.
The IGMP message was local multicast. Ignoring.
RECV Membership query   from 10.0.100.1      to 224.0.0.1
^Cselect() failure; Errno(4): Interrupted system call
Got a interrupt signal. Exiting.
Removing MFC: 213.75.167.58 -> 224.3.2.6, InpVIf: 1
leaveMcGroup: 224.3.2.6 on vtnet6
leaveMcGroup: 224.0.252.134 on vtnet6
All routes removed. Routing table is empty.
Shutdown complete....

[ik222]

Op zich zie ik daarin niets raars voorbij komen... Misschien eens kijken of je kan Sniffen op de IPTVWAN interface...

[marigo]

Heb ik gedaan, daar zie ik wel iets vreemds.

De (multicast) source stuurt de stream die wordt opgevraagd naar het IP adres wat ik via de DHCP client op de IPTVWAN interface heb gekregen.

code:

Source          Destination
213.75.117.136  10.14.74.193    UDP 1372    50270 → 25333 Len=1330

Terwijl de stream naar het multicast adres gestuurd moet worden. Het werkte vanavond even, maar ik weet ook waarom het werkte. Op de tweede STB (die ik tijdelijke even in bridge mode heb gezet) werd deze stream gekeken. Toen deze STB werd uitgezet stopte de stream ook op mijn "routed" STB. De weg vanaf de multicast source naar mijn interne netwerk staat dus wel goed.

Dit was de stream die ik "routed" kon ontvangen

code:

Source          Destination
217.166.226.136 224.0.252.136   UDP 1370    49152 → 7272 Len=1328

Lijkt dat het ergens in de translatie nog niet helemaal goed gaat.
Ik ga nog even verder zoeken. Mocht je nog tips hebben, dan hoor ik ze graag.

[ik222]

Die stream naar je IPTVWAN adres is hoogstwaarschijnlijk de tijdelijke unicast stream. Als je zapt naar een kanaal wordt eerst de stream als unicast geladen en na een paar seconden wordt naar multicast geschakeld. Vandaar ook dat je een paar seconden beeld hebt als IGMP niet werkt.

Dat het wel werkt als je bridged een stream open heb staan betekent dat IGMP vanaf je LAN fout gaat. Zie je echt niets door een firewall geblokkeerd worden, en zie je IGMP verkeer naar buiten gaan?

[marigo]

In de firewall wordt er niks geblokkeerd.

Ik denk dat de config in OPNsense wel goed staat. Zie de IGMP berichten vanaf de STB geproxied worden via de IGMP proxy naar het IPTV-WAN

Echter via een dump zie ik dat de stream wordt opgezet naar het unicast adres die ik via DHCP heb verkregen op het IPTV-WAN (Vlan4). Dit zou als destination een 224.x.x.x adres moeten zijn. Ik denk dat het hier fout gaat.
Die unicast stream zie ik ook heel even (dan heb ik beeld en geluid), dan stopt het (waarschijnlijk zou die omschakeling dan naar 224.x.x.x dan uitgevoerd moeten worden), maar daarna volgt nog een stukje van de stream naar het unicast adres en hierna stopt het. Heb dan alleen de melding. "Zap naar een andere zender"

De omschakeling van van unicast naar het multicast adres gaat niet goed. Dat kan ik zien in een capture en live op de tv. Zodra de stream over wil schakelen naar multicast dan bevriest het beeld. Daarna wordt dit nog een keer geprobeerd en stopt het.

Het maakt ook niet uit naar welke zender ik schakel de unicast stream probeert na enige seconden de multicast stream op te zetten naar 224.3.2.6

213.75.167.58.37287 > 224.3.2.6.9875

Gevonden in deze post:
BigEagle in "Zelfbouw project: Firewall / Router / AP"

Had igmp snooping ook aan staan in Vlan4. Dat heb ik dus nu nog alleen aan staan in het Vlan waar de decoders in hangen. Op mijn TP-Link TL-SG1016DE moet ik igmp snooping ook UIT laten staan anders bevriest het beeld weer.

Werkt nu!!! Heel erg blij mee.

[ Voor 65% gewijzigd door marigo op 09-09-2019 19:22 ]