Probleme bei der Portfreigabe über UPnP von Systemen hinter einem USG ohne NAT und einer FRITZ!Box

Auch wenn bei deaktiviertem NAT in der USG alle Systeme hinter dem USG per UPnP die Portfreigaben der FRITZ!Box theoretisch steuern können, funktioniert es im Alltag nicht wie erwartet. Dies kann dazu führen, dass manche Spiele nur eingeschränkt Verbindungen zu anderen Spielern aufbauen können. Der Leser Chris hat mich im Blog Artikel UniFi LAN-/WLAN-Infrastruktur mit FRITZ!Box ohne „Doppeltes NAT“ darauf aufmerksam gemacht, dass das Spiel Destiny 2 mit der im Artikel beschriebene Konfiguration “nur” NAT Stufe 2 erreicht – das ist zwar besser als NAT-3 (wegen doppeltem NAT) aber doch weniger gut als NAT-1, was für eine direkte Erreichbarkeit des Systems für alle anderen Spieler steht.

Aktuell (08.03.2020) habe ich noch keine elegante Lösung, ich möchte meine Analyse hier kurz festhalten. Teilweise beschreibe ich nicht im Detail wie ich etwas gemacht habe, da ich noch nicht weiß, ob es am Ende wirklich notwendig war. Abhängig von Rückfragen oder Lösungsideen, passe ich den Artikel an und erweitere ihn bei Bedarf.
Update (15.03.2020): SSDP-Multicastpakete des PCs aufgelistet, auf die die FritzBox! im “Gutfall” antwortet.

Test: PC direkt an der FRITZ!Box

Um zu sehen wie sich das Spiel im Idealfall verhält, habe ich den PC direkt an die FRITZ!Box angeschlossen und in der FRITZ!Box für diesen PC die Option ” Selbstständige Portfreigaben für dieses Gerät erlauben.” aktiviert. Bevor ich das Spiel gestartet habe, habe ich den LAN-Traffic der FRITZ!Box zur weiteren Analyse durch Wireshark protokolliert.

Das Spiel erkennt als NAT-Type “offen” (1), was auch dem angestrebten Verhalten hinter dem USG entspricht. Im Netzwerk passiert:

  • 192.168.0.1/24 – meine FRITZ! Box
  • 192.168.0.45/24 – der PC mit Destiny 2
  • Wireshark Filter für die Analyse: ((ssdp or http or igmp) and (ip.src == 192.168.0.1 or ip.src == 192.168.0.45))
  • Über igmp machen FRITZ!Box und PC bekannt, dass sie per Multicast 239.255.255.250:1900 erreichbar sind.
  • Der PC frägt über 239.255.255.250:1900 (M-SEARCH) an, welches Gerät das InternetGatewayDevice ist (SSDP).
  • Die FRITZ!Box antwortet dem PC direkt.
  • Beide handeln verschiedenes direkt aus – zum Beispiel die relevanten Portfreigaben (in meinem Fall: UDP 3097 & 28617).
  • Alles ist gut.

Test: PC am USG

NAT/Masquerading ist auf dem USG deaktiviert. Destiny 2 meldet NAT-Typ: moderat (2). Nach der Analyse des Netzverkehrs, sieht es danach aus, dass der PC sich per IGMP an der Multicastadresse 239.255.255.250 im Netz “hinter” dem USG anmeldet und dort die SSDP Anfragen absetzt. Die FRITZ!Box meldet sich per IGMP an der Multicastadresse 239.255.255.250 im Netz “vor” dem USG / “hinter” der FRITZ!Box an. So reden beide Parteien zwar Multicast, aber der richtige Partner hört nicht zu. Erschwerend kommt hinzu, dass die SSDP Pakete des PCs eine TTL von 1 haben (sollte laut Standard eigentlich 4 sein?)

Was bedeutet das für UPnP? Geht es generell nicht oder fehlt nur am Anfang der Kette der Schritt, der dem PC mitteilt, wo das Internetgateway ist? Um das zu testen, habe ich mit Insomnia die UPnP Kommunikation nachgestellt:

  • 192.168.0.1/24 – meine FRITZ!Box
  • 192.168.1.45/24 – der PC mit Destiny 2
  • 192.168.0.250/24 | 192.168.1.1 – das USG mit deaktiviertem NAT/Masquerading
  • FRITZ!Box: Internet -> Freigaben -> Portfreigaben -> Gerät für Freigaben hinzufügen
    • Gerät: IP-Adresse manuell eingeben
    • IPv4-Adresse: 192.168.1.45
    • Selbstständige Portfreigaben für dieses Gerät erlauben: aktivieren
    • OK & Übernehmen

