Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    [HowTo] MagentaTV mit pfSense 2.4.5

    Deutsch
    howto magentatv
    10
    42
    16.8k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      DrPhreak @maclake77
      last edited by

      @maclake77 @maclake77
      Hallöchen, wenn ich das auf deinem letzten Screen richtig sehe, ist die IPcv4 UDP Regel nicht korrekt angelegt.
      Destination müsste hier 232.0.0.0/16 sein und nicht 224.0.0.0/4

      Ich weiß nicht, ob du schon eine Lösung gefunden hast,aber das ist mir so beim druchgehen aufgefallen.

      Grüße
      DrPhreak

      1 Reply Last reply Reply Quote 0
      • S
        speedAmaster
        last edited by speedAmaster

        Hi,
        ich bin leider ebenfalls am verzweifeln.
        Meine Config:
        WAN2.PNG
        MAGENTA.PNG
        IGMP proxy.PNG
        Wie ihr seht versuche ich meinen Magenta Reciever im MAGENTA VLAN zum Laufen zu bringen. Meine pfSense ist hinter meiner fritzbox (doppel NAT?).
        Nach dem Kanalumschalten (UDP burst funktioniert) ruckelt mein TV Bild (vermutlich durch IGMP Problem) und nach einigen Sekunden kommt die Verbindungfehlermeldung.
        Kann mir Jemand weiterhelfen? Wäre ein große Hilfe!
        Danke
        speedAmaster

        ? 1 Reply Last reply Reply Quote 0
        • ?
          A Former User @speedAmaster
          last edited by

          @speedamaster, in wan it has 2 rules by default.

          S 1 Reply Last reply Reply Quote 0
          • S
            speedAmaster @A Former User
            last edited by

            @silence Hey, aren't there already two default rules in WAN? See "allow IGMP for Magenta" and "allow UDP for Magenta"? Do I need more rules or did I attach the wrong Source-/ Dest.-IP-Ranges? I'm at a loss. Thanks for your effort!

            ? 1 Reply Last reply Reply Quote 0
            • ?
              A Former User @speedAmaster
              last edited by

              @speedamaster said in [HowTo] MagentaTV mit pfSense 2.4.5:

              @silence Hey, aren't there already two default rules in WAN? See "allow IGMP for Magenta" and "allow UDP for Magenta"? Do I need more rules or did I attach the wrong Source-/ Dest.-IP-Ranges? I'm at a loss. Thanks for your effort!

              In your blocking rule (configure logs) so that you can record the problem and then it will be easier to solve it.

              S 1 Reply Last reply Reply Quote 0
              • E
                EuroPC @arnog
                last edited by EuroPC

                @arnog Hallo,

                ich habe mir gerade eine pfSense Netgate2100 zugelegt, da diese im Gegensatz zur DMP ordentlich mit VPNs umgehen kann, was aber hier nicht das Problem ist.

                Deiner Anleitung um Entertain zum Laufen zu bekommen bin ich soweit gefolgt.

                Leider stoppt Entertain und friert nach kurzer Zeit ein.
                Du schreibst, dass pfSense das VLAN- Tagging bei Dir übernimmt. Wo stelle ich das ein?

                Mein Setup ist wie folgt: T-DSL 100 -- Vigor160 -- Netgate2100 -- Devolo DLAN (MagicLan2) -- tplink SG108S -- MediaReceiver401 Typ B

                In Verbindung mit Fritzbox oder Digibox lief Entertain tadellos, weshalb Switch und dLan eigentlich kein Problem sein sollten.

                Danke, EuroPC

                A 1 Reply Last reply Reply Quote 0
                • S
                  speedAmaster @A Former User
                  last edited by

                  @silence Unfortunatly there was no result from the log analysis in my eyes. I see this outcome as pretty obvious as even with "allow all traffic"-rules for WAN and MAGENTA at the very top my IPTV stream is stopping after some seconds, probably due to failing IGMPv3 messages from outside (from multicast group) to inside. PfBlocker rules stay empty so they cant be the cause either.
                  Can double NAT be a problem as my pfSense is operating behind a fritzbox? Or do you have any other ideas left...? Thanks a lot!

                  ? 1 Reply Last reply Reply Quote 0
                  • ?
                    A Former User @speedAmaster
                    last edited by

                    @speedamaster, confirm you enabled save log in blocking rule? to be able to verify exactly which is the part that is getting blocked and needs for a good operation?

                    No, double nat shouldn't be a problem, I've done it before.

                    A 1 Reply Last reply Reply Quote 0
                    • A
                      arnog @EuroPC
                      last edited by arnog

                      @europc Das WAN Interface ist ein PPPoE-Interface, das wiederum als Link Interface ein VLAN Interface verwendet.

                      Welches Gerät macht denn bei dir die PPPoE-Einwahl? Wenn das die pfSense erledigt und das VLAN-Tagging nur durch den Vigor 160 gemacht wird, sollte es kein Problem für den Multicast-Verkehr sein. Falls der Vigor 160 die PPPoE-Einwahl macht, hast du wahrscheinlich auch Double NAT.

                      Falls du Double NAT mit dem Vigor 160 als Router machst: probier mal, die interne IP-Adresse des Vigor 160 noch beim Upstream mit anzugeben, also zum Beispiel 192.168.1.1/32. Evtl. auch mal die eingehende Regel für den UDP-Verkehr so ändern, dass die interne IP-Adresse des Routers als Quelle angegeben wird.

                      1 Reply Last reply Reply Quote 0
                      • A
                        arnog @A Former User
                        last edited by

                        @silence @speedAmaster I am not sure if Double NAT is a problem or not. For other traffic it shouldn't, but I am not sure how the IGMP Proxy in the upstream device works. But maybe it would help to add the upstreame device's internal IP address to the upstream configuration of the IGMP Proxy.

                        It might also be a problem with the rule that allows incoming UDP traffic, as I am not sure, what the source IP address of these packets is. Maybe try to use the upstream device's internal IP address in this rule.

                        Without a Wireshark capture between the pfSense and the upstream router, this is really difficult to troubleshoot.

                        1 Reply Last reply Reply Quote 0
                        • D
                          DollarSign @arnog
                          last edited by

                          Danke für den tollen Guide @arnog!

                          Kannst Du mir noch erklären, warum das Netz für den IGMP Inbound (224.0.0.0/4) größer ist als das vom UDP Inbound (232.0.0.0/16)?

                          Ich habe eine Multicast-Adressliste gefunden, wo so aussieht aus würde das 232.0.0.0/16 Netz ausreichen. Diese Adressen entsprechen auch den Multicast-Gruppen oder übersehe ich hier etwas?

                          A 1 Reply Last reply Reply Quote 0
                          • A
                            arnog @DollarSign
                            last edited by

                            @dollarsign IGMP General Membership Queries werden von außen an die Adresse 224.0.0.1 geschickt. Deswegen sollte die auf jeden Fall offen sein. Die gruppenspezifischen Membership Queries werden an die Gruppenadresse geschickt. Da IGMP nicht weiter problematisch ist, habe ich da das Netz nicht enger gezogen. Du kannst aber mal probieren, eine Regel für 224.0.0.1/32 und eine für 232.0.0.0/16 anzulegen. Das sollte auch klappen. Halte ich aber wie gesagt bei IGMP für unkritisch.

                            1 Reply Last reply Reply Quote 0
                            • W wkn referenced this topic on
                            • JeGrJ JeGr unpinned this topic on
                            • M MaxMixer referenced this topic on
                            • First post
                              Last post
                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.