Bin per ssh drin (falls es wichtig ist: Rechner ist direkt an einen LAN-Port des Freifunkrouters gestöpselt, WAN ist im Netzwerkswitch eingestöpselt, über den ich ins große weite Internet komme)
Ich weiß jetzt leider nicht so ganz genau wie es aussehen soll wenn es funktioniert, aber auf jeden Fall hat br-lan die korrekte IP-Adresse und Netzmaske und ip route gibt mir auch als Defaultroute den Weg über das Gateway aus.
na dann ping doch mal das Gateway
Ist erreichbar. Hätte ich vielleicht sagen sollen 
Das steht das hoffentlich nicht so in der Datei, oder? (Klingt jetzt mehr nach einem Router eines Friseurs oder Kneipiers…,-)
Na dann ist das schon mal nicht das Problem 
Das wäre so erst mal die verdächtigen.
Natürlich nicht, ist aber eine öffentliche IP und nicht jeder muss gleich per Whois rausfinden können, wo ich sitze 
Das kann gut sein, das werde ich erst einmal checken!
Ich hoffe mal, das ist irgendwo in der Doku versteckt, wäre peinlich, das einfach überlesen zu haben.
Router ist registriert, das ist es also hoffentlich nicht Kann aber natürlich sein dass ich da irgendwas verbockt hab.
Eine öffentliche IPv4 für einen FF-Router? Nobel geht die Welt zugrunde!
Dann schreib doch
option ipaddr '\geheim'
(Dann wird klar, dass Du’s manuell herausgenommen hast)
Naja irgendwie muss der Router ja mit seiner Außenwelt kommunizieren 
Oder anders ausgedrückt: „Muss man Wissen!“ 
Oha, laut Netzwerkdoku hier ist TCP/10000 inbound zu, aufgrund einer Advisory von 2005…
Aber UDP sollte auf sein. Falls UDP versehentlich auch gesperrt wurde, dann kann ich da auch leider nichts dran machen…
Auf dem Gateway hab ich noch gefunden dass die TTL auf 1 gesetzt wurde, mit einer Ausnahme für meine IP-Adresse ändert sich aber immer noch nichts, das ist also nicht der einzige Grund.
Ich nehme an, ich werde mich dann mal nächste Woche mit unseren Admins zusammen setzen müssen. Danke für die Hilfe!
Urgh, es lag nicht an der Firewall. Jetzt funktioniert alles. Aber es ist nicht schön.
Mir ist aufgefallen dass die „sendto: operation not permitted“ Fehlermeldung nur bei IPv6-Adressen auftrat ($DEITY sei dank gibt Ping die aufgelöste Adresse nochmal aus!)
Ich habe jetzt alle Vorkommen von „rheinland{0-3}.freifunk-rheinland.net“ in Configdateien durch die IPv4 ersetzt, auf die es auflöst. Anscheinend hat das Ding versucht, sich per IPv6 mit den Supernodes zu verbinden, obwohl nur eine IPv4 statisch konfiguriert war.
Ich habe irgendwie das Gefühl, das wird nur Probleme verursachen, daher werde ich die Kiste wohl wieder abschalten und auf „richtigen“ Support für statische Adressen warten müssen… Was meint ihr?
Nebenbei: Es ist Port 10040 nicht 10000, zumindest laut meiner Configdatei.
also in der config dabei /overlay/etc/fastd steht port 10000
also in der Domain Ruhrgebiet ist das korrekt. Die Supernodes sind aktuell nur per IPv4 erreichbar
Die Kiste läuft doch. Warum willst du die jetzt wieder abschalten?
Es gibt hier und da die ein oder andere Ungereimtheit in der Gould Software aber das ist schon ok so. Läuft.
Gruß
Thomas
10040 wunderte mich ebenfalls, aber ja doch…
Könnte es sein, dass irgendeine Firewall meint, den Traffic anhand des „BehaviourPatterns“ als irgendeine Form von „Storm“ abwehren zu müssen?
In jedem Fall fehlt da noch ein wenig Doku für die Leute, die FF-Nodes vielleicht auch mal in „vernagelten Firmennetzen“ installieren möchten.
Also „welche Ports müssen zwingend in welcher Richtung offen sein“.
Ne, es funktioniert ja jetzt. Das lag nur daran dass der Router versucht hat IPv6 in einem IPv4-only-Netz zu sprechen, warum auch immer. Sobald der Tunnel aufgebaut ist, ist IPv6 ja verfügbar, darum habe ich keine Probleme mehr. Vorteil ist jetzt, dass die Clients auch IPv6 bekommen. Da hier sogar 6to4 abgeriegelt ist, ist das ganz praktisch.
Und so komplex war die Firewall auch nicht, das sind nur normale iptables hier. Wir planen zwar irgendwann ein IDS einzuführen, aber bevor es soweit ist, gibt es wichtigeres. DHCP ausrollen z.B. 
Verstehe ich dich richtig, das du eure „Firmen“ Policy umgehst indem du das FF Netz in das gesicherte Netzwerk eingesteckt hast?
Na ob das so ne gute Idee ist?
GT
Solange das Interface Richtung Internet ordentlich vom internen Netz isoliert ist, und eine grundsätzliche Freigabe für Nutzung der Ressourcen erteilt wurde, sehe ich kein Problem. Oder anders: so wird eine Firmen-Policy, in der private Geräte nichts im Firmen-LAN zu suchen haben, noch unterstützt.
Wie kommt ihr eigentlich alle darauf dass ich in einem Firmennetz sitze? Ich mach schon nichts was ich nicht darf 
Die Bedenken die ich hatte bezogen sich eher darauf, dass ich nichts mitkriege wenn die IPs von den Supernodes umgestellt werden, da ich jetzt ja nackige IPs in den Configs stehen hab. Aber wer weiß ob sowas überhaupt vorkommen kann.
In Frankfurt wechseln die fast im Wochentakt…
Falls noch jemand irgendwann in der Zukunft diesen Faden findet: Mit der neuen Gluon-Version 2014.3.1 funktioniert die statische IP-Konfiguration (über Konfigurations-Webinterface, Reiter Expertenmodus) ohne die hier genannten Workarounds. Eben getestet.