Canal Digitaal: niet alle kanalen werken na vervangen fysieke OpenWrt router door VM met OpenWrt

Afgelopen week heb ik onze fysieke OpenWrt router vervangen door een virtuele machine met OpenWrt in verband met glasvezel dat binnen enkele maanden hier geleverd gaat worden. De configuratie is 1 op 1 overgenomen van de fysieke router. Alles werkt wel weer, alleen doen sommige tv-kanalen het nu niet meer.

Wat mij opvalt is dat het IP-adres dat ik op VLAN 4 krijg, geen 10.10.12.x adres meer is (bij de fysieke router), maar nu 100.69.x.y/23 is.

In de vorige situatie kreeg mijn router van de DHCP server van Canal Digitaal via optie 121 static routes uitgedeeld voor 10.10.0.33/32, 185.24.175.0/24 en 185.41.48.0/24.

Dat lijkt nu niet langer het geval te zijn, de enige route die via VLAN 4 loopt is nu: 100.64.0.0/10.

Veel kanalen werken op dit moment, zeker diegene die via multicasting worden verspreid. Enkele kanalen doen het niet. Ik heb daarop een packet capture op de vlan 4 interface van de router gedaan en zie dit gebeuren zodra ik bijvoorbeeld naar Out TV overschakel (we hebben het pluspakket van CD):

Out TV wordt dus gedistribueerd via RTSP. Dat gebeurde bij sommige kanalen in het verleden ook wel, maar zo uit mijn hoofd liep dat verkeer dan over VLAN 4. In dit geval zou dat over VLAN 6 (internet, PPPoE) zijn, want er is geen route naar adres 185.24.175.210 over VLAN 4. De RTSP-server antwoordt kennelijk wel over het internet, want dat is te zien in de packet capture.

Over RTSP, de kernel module is geladen in de router:

root@OpenWrt01:~# lsmod | grep rtsp
nf_conntrack           77824 35 xt_connlimit,nf_conncount,xt_state,xt_nat,xt_helper,xt_conntrack,xt_connmark,xt_connbytes,xt_REDIRECT,xt_MASQUERADE,xt_CT,nft_redir,nft_nat,nft_masq,nft_flow_offload,nft_ct,nf_nat_tftp,nf_nat_snmp_basic,nf_nat_sip,nf_nat_rtsp,nf_nat_pptp,nf_nat_irc,nf_nat_h323,nf_nat_amanda,nf_nat,nf_flow_table,nf_conntrack_tftp,nf_conntrack_snmp,nf_conntrack_sip,nf_conntrack_rtsp,nf_conntrack_pptp,nf_conntrack_irc,nf_conntrack_h323,nf_conntrack_broadcast,nf_conntrack_amanda
nf_conntrack_rtsp      16384  2 nf_nat_rtsp
nf_nat                 28672 15 iptable_nat,xt_nat,xt_REDIRECT,xt_MASQUERADE,nft_redir,nft_nat,nft_masq,nft_chain_nat,nf_nat_tftp,nf_nat_sip,nf_nat_rtsp,nf_nat_pptp,nf_nat_irc,nf_nat_h323,nf_nat_amanda
nf_nat_rtsp            12288  0

Overigens heb ik geprobeerd om hierboven genoemde drie subnetten te routeren over VLAN 4, maar dan werkt er nog veel minder zenders. Kennelijk worden deze kanalen nu over internet gerouteerd naar ons huis.

In de vorige situatie werkte RTSP dan ook zonder problemen. We hebben twee ontvangers, dus een destination NAT regel in de firewall (nftables) aanbrengen gaat me niet helpen.

Mijn vragen voor nu zijn:

Heeft Canal Digitaal iets aan haar infrastructuur en werking gewijzigd?

Missen er routeringen over VLAN 4 in mijn router?

Heeft iemand met eenzelfde 100.x.y.z adres op VLAN 4 een oplossing het werkend? Ook met eigen apparatuur?

Als ik de oude router weer aansluit, krijg ik onmiddellijk mijn oude IP-adres op VLAN 4 weer, 10.10.12.x. Het liefst blijf ik nu de VM-versie van de router gebruiken.

Het is dat je het post, maar mij was het nog niet opgevallen dat de routering op vlan4 is aangepast. Ik heb wel een 100.66.x.x adres met 10.64.0.0/10 eb 10.66.0.0/20 routering op vlan4 en de rest via pppoe.

igmp proxy config voor vlan4 is ongewijzigd:

phyint vlan4 upstream  ratelimit 0  threshold 1
        altnet 185.24.175.0/24
        altnet 185.41.48.0/24
        altnet 217.166.224.0/22

Ondanks de vlan4 config in igmpproxy die nog de oude altnets heeft staan op vlan4 werkt de ontvanger hier, al gebruiken we 'm zeer beperkt. Meer dan BBC first en heel af en toe national geogfraphic hebben we niet op staan. (doet me er aan denken, ik heb nog opnames te testen)

