Für die Namensauflösung braucht es Port 53, Port 54 ist etwas anderes bzw. wird nur intern benutzt.
Bei den Ports ist grundlegend zwischen Destination-Ports und Source-Ports zu unterscheiden.
Die Source-Ports sind quasi beliebig, da insbesondere durch das Source-NAT zufällige Ports ausgewählt werden, sodass die Tunnelverbindung mit der öffentlichen IP-Adresse des DSLers und zufälligem, aber richtig gemapptem Port hergestellt werden kann.
Die Destination-Ports (ich nehme an, die sind mit ausgehenden Ports gemeint) sind durch unsere Server statisch festgelegt. Das einfachste wäre für das Gerät alle Destination-Ports freizugeben. Für das Firmennetz hätte ich da keine Sicherheitsbedenken.
Möglich wäre es auch alle nötigen Destination-Ports freizugeben. Ich sehe hier den Nachteil des Wartungsaufwands bei Änderungen. Ich schätze unsere Community so ein, dass wir derlei Port-Änderungen oder -Erweiterungen auch nicht groß ankündigen würden, was zu unerwarteten Fehlern führen könnte, die schwierig zu diagnostizieren wären. Betroffen sind nur Netze in denen derart restriktive und selbst gewählte Policies gelten.
Long story short ... mhmm... long again:
Ich würde der Firma raten die internen Policies bzgl. Destination-Ports zu überdenken. Es ist kein wirksames Mittel und bewegt sich auf dem Niveau von Schulfiltern. Schulfilter haben mich damals nicht davon abgehalten meinen SSH-Server auf Port 80 zu starten ;-)
Läufst du damit argumentativ vor eine Wand, würde ich darum bitten, die benötigten Ports freizugeben und zu hoffen, dass es möglichst lange hält. Für L2TP müssen ganze Port-Bereiche freigegeben werden. Nicht selten sind dass denn Ports im Bereich 20000-22000, 9000-9001 und für fastd 10000-10003. Ich würde auf Nummer sicher gehen und 20000-30000, 9000-9010 und für fastd 10000-11111 freigeben. Natürlich führen so umfassende Freigaben das ganze wieder ad absurdum ;-)
Immer wichtig dabei: Es geht *nicht* um Port-Forwarding. Port-Forwarding bezieht sich immer auf die eigenen Source-Ports und wird nur benötigt, wenn die Gegenstelle einen statischen Source-Port erwartet bzw. nur einen statischen Destination-Port beliefert (Richtung der Nachrichten relevant!).
Viele Grüße, Simon
Am 01.12.18 um 11:28 schrieb lrnzo via Nordwest:
Hallo Leute,
folgendes Problem. Der Uplink für den Kulturverein Petersburg [1] ist für mich zZ nur via ipv6 linklocal über wlan zugänglich. Er steht in einer Halle, die einer Firma gehört und wo wir dankenswerte Weise unkompliziert Internet haben können. Richtig angeschlossen ist der. Auf br-wan bekommt bekommt man ipv4 vom DHCP und es können auch alle möglichen ipv4-adressen (u.a. auch unsere supernodes) gepingt werden. Allerdings funktioniert dns nicht und auch wenn ich die ip des supernodes anstatt des hostnames in die /etc/config/fastd schreibe, kann er keinen Tunnel aufbauen. Vom LAN-Admin weiß ich, dass nur bestimmte ausgehende Ports freigegeben sind, zB 53, 80, 443. für den gluon-wan-dnsmasq müsste wahrscheinlich auch der port 54 auf sein, oder? ist es so, dass für fastd bzw. l2tp derselbe ausgehende port auf sein muss, auf dem auch der jeweilige supernode lauscht? mir war so, dass ausgehend immer irgendein mehr oder wenig beliebiger port genutzt wird. Aber wenn ich einfach sagen könnte: bitte einmal Port 9000 bzw 10000 & 10001 ausgehend freigeben, wäre das ja das einfachste. Alternativ müsste ich vermutlich die ip/ebtables des ff-Router dahingehend bearbeiten, dass ausgehende Verbindung über zB port 80 rausgehen. von firewalls habe ich nur leider wenig Ahnung und ich fürchte, dass das ganze auch nicht updatefest wäre.
Was würdest DU tun?
[1] https://map.ffnw.de/friedhof/#%21/de/map/60e327a17ee4
Nordwest mailing list -- nordwest@lists.ffnw.de To unsubscribe send an email to nordwest-leave@lists.ffnw.de