UPnP: Welche externe IP hat meine FRITZ!Box?

Auf dem PC Insomnia starten und einen neuen POST-Request anlegen:

  • Name: WANIPConn1#GetExternalIPAddress
  • POST-URL: http://192.168.0.1:49000/igdupnp/control/WANIPConn1
  • POST_Body XML: 
<s:Envelope
    xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
    s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <s:Body>
		<u:GetExternalIPAddress />
    </s:Body>
</s:Envelope>
  • Header
    • Content-Type: text/xml; charset=”utf-8″
    • SOAPACTION: SOAPACTION: “urn:schemas-upnp-org:service:WANIPConnection:1#GetExternalIPAddress”

Sollte als HTTP Code 200 und ein XML mit der externen IP der FRITZ!Box liefern.

UPnP: Ist ein bestimmter Port bereits auf eine interne IP weitergeleitet?

Neuen POST-Request in Insomnia anlegen, der exemplarisch prüft, ob der UDP Port 3097 bereits für eine interne Weiterleitung verwendet wird.

  • Name: WANIPConn1#GetSpecificPortMappingEntry
  • POST-URL: http://192.168.0.1:49000/igdupnp/control/WANIPConn1
  • POST_Body XML: 
<s:Envelope
    xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
    s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <s:Body>
        <u:GetSpecificPortMappingEntry
            xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
            <NewRemoteHost></NewRemoteHost>
            <NewExternalPort>3097</NewExternalPort>
            <NewProtocol>UDP</NewProtocol>
            </u:GetSpecificPortMappingEntry>
       </s:Body>
</s:Envelope>
  • Header
    • Content-Type: text/xml; charset=”utf-8″
    • SOAPACTION: SOAPACTION: “urn:schemas-upnp-org:service:WANIPConnection:1#GetSpecificPortMappingEntry”

Sollte als HTTP Code 500 liefern, was entweder bedeutet, dass die Abfrage falsch war, oder dass der Port noch für keine Weiterleitung verwendet wird.

UPnP: Einen externen Port der FRITZ!Box auf den PC weiterleiten

Neuen POST-Request in Insomnia anlegen, der per UPnP eine Portweiterleitung UDP 3097 auf den PC 192.168.1.45/24 konfiguriert.

  • Name: WANIPConn1#AddPortMapping
  • POST-URL: http://192.168.0.1:49000/igdupnp/control/WANIPConn1
  • POST_Body XML:
<s:Envelope
    xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
    s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <s:Body>
        <u:AddPortMapping
            xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
            <NewRemoteHost></NewRemoteHost>
            <NewExternalPort>3097</NewExternalPort>
            <NewProtocol>UDP</NewProtocol>
            <NewInternalPort>3097</NewInternalPort>
            <NewInternalClient>192.168.1.45</NewInternalClient>
            <NewEnabled>1</NewEnabled>
            <NewPortMappingDescription>DemonwarePortMapping</NewPortMappingDescription>
            <NewLeaseDuration>0</NewLeaseDuration>
        </u:AddPortMapping>
    </s:Body>
</s:Envelope>
  • Header
    • Content-Type: text/xml; charset=”utf-8″
    • SOAPACTION: SOAPACTION: “urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping”

Sollte als HTTP Code 200 und etwas XML zurückgeben. In der FRITZ!Box wird die Freigabe angezeigt. Der Befehl aus dem Abschnitt “UPnP: Ist ein bestimmter Port bereits auf eine interne IP weitergeleitet?” sollte jetzt den HTTP Code 200 liefern und per XML melden, dass der Port weitergeleitet wird.

UPnP: Weiterleitung eines externen Ports der FRITZ!Box auf den PC löschen

Neuen POST-Request in Insomnia anlegen, der per UPnP die Portweiterleitung UDP 3097 löscht.

  • Name: WANIPConn1#DeletePortMapping
  • POST-URL: http://192.168.0.1:49000/igdupnp/control/WANIPConn1
  • POST_Body XML: 
<s:Envelope
    xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"
    s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
    <s:Body>
        <u:DeletePortMapping
            xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1">
            <NewRemoteHost></NewRemoteHost>
            <NewExternalPort>3097</NewExternalPort>
            <NewProtocol>UDP</NewProtocol>
        </u:DeletePortMapping>
    </s:Body>