Ik heb eigen hardware, een RPi 4, met iptables, maar geen rtsp modules. De rtso server die je noemt antwoord ook hier netjes via het pppoe interface (traceroute).

Thanks @KoffieNu voor je opmerkingen.

Ik heb nog eens verder gekeken. Wat ik zie is dat op de PPPoE-interface er verkeer binnenkomt zodra ik naar een RTSP-zender zap. Voor zover ik weet, doet de tvbox een verzoek via RTSP op poort 554 naar een server van Canal Digitaal om een stream aan te vragen. Die stream gaat inderdaad lopen en komt op de PPPoE-interface binnen:

08:47:40.573517 IP 185.24.175.210.10000 > 45.137.x.y.2010: UDP, length 1328
08:47:40.576648 IP 185.24.175.210.10000 > 45.137.x.y.2010: UDP, length 1328
08:47:40.581590 IP 185.24.175.210.10000 > 45.137.x.y.2010: UDP, length 1328
08:47:40.584109 IP 185.24.175.210.10000 > 45.137.x.y.2010: UDP, length 1328
08:47:40.588462 IP 185.24.175.210.10000 > 45.137.x.y.2010: UDP, length 1328
08:47:40.591057 IP 185.24.175.210.10000 > 45.137.x.y.2010: UDP, length 1328
08:47:40.594047 IP 185.24.175.210.10000 > 45.137.x.y.2010: UDP, length 1328

etc.

De RTSP helper kernel module kijkt, als ik goed heb, mee met het verzoek naar de RTSP-server van CD en herschrijft de IP-adressen in de packets, omdat deze hardcoded in de payload van een RTSP bericht meegaan. Dat gaat dus niet werken als je gebruik maakt van NAT. Verder zou de kernel module ook een poortje in de firewall moeten open zetten voor het inkomende verkeer, want dat is een nieuwe sessie en staat los van het RTSP stream start verzoek dat naar de CD RTSP server is gestuurd.

Kennelijk gebeurt dit niet en wordt het verkeer vermoedelijk gedropt door de firewall.

Ben het verder aan het uitzoeken.

Je hebt connection tracking aan staan. (in elk geval is de module geladen) Ik zou verwachten dat de firewall de nieuwe stream als ‘related’ herkent en zo correct door zet.

Ik zou verwachten dat de iptables een regel als onderstaande in de INPUT, OUTPUT en FORWARD secties heeft:

ACCEPT     0    --  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED

Heeft openWRT conntrack tooling in het image staan? Die kunnen wat duidelijkheid geven. (gok ik, zelf heb ik nog niet zo diep hoeven te debuggen)

OpenWrt 22.03.5 gebruikt nftables. RELATED staat zo te zien aan op de INPUT, OUTPUT en FORWARD chains:

root@OpenWrt01:~# nft list ruleset

...
chain input {
     ...
     ct state established,related accept comment "!fw4: Allow inbound established and related flows"
     ...
}

chain forward {
     ...
     ct state established,related accept comment "!fw4: Allow forwarded established and related flows"
     ...
}

chain output {
     ...
     ct state established,related accept comment "!fw4: Allow outbound established and related flows"
     ...
}

Ik heb de conntrack tool geïnstalleerd. Als ik zap naar een RTSP-kanaal dan zie ik met de tool o.a. dit:

root@OpenWrt01:~# conntrack -L | grep 185.24

...
udp      17 20 src=185.24.175.210 dst=45.137.x.y sport=10000 dport=2000 packets=20296 bytes=27520436 [UNREPLIED] src=45.137.x.y dst=185.24.175.210 sport=2000 dport=10000 packets=0 bytes=0 mark=0 use=1
...

Dit zou de TV-stream moeten zijn. Ik zie geen destination NAT naar de tv-box toe, maar weet ook niet 100% zeker of je dit met de conntrack tool kunt zien. Heb niet eerder gewerkt met dit tooltje.

Heb handmatig in de firewall een destination NAT aangemaakt naar de tv-box. In dat geval kan ik wel kijken naar de RTSP zenders. Helaas is dat nog niet de oplossing, omdat we twee STB’s in huis hebben.

Ik heb een groot vermoeden dat er een bug zit in OpenWrt 22.03.05 met betrekking tot RTSP.

Heb zojuist een nieuwe VM aangemaakt op Proxmox met daarin de laatste bleeding edge versie van OpenWrt, een snapshot versie. De configuratie heb ik 1-op-1 overgezet van de 22.03.05 versie met behulp van rsync.

Resultaat: ik kan nu weer op beide STB’s naar RTSP-zenders kijken zonder dat er handmatige destination NAT rules moeten zijn aangemaakt in de firewall. Ik heb nog steeds een 100.69.x.y adres op VLAN 4.

Voorlopig maar eens proefdraaien op deze versie en hopen dat versie 23.05.0 snel uit gaat komen.

Bedankt voor het meedenken, @KoffieNu !

Dit topic is 24 uur na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.