UPnP bei doppeltem NAT - Patch verfügbar, wie "vorantreiben"?

[JeGr]

Hallo Jörg,

was genau funktioniert denn nicht mehr bei dir? Also ich hatte auch mit der 2.4.5 keine Probleme mit meinen Kisten zumindest Level 2 NAT zu bekommen. Ist das ein Problem? Bist du dir sicher, dass dein Problem - welches auch immer - nicht ggf. durch die DoppelNAT die ganze Zeit besteht/bestand? Bzw. was hat sich denn nach 2.4.5-p1 (hoffe ich) geändert?

Was generell uPNP angeht: in den 2.5-dev Snapshots ist eine neue miniupnpd Version drin, die irgendwelche Probleme mit Port Weiterleitungen oder gerade Konsolen angeblich besser machen soll. JimP hat da explizit Tester gesucht, die ggf. Willens sind, Ihre Kiste auf 2.5-devel zu aktualisieren und das zu Testen. Vielleicht wäre das eine Möglichkeit für dich - je nachdem was du sonst noch einsetzt und ob du dich mit einer Beta Version rumschlagen möchtest?

Grüße
Jens

[altmetaller]

Hallo,

es geht nicht um das NAT - es geht um das UPnP. Es werden dort schlichtweg keine Forwardings eingetragen.

Das scheint wohl „irgendwie“ damit zusammenzuhängen, dass die pfSense eine falsche IP auf dem WAN sieht (nämlich die 192.168.178.xxx/24 und nicht die öffentliche vom ISP).

So richtig verstanden habe ich das aber nicht; trotz „Google Übersetzer“ :-(

Der Fehler wurde mit der 2.4.5 eingebaut und besteht in der 2.4.5-p1 immer noch.

Um komplett auf eine Beta zu schwenken fehlt mir leider die Hardware. Wenn es darum ginge, ein Paket auszutauschen - kein Problem. Aber eine Beta produktiv zu nutzen traue ich mich dann doch nicht. Zumal das ja auch ein sicherheitsrelevantes Thema ist.

Gruß,
Jörg

[JeGr]

@altmetaller said in UPnP bei doppeltem NAT - Patch verfügbar, wie "vorantreiben"?:

Aber eine Beta produktiv zu nutzen traue ich mich dann doch nicht. Zumal das ja auch ein sicherheitsrelevantes Thema ist.

Das teile ich mal in zwei Hälften:

1. Beta Produktiv einzusetzen: Es ist ein Devel Snapshot. Wenn man keine extrem abgefahrene Konfiguration hat oder extrem viele Pakete einsetzt, läuft das eigentlich. Momentan ist bei mir da eher der Wurm im IPv6 Handling drin was die Kiste manchmal zum Neustarten bringt, aber das ist unter Beobachtung. Das Zutrauen ist jetzt kein großer Schritt. Konfiguration vorher sichern, updaten, testen/durchspielen. Wenns nicht richtig laufen will oder derbe Probleme geben sollte, zurück auf 2.4.5-p1 installieren und gut.

2. Sicherheitsrelevantes Thema: Inwiefern? Die neue Version baut im Gegenteil auf aktuellem FreeBSD auf und hat etliche Pakete in neuerer Version und mit etlichen Patches. Außer dem Stabilitätspunkt gäbe es eigentlich aus genau dieser Ecke kaum einen Grund es nicht zu tun. Ich würde es aber wegen genau der manchmal schwankenden Stabilität mit Dualstack oder bei Einsatz manchen Pakets nicht empfehlen.

Prinzipiell ist es ein Problem von MiniUPnPd selbst, die sich das in der Version so eingebaut haben. Es gab dann eine Anfrage bezüglich eines Patches dort, der aber nie wirklich getestet wurde. Daher kenne ich den aktuellen Stand von miniupnpd nicht, ob dieser Patch dann wirklich später in einer neueren Version mit verbaut wurde oder nicht.

Ich habe aber @jimp eine Anfrage im 2.5-devel Test-Thread geschrieben, ob der modifizierte miniupnpd von 2.5 der dort wegen Multi-Konsolen-Fähigkeit getestet wird auch den Patch für das private-Adressen-auf-WAN Problem enthält bzw. dieser von Upstream inzwischen integriert wurde. Sobald ich da mehr höre, gebe ich Bescheid!

[altmetaller]

Hallo,

vielen lieben Dank dafür! Letztendlich geht es (mir) darum, einfach mal auf das Thema und den Patch aufmerksam zu machen. Ich meine - falls es nicht gefixt wird, dann "ist das halt so.

Das Thema ist bekannt, ein (relativ übersichtlicher) Patch ist verfügbar - ich sehe da ganz positiv :-)

Gruß,
Jörg

[JeGr]

Soweit ich mich durch das Github Repo richtig durchgefräst habe, ist der Stand der:

• 2.4.4-p3 hatte miniupnpd-2.0.20180503
• 2.4.5-p1 hatte miniupnpd-2.1.20190210

letzteres hat wohl das Problem mit den RFC1918 Adressen auf WAN, dass es dann absemmelt oder einfach nicht mehr geht.

Wenn du nicht auf 2.5 upgraden möchtest aber experimentierfreudig bist ;) ...
Man könnte sich das miniupnpd binary von 2.4.4-x greifen und manuell auf die 2.4.5 rüberkopieren. Das vorhandene 2.4.5er binary umbenennen und dann mit dem 2.4.4er quasi ersetzen. Rein theoretisch sollte das gehen, weil beide 2.4.x noch auf FreeBSD 11.x aufbauen, die Package Builds sind also normalerweise kompatibel.

Könnten wir ausprobieren, das könnte ich dir ggf. auch als step-by-step aufschreiben wenn dus testen magst.

Grüße

[altmetaller]

@JeGr Das würde ich sogar selber hinkriegen. Allerdings muss ich dafür erst mal Einiges vorbereiten (2.4.4x installieren, SSH-Copy etablieren usw.).

Aber die Idee ist "eigentlich" ganz gut :-)

[JeGr]

Wenn du nur das Binary von 2.4.4-p3 brauchst sags, das kann ich dir auch hier als ZIP anhängen. Ich hab im Lab genug VMs rumhängen - da sollte auch noch eine ältere dabei sein.

Edit: Hier isses, frisches Binary von einem 2.4.4-p3 System.
miniupnpd.zip

Ablegen in /usr/local/sbin und vorher ggf. die vorhandene umbenennen in miniupnpd-orig oder so :)
Oh und vor der ganzen Aktion unbedingt mal UPNP ganz abschalten und sicherstellen dass der Daemon nicht läuft ;) Aber dürfte fast klar sein :)

[altmetaller]

@JeGr Danke - ich gucke mir das (am Wochenende) mal an! Aber wie gesagt: Dass das Thema zumindest einmal betrachtet wird, stimmt mich ja schon positiv. Zumal ich eine Engelsgeduld habe :-)

[JeGr]

Also soweit ich sehen konnte ist in der Version, die jetzt in 2.5 ist (2.2.0-RC1) der Patch mit drin, der als Lösung für das Problem von miniupnpd Upstream aus vorgeschlagen wurde. Insofern denke ich sind die Chancen ganz gut, dass das mit 2.5 spätestens wieder fliegt. Und die Zeit dahin, kann man ja - sollte es funktionieren - mit dem Switch der Binaries überbrücken, dann hat man zumindest einen Workaround. :)

[Rico]

Der Patch ist doch da, muss nur einer für 2.1.20190210 mal kompilieren. :-)

-Rico

[JeGr]

Und dann darfst du trotzdem ständig das Binary austauschen außer du machst es im Netgate Repo mit Pull request etc. Aber da momentan kein neues p2 m.W. in Arbeit ist, müsste man da auch entsprechend drauf warten. Und dann kann man auch als Workaround einfach die alte Binary nehmen wenn die funktioniert (sollte). :)

[altmetaller]

Hallo,

also, das mit dem Austausch des Binarys war 2 Minuten Arbeit und hat auch ohne weitere Änderungen zum Erfolg geführt. Folgendes Szenario:

• pfSense hängt als Exposed Host an der Fritz!Box, dort sind alle Filter (auch der Teredo-Filter) ausgeschaltet
• PC und XBox bekommen via DHCP immer die gleiche IP-Adresse und können sich erfolgreich einen Port freischalten

Bei der XBox habe ich jetzt den NAT-Typ "Offen" und sehe, dass die sich Port 3074 UDP via UPnP freigeschaltet hat und dort Teredo fährt. Das ist also alles Perfekt.

Beim PC (Windows 10) sehe ich, dass der sich einen relativ hohen Port (60.000nochwas) freigeschaltet hat und dort ebenfalls Teredo fährt. Der PC hat allerdings den NAT-Typ "strict".

Ich denke aber, das hat mit der pfSense und der hier erwähnten Problematik nichts zu tun...?!?

Gruß,
Jörg

Liebe Grüße,
Jörg

[JeGr]

@altmetaller said in UPnP bei doppeltem NAT - Patch verfügbar, wie "vorantreiben"?:

Ich denke aber, das hat mit der pfSense und der hier erwähnten Problematik nichts zu tun...?!?

Jein, kann sein, kann nicht. Normalerweise brauchst du zusätzlich für abgehende NAT noch für die Geräte die uPNP machen den outbound NAT Haken bei "static port" aber eben nur die Geräte (Konsole oder PC) damit das was nicht per upnp raus läuft den Port beibehält. Aber solang es geht würde ich jetzt auch nimmer schrauben :)