</s:Envelope>
  • Header:
    • Content-Type: text/xml; charset=”utf-8″
    • SOAPACTION: SOAPACTION: “urn:schemas-upnp-org:service:WANIPConnection:1#DeletePortMapping”

Sollte HTTP Code 200 liefern, wenn das Löschen erfolgreich war und 500, wenn es einen Fehler oder nichts zum Löschen gab. In der FRITZ!Box wird die Weiterleitung nicht mehr angezeigt. Der Befehl aus dem Abschnitt “UPnP: Ist ein bestimmter Port bereits auf eine interne IP weitergeleitet?” sollte jetzt wieder den HTTP Code 500 liefern.

Analyse: Auf welche Multicast Anfragen bekommt Destiny 2 im “Gutfall” Antworten?

Das Konfigurieren der FritzBox! per UPnP ist auch aus anderen Subnetzen aus möglich. Nur leider funktioniert es nicht, da der PC auf seine Anfragen über Multicast UDP 239.255.255.250:1900 keine Antwort bekommt, da diese Anfragen nicht bei der FritzBox! landen. Hier die Anfragen, die positiv beantwortet werden, wenn sowohl FritzBox! als auch PC im gleichen Subnetz sind.

PC -> 239.255.255.250:1900 (Multicast)

M-SEARCH * HTTP/1.1 – upnp:rootdevice

