11:28 a.m.
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/#!/de/map/60e327a17ee4
1:39 a.m.
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/#!/de/map/60e327a17ee4
_______________________________________________
Nordwest mailing list -- nordwest(a)lists.ffnw.de
To unsubscribe send an email to nordwest-leave(a)lists.ffnw.de
786
days inactive
787
days old
1 comments
2 participants
participants (2)
-
lrnzo -
Simon Kurka