Hallo @All,
schlage mich gerade mit einem Bildungsträger rum, bei dem wir laufend Fehler 1020 bekommen.
Wir vermuten es liegt an den Firewall-Einstellungen der Bildungseinrichtung.
Der verwendete BBB/Turn steht ausserhalb der Schule und TN von daheim erhalten keinen Fehler 1020.
Welche Ports und Protokolle (TCP/UDP?) müssen aus der Sicht der Schule geöffnet sein? Port 80/443 ist klar. Sonst noch welche?
VG Andre
Hi Andre,
Laut BBB Dokumentation (https://docs.bigbluebutton.org/2.2/configure-firewall.html):
TCP/IP port 22 (for SSH)
TCP/IP ports 80/443 (for HTTP/HTTPS)
UDP ports in the range 16384 - 32768 (for FreeSWITCH/HTML5 RTP streams)
VG, Dorian
Hallo Dorian,
bezieht sich das nicht auf die Firewall-Konfiguration des BBB-Servers?
Ich meine aber den Ein/Ausgang eines Schulanschlusses/Router etc., welche Ports müssen für BBB offen sein.
Reicht Port (80)443?
VG Andre
Hi Andre,
Neija, was in den Server rein muss, muss ja auch aus dem Client raus …
VG, Dorian
Hallo Dorian,
komme mir gerade Voll-Blond vor.
Habt ihr bei euren (Schul)-Netzen UDP-Port 16384 - 32768 nach innen aufgemacht? Oder auch nach aussen?
VG Andre
Hi Andre,
Bei uns von innen generell überall hin, da haben wir alles offen. Von außen haben wir nur die Ports für unsere Webserver offen.
Vielleicht erzähle ich aber auch quatsch 
Aber ich denke mal, dass man die ganzen udp Ports die bbb braucht in der Firewall von innen nach außen erlauben muss.
VG, Dorian
Client kommt ja ueber 443 rein, dann handeln Server und Client zusaetzliche Ports aus, BBB braucht fuer Audio, Video und Whiteboardgeficke dann mehrere UDP-Ports irgendwo zwischen 16000irgendwas und 32000irgendwas, siehe oben.
Wenn der Client da keine Antwort bekommt, dann versucht er’s mit dem Turnserver, der loest aber das Problem nicht, da dieser auch versucht die entsprechenden Ports auszuhandeln, demnach muss die Firewall den Bereich offenhalten/forwarden, sonst gibt’s kein Verhandeln.
Der Client connectet uebrigens bei jedem Sitzungsstart kurz den Turnserver, ob das jetzt datenschutzkonform ist wenn der extern liegt, darueber laesst sich glaube ich nicht streiten
Gruss Harry
Edith: Firewalls sind meistens (bei IPv4) sowieso fuer’n Arsch, bringen bzgl. Sicherheit nur was, wenn einer der Admins ein Trottel ist und dauernd Dienste aufmacht, die der Guruadmin per defautlt ueber die Firewall blockt oder wenn die Dockeradmins nicht schnallen, was localhost ist.
Hallo Harry,
danke für die ausführliche Erläuterung!
Irgend wie habe ich eine Denk-Blockade …
„DAU“-Frage:
Handelt meine Standard-Fritz!Box die Ports „automatisch“ mit dem Server aus? Oder mein Handy/Tablet über Nicht-WLAN?
OK, ich denke mal die techn. Situation im wesentlichen erfasst zu haben.
Irgend wie erinnern mich deine Äusserungen immer wieder an AfH, meinem Idol 
VG Andre 
Das hat nix mit WLAN oder LAN zu tun, die Fritze handelt gar nix aus, sie macht NAT und schreibt anstatt Deiner 192.168.178.11 ihre oeffentliche IP als Absender drunter, denn sie muss ja die Antwort entgegennehmen, fuehrt aber eine Tabelle (session table), was gerade offen ist und reicht das einfach an Dich weiter.
Ja, BOFH macht sich’s einfach - ich auch. Alles muss einfach sein, sonst schnall ich’s nicht.
Das mit den Firewalls ist aber wirklich so’n Ding, nicht selten werden gerade diese genutzt um Zugang ins interne Netzwerk zu bekommen, legendaer der FireEye-Hack von Tavis Ormandy vor 5 Jahren und er ist einer von den Guten, wird von Google in Projekt Zero mit Geld beworfen um die Welt besser zu machen. Project Zero: FireEye Exploitation: Project Zero’s Vulnerability of the Beast
Es gibt aber noch unzaehlige weitere Beispiele wo keine Firewall viel sicherer gewesen waere.
So eine „Appliance“ ist ein solche komlexer Konstrukt, da sind immer Luecken drin. Alleine schon der Code um da VPNs entweder durchzutunneln oder zu terminieren schreit nach „Sicherheitsfeatures“ fuer die boesen Jungs, die ihr Geld damit verdienen in internen Netzwerken Daten zu sammeln und diese meistbietend zu verkaufen.
Gruss Harry
Hi Harry,
Kenn ich …
OK …, es geht (mir) nicht um NAT/WAN, sondern um die(se) „UDP-Port-Aushandlung“ zwischen BBB/Client bzw. Client/BBB.
Ist klar. Und wie funktioniert das mit der Port-Aushandlung? Abstrakt.
Firewall(ing), ähnlich wie DNS und Mailserver, ist nicht mal eben, oder schnell mal gemacht und administriert - und verstanden. Geht zumindest mir so.
Zitat:
Unix/Linux ein Fass, das nach unten immer grösser wird und keinen Boden hat …
VG Andre
Server fordert vom Stack einen Socket an, kriegt den und legt daraufhin einen freien Port fest z.B. 4711 und wartet…
Client macht das Gleiche, Linux faengt da irgendwo bei > 30000 an, das haengt aber auch vom Clientdienst ab, das passiert beim Aufruf z.B. einer Webseite, ruft man in mehreren Tabs auf, dann werden mehrere Ports aufgemacht.
Das war’s auch schon mit dem Aushandeln, adressiert wird zwischen den beiden Ports an die IP, NAT uebersetzt lediglich die IP, die Ports bleiben erhalten.
GAU passiert natuerlich, wenn zwei Clients aus dem gleichen Netz den gleichen Port als „Antwortport“ angeben, dann kriegt die Fritze eine Krise, da sie zwei verschiedene Antworten auf einen Port bekaeme und diese nicht mehr unterscheiden kann, deshalb setzt sie den Port der zweiten Anfrage einfach eins hoch, das nennt sich PAT (Port Address Translation).
Du kannst Dir das kompliziert mit Wireshark ansehen, mit ein paar Filtern raeumt sich das auf oder gleich mit „iftop“ oder „tcptrack“, „iptraf“ muesste auch tun, man muss halt die Ports einblenden (p oder so).
Gruss Harry