Simple Service Discovery Protocol
    M-SEARCH * HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): M-SEARCH * HTTP/1.1\r\n]
            [M-SEARCH * HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: M-SEARCH
        Request URI: *
        Request Version: HTTP/1.1
    Host: 239.255.255.250:1900\r\n
    ST: upnp:rootdevice\r\n
    Man: "ssdp:discover"\r\n
    MX: 3\r\n
    \r\n
    [Full request URI: http://239.255.255.250:1900*]
    [HTTP request 1/139]
    [Next request in frame: 19332]

FritzBox! -> PC (Unicast)

HTTP/1.1 200 OK – fboxdesc.xml

Simple Service Discovery Protocol
    HTTP/1.1 200 OK\r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
            [HTTP/1.1 200 OK\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Response Version: HTTP/1.1
        Status Code: 200
        [Status Code Description: OK]
        Response Phrase: OK
    LOCATION: http://192.168.0.1:49000/fboxdesc.xml\r\n
    SERVER: FRITZ!Box 7490 UPnP/1.0 AVM FRITZ!Box 7490 113.07.12\r\n
    CACHE-CONTROL: max-age=1800\r\n
    EXT:\r\n
    ST: upnp:rootdevice\r\n
    USN: uuid:<EINDEUTIGE-ID>::upnp:rootdevice\r\n
    \r\n
    [HTTP response 1/120]
    [Next response in frame: 18674]

HTTP/1.1 200 OK – avmnexusdesc.xml

Simple Service Discovery Protocol
    HTTP/1.1 200 OK\r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
            [HTTP/1.1 200 OK\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Response Version: HTTP/1.1
        Status Code: 200
        [Status Code Description: OK]
        Response Phrase: OK
    LOCATION: http://192.168.0.1:49000/avmnexusdesc.xml\r\n
    SERVER: FRITZ!Box 7490 UPnP/1.0 AVM FRITZ!Box 7490 113.07.12\r\n
    CACHE-CONTROL: max-age=1800\r\n
    EXT:\r\n
    ST: upnp:rootdevice\r\n
    USN: uuid:<EINDEUTIGE-ID>::upnp:rootdevice\r\n
    \r\n
    [HTTP response 2/120]
    [Prev response in frame: 18673]
    [Next response in frame: 18675]

HTTP/1.1 200 OK – igddesc.xml

Simple Service Discovery Protocol
    HTTP/1.1 200 OK\r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
            [HTTP/1.1 200 OK\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Response Version: HTTP/1.1
        Status Code: 200
        [Status Code Description: OK]
        Response Phrase: OK
    LOCATION: http://192.168.0.1:49000/l2tpv3.xml\r\n
    SERVER: FRITZ!Box 7490 UPnP/1.0 AVM FRITZ!Box 7490 113.07.12\r\n
    CACHE-CONTROL: max-age=1800\r\n
    EXT:\r\n
    ST: upnp:rootdevice\r\n
    USN: uuid:<EINDEUTIGE-ID>::upnp:rootdevice\r\n
    \r\n
    [HTTP response 3/120]
    [Prev response in frame: 18674]
    [Next response in frame: 18676]

HTTP/1.1 200 OK – igddesc.xml

Simple Service Discovery Protocol
    HTTP/1.1 200 OK\r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
            [HTTP/1.1 200 OK\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Response Version: HTTP/1.1
        Status Code: 200
        [Status Code Description: OK]
        Response Phrase: OK
    LOCATION: http://192.168.0.1:49000/igd2desc.xml\r\n
    SERVER: FRITZ!Box 7490 UPnP/1.0 AVM FRITZ!Box 7490 113.07.12\r\n
    CACHE-CONTROL: max-age=1800\r\n
    EXT:\r\n
    ST: upnp:rootdevice\r\n
    USN: uuid:<EINDEUTIGE-ID>::upnp:rootdevice\r\n
    \r\n
    [HTTP response 4/120]
    [Prev response in frame: 18675]
    [Next response in frame: 18677]

HTTP/1.1 200 OK – igddesc.xml

Simple Service Discovery Protocol
    HTTP/1.1 200 OK\r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
            [HTTP/1.1 200 OK\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Response Version: HTTP/1.1
        Status Code: 200
        [Status Code Description: OK]
        Response Phrase: OK
    LOCATION: http://192.168.0.1:49000/igddesc.xml\r\n
    SERVER: FRITZ!Box 7490 UPnP/1.0 AVM FRITZ!Box 7490 113.07.12\r\n
    CACHE-CONTROL: max-age=1800\r\n
    EXT:\r\n
    ST: upnp:rootdevice\r\n
    USN: uuid:<EINDEUTIGE-ID>::upnp:rootdevice\r\n
    \r\n
    [HTTP response 5/120]
    [Prev response in frame: 18676]
    [Next response in frame: 19333]

PC -> 239.255.255.250:1900 (Multicast)

M-SEARCH * HTTP/1.1 – urn:schemas-upnp-org:service:WANIPConnection:1

Simple Service Discovery Protocol
    M-SEARCH * HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): M-SEARCH * HTTP/1.1\r\n]
        Request Method: M-SEARCH
        Request URI: *
        Request Version: HTTP/1.1
    MX: 1\r\n
    HOST: 239.255.255.250:1900\r\n
    MAN: "ssdp:discover"\r\n
    ST: urn:schemas-upnp-org:service:WANIPConnection:1\r\n
    \r\n
    [Full request URI: http://239.255.255.250:1900*]
    [HTTP request 1/2]
    [Next request in frame: 41423]

FritzBox! -> PC (Unicast)

HTTP/1.1 200 OK – urn:schemas-upnp-org:service:WANIPConnection:1

Simple Service Discovery Protocol
    HTTP/1.1 200 OK\r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
        Response Version: HTTP/1.1
        Status Code: 200
        [Status Code Description: OK]
        Response Phrase: OK
    LOCATION: http://192.168.0.1:49000/igddesc.xml\r\n
    SERVER: FRITZ!Box 7490 UPnP/1.0 AVM FRITZ!Box 7490 113.07.12\r\n
    CACHE-CONTROL: max-age=1800\r\n
    EXT:\r\n
    ST: urn:schemas-upnp-org:service:WANIPConnection:1\r\n
    USN: uuid:<EINDEUTIGE-ID>::urn:schemas-upnp-org:service:WANIPConnection:1\r\n
    \r\n
    [HTTP response 1/1]

PC -> 239.255.255.250:1900 (Multicast)

M-SEARCH * HTTP/1.1 – urn:schemas-upnp-org:device:InternetGatewayDevice:1

Simple Service Discovery Protocol
    M-SEARCH * HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): M-SEARCH * HTTP/1.1\r\n]
            [M-SEARCH * HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: M-SEARCH
        Request URI: *
        Request Version: HTTP/1.1
    Host: 239.255.255.250:1900\r\n
    ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1\r\n
    Man: "ssdp:discover"\r\n
    MX: 3\r\n
    \r\n
    [Full request URI: http://239.255.255.250:1900*]
    [HTTP request 2/139]
    [Prev request in frame: 18666]
    [Next request in frame: 19676]

FritzBox! -> PC (Unicast)

HTTP/1.1 200 OK – urn:schemas-upnp-org:device:InternetGatewayDevice:1

Simple Service Discovery Protocol
    HTTP/1.1 200 OK\r\n
        [Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n]
            [HTTP/1.1 200 OK\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Response Version: HTTP/1.1
        Status Code: 200
        [Status Code Description: OK]
        Response Phrase: OK
    LOCATION: http://192.168.0.1:49000/igddesc.xml\r\n
    SERVER: FRITZ!Box 7490 UPnP/1.0 AVM FRITZ!Box 7490 113.07.12\r\n
    CACHE-CONTROL: max-age=1800\r\n
    EXT:\r\n
    ST: urn:schemas-upnp-org:device:InternetGatewayDevice:1\r\n
    USN: uuid:<EINDEUTIGE-ID>::urn:schemas-upnp-org:device:InternetGatewayDevice:1\r\n
    \r\n
    [HTTP response 6/120]
    [Prev response in frame: 18677]
    [Next response in frame: 19685]

Und jetzt?

Was ich bis hierher zeigen wollte, ist, dass UPnP zum Konfigurieren der FRITZ!Box aus einem Subnetz hinter einem anderen Router wie zum Beispiel dem USG technisch erst Mal kein Problem ist. Da vor dem direkten Konfigurieren per UPnP aber ein Austausch über IGMP und SSDP läuft, kann es zu Problemen kommen.

Ich habe etwas mit igmp-proxy, mDNS und Firewalleinstellungen auf dem USG ohne Erfolg experimentiert, um das IGMP-/SSDP-Problem zu lösen. Quellen und Details, liefere ich bei Bedarf gerne nach. Es sollte technisch irgendwie möglich sein, die Multicast-Adresse 239.255.255.250 über die beiden Subnetze “vor” und “hinter” dem USG zu spannen.

Alternativ wäre eventuell ein kleines Programm im Netz 192.168.1.0/24 ein Workaround. Es könnte auf die Anfrage des PCs mit Destiny 2 mit den Informationen der FRITZ!Box antworten. Sobald die IP des Internet Gateways bekannt ist, sollte der UPnP-Teil laufen.

Muss in Ruhe darüber nachdenken. Für Vorschläge und Anmerkungen bin ich dankbar.

3 Gedanken zu „Probleme bei der Portfreigabe über UPnP von Systemen hinter einem USG ohne NAT und einer FRITZ!Box“

  1. Hi Martin,

    ich kann mich erinnern, dass ich in meinen damaligen Tests UPnP nie zum Laufen bekommen habe wenn die Fritz!Box nicht den DHCP-Server stellt – nicht, dass dieser Umstand in irgendeiner Form mit hinein spielt. Ich habe aber nicht in die Protokolle geschaut sondern lediglich meine Routing und Firewall-Regeln geprüft.

    Du kannst ja auch UPnP auf der USG aktivieren und die USG als Exposed Host in der Fritz!Box konfigurieren – aber auch das funktioniert bei mir nicht. Lustigerweise funktioniert auch die Portweiterleitung auf den PC nicht – zumindest erkennt Destiny 2 dann auch nur NAT-Type 2 / Moderate.

    Ich werde mal dein Testbed nachbauen, damit ich mittesten kann. Übrigens: Routing und Switching sind für mich kein Hexenwerk – ich habe mich nur mit den Protokollen nicht so weit auseinandergesetzt. Wir können uns also gern auch weiter auf höherer Ebene unterhalten ohne viel zu erklären – ich frage schon sollte ich etwas nicht verstehen.

    Gruß,
    Chris

    Antworten

    1. Hi,
      das Destiny 2 auch mit manuell konfigurierter Portweiterleitung die Verbindung nicht als “offen” einstuft, hat mich auch gewundert. Ich vermute, das Spiel baut so sehr auf UPnP, dass wenn es über SSDP keine Antwort bekommt, es “maximal” von Typ-2 ausgeht.
      Ich habe die Multicast Anfragen des PCs, die von der FritzBox! beantwortet werden, wenn sie im gleichen Subnetz sind, im Artikel ergänzt.
      Gruß
      Martin

      Antworten

    2. Hallo Chris,

      ich habe ein kleines Java Programm geschrieben, dass die richtigen SSDP Meldungen an Destiny 2 schickt, so dass das Spiel auch hinter dem USG das Portforwarding der FritzBox korrekt einstellt und als NAT Typ “offen” angezeigt wird. Was ist die IP deiner FritzBox? Das Programm ist noch sehr “hässlich”. Unter anderem ist die IP der FritzBox fest hinterlegt – für einen generellen Test kann ich dir das JAR-File zur Verfügung stellen. Sobald der Code sauber ist, kann ich ihn auch veröffentlichen.

      Gruß
      Martin

      Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert