Posts by ATD

    Eigentlich braucht man es nicht, trotzdem gibt es im Internet viele Meinungen, die einem erklären, dass Masquerading auch bei IPv6 unerlässlich ist.


    Aha.


    Ich bräuchte mal jemanden, der etwas Ordnung in mein Chaos bringt. Im Internet widerspricht sich irgendwie alles.


    Mit Deinem Worten:


    Hätte hier ja mit mehr Reaktionen gerechnet.


    überlasse ich das Feld (momentan) den "Anderen". ;-)


    Albert

    NAT hat der Teufel erfunden ;)


    Ich wusste bis jetzt nicht, dass er schon etwas Sinnvolles getan hat. ;-)


    Wie komme ich da "durch", ohne dass am Router etwas umkonfiguriert werden muss?


    Dann bleibt fast nut der TeamViewer bei bedarf. Er kann selbst VPN. Ob VPN auch in der freien Version enthalten ist, das kann ich nicht beantworten.


    Albert

    Ist es möglich, yavdr als "server only" zu installieren ohne dass man eine nvidia Grafikkarte benötigt?


    Ja, es heißt "headless". WFE -> Einstellungen -> Allgemein -> Setup -> headless (yaVDR server).


    Albert

    Denn via D-lan hat man recht hohe Ping Zeiten so um die 4-5 ms kann es daran liegen das sich der minisatip server so verhaelt ?


    Bei DLAN Problemen aller Art lautet bei uns die erste Frage an den Kunden: Steckt der direkt in der Dose oder hängt er an einem Verteilersteckdose. Letzteres hat sich meistens als "suboptimal" erwiesen.


    Albert

    Gerd, ich habe einen Lieferanten, welcher ein sehr großes Sortiment an Lüfter anbietet. Falls Du den Lüfter ausbaust und ein Bild von dem Aufkleber mir zukommen lässt (noch besser postest), dann kann ich Dir ggf. helfen oder ein Andere. Die Maße wären für "kompatible" auch sehr interessant.


    Albert

    Ansonsten habe ich aus der Ferne keine Möglichkeit, den Tunnel wieder aufzubauen.


    Das ist so nicht ganz korrekt. Vorausgesetzt, dass Du die aktuelle IP von cougar kennst (DDNS?) und über den Ausfall informiert wirst, dann ginge es doch ohne racoon mit ssh.


    Ich dachte immer, dass cougar auf Deinem Hauptwohnsitz aktiv ist. Noch ein Paar Fragen um die Sache zu präzisieren:


    1. Du bist nicht am Standort von cougar (Arbeit, Urlaub, was auch immer)?
    2. Du wirst über einen Ausfall der ipsec auf cougar informiert (von jemand oder von etwas)?
    3. Du kennst die IP von racoon, nicht aber von cougar, deswegen der Umweg über racoon?
    4. Sofern der Tunnel nicht mehr steht, so kennt racoon den externen IP von cougar nicht mehr, Du hast vor, sie aus einem Log herauszupicken!?


    Das dachte ich mir schon. Ich hatte halt gehofft, es gäbe eine Möglichkeit, die Pakete, die an Port 22 bei cougar ankommen und von racoon stammen ganz normal zu behandeln und nicht durch den Tunnel zu schicken.


    Nun ja, unmöglich ist gar nichts. Man kann sich die Schwächen und Besonderheiten einer Konfiguration zu Nutze machen. Weiter oben habe ich geschrieben, dass racoon selbst keinen Tunnel aufbauen kann, denn rigtht = %any anwählen ist nicht möglich. Cougar baut den Tunnel auf und sendet darüber Pakete zum racoon. Racoon vertauscht dann die Absenderadresse mit dem Empfängeradresse (und auch umgekehrt), so kommen die Pakete über den Tunnel zurück. Wenn der Tunnel nicht mehr steht, dann ist es theoretisch möglich den externen IP von cougar (sofern bekannt!) von racoon aus mit ssh anzusteuern. Diese Pakete könnten wir dann über wan nach lan redirecten, denn der SSH-Server hört auf die interne IP von cougar!


    Folgendes in der /etc/config/firewall, genau an der Stelle vor dem ersten config zone, könnte bereits Deinem Anliegen lösen:



    Albert

    Die Firewall auf racoon kann ich beliebig restarten, ohne daß der Tunnel abbricht.
    FW_SERVICES_EXT_IP="esp" scheint auch nicht nötig zu sein, denn es geht mit und ohne diesen Eintrag.


    Das heißt, Du hast keinen ping über cron mehr?


    Ich würde daher gerne in der Firewall von cougar den ssh-Port nur für racoon öffnen, so daß ich reinkomme, wenn der VPN-Tunnel aus irgend welchen Gründen mal nicht steht.


    Das mit dem ssh kommend von racoon nach cougar verstehe ich nicht. Könntest Du bitte genauer schildern, was Du damit vor hast? Mir ist nicht klar, wie/wer/was/warum von racoon ssh Verbindungen nach cougar aufnehmen könnte/sollte.


    Hintergrund: in Deinem Regel schließt der eine Argument: option src 'wan' (das ist die Zone wan) den anderen: option src_ip '88.198.76.220' (die Adresse gehört zur Zone vpn) aus. Beide müssten zutreffen, damit der Regel greift. Genau das ist aber unmöglicht, denn diese bestimmte IP kommt entweder über den wan oder über den Tunnel. Daran würde weder die Position der Regel noch das Weglassen oder ersetzen von wan nichts ändern.


    Albert

    So wird alles klar.


    Firewall:


    Wie vermutet, Dein Firewall auf racoon blockiert das esp Protokoll kommend grundsätzlich. Deswegen hast Du den periodischen ping eingeführt. Erst nach einem ping auf die private IP von cougar vertraut Dein Firewall dem esp Protokoll. Wenn Du in /etc/sysconfig/SuSEfirewall2 zusätzlich die Zeile:


    FW_SERVICES_EXT_IP="esp"


    aufnimmst, dann kannst Du den ping per cron auf racoon abstellen.


    IPSec:


    1. StrongSwan arbeitet nicht mit on demand Tunneln, sondern mit statischen Tunneln und periodischen rekeying. Es überwacht die Verbindung auf Abbrüche per default nicht.


    2. StrongSwan verwendet right= für die Adresse des Routers/Clients auf der anderen Tunnelende. Der Wert kann eine publich IP, eine aufgelöste %DDNS oder eben %any sein. In den ersten beiden Fällen kann racoon eine Verbindung initiieren, bei %any nur alle entgegennehmen. Any kann man logischer weise nicht "anrufen".


    Aus 2. ist es ersichtlich, dass ein ipsec restart an racoon dazu führt, dass die Verbindung abreist. Racoon kann wegen %any niemanden anrufen, cougar versucht es nicht. Cougar hat keine feste public IP und DDNS möchtest Du auch nicht. Startest Du später auf cougar ipsec neu, so initiiert cougar eine neue Verbindung zu racoon.


    Das können wir aber aus Punkt 1. anders lösen. Wir schalten auf cougar dpd ein:


    dpdaction = restart


    Die Zeile gehört in die Sektion conn %default in /etc/ipsec.conf auf cougar. Wenn Du die Zeiten für die Überwachung ändern möchtest, dann findest Du dazu hier Literatur.


    Albert

    Mit TransEdit sollte es prinzipiell möglich sein, falls Du einen Windows PC besitzt. Wenn Du Interesse hast, sende mir eine PN/Mail, ich habe Zugang zum Mitgliederbereich von DVBViewer. Das Programm ist mini.


    Albert

    Du hattest Recht, sobald ipsec auf racoon neu gestartet wird, bricht die Verbindung zu cougar ab und wird auch nicht von selber neu aufgebaut (ist mir über die Feiertage passiert ;-).


    Nicht ganz, ich meinte nicht IPSec sondern den Firewall auf racoon. Die beide sollten wir strikt auseinender halten.


    Racoon ist kein "Router". Ich nehme an, Du hast Susi auf dem Server und ganz einfach strongSwan installiert. An dem Firewall hast Du nichts geändert. Korrekt?


    Die ipsec.conf von racoon, haben wir sie schon gesehen?


    Sorry, das es länger gedauert hat. Ich habe mich schon länger nicht eingeloggt, jetzt sehe ich plötzlich vier ungelesene Seiten vor mir. :-(


    Albert

    ipsec "irgendwie weiß", daß die VPN-Verbindung zwischen panther und cougar "über racoon" läuft


    Nein, das funktioniert so nicht. IPSec ist immer ein Punkt-zu-Punkt Verbindung. Prinzipiell könnte man das schon auf racoon mit einer Route regeln. Da wir aber auf racoon iptables haben und nicht einmal einen Subnet hinter der public IP oder einen virtuellen Interface, wird es nahezu unmöglich. Ein direkter Tunnel zwischen cougar und panther wäre um Größenordnungen einfacher zu bewerkstelligen. Versuche Dich lieber mit dem Gedanken eines DDNS zu befreunden.


    Meine /etc/firewall.user hatte noch die zwei Zeilen


    Sie sind überflüssig. Die Regeln aus der erste Zeile werden beim abarbeiten von /etc/config/firewall bereits erzeugt (anlegen der Zone vpn mit Subnets, bzw. forward vpn -> lan). Wenn Du diese Zeile verwendest, dann entsteht lediglich eine zweite, identische Regel. Die zweite Zeile bewirkt nichts, dafür habe ich die Neue eingefügt. Somit wird esp auch kommend akzeptiert. Die zwei weiteren Zeilen mit dem NAT Einträgen sind dagegen Pflicht!


    Sollte die Verbindung doch mal wieder nicht hochkommen, werde ich die "esp"-Zeile von dir aktivieren.


    Das passiert spätestens wenn auf racoon der FW neu gestartet wird, glaube ich. Nimm lieber die drei Regeln für racoon und auch für cougar. Alle drei erlauben nur, keine von denen verbietet etwas. Du hast nichts zu verlieren, es kann nichts schief gehen. ;-)


    Ja, das ist erledigt und ich habe inzwischen meine ganze Entwicklungsumgebung hierher verlegt :-).


    Es war doch ein Spaziergang. :-)


    Nachdem ich endlich meinen Glauben an die Anleitung bei OpenWRT verloren habe, bzw. mit Hilfe der VM mit OpenWRT und eine reelle Umgebung ging es doch recht zügig voran.


    Nochmals recht vielen Dank für deine unermüdliche und kompetente Hilfe!


    Für Dich immer sehr gerne. Es hat Spaß gemacht und der "Lernfaktor" kam auch nicht zu kurz. ;-)


    Albert

    Nun wäre es nur noch schön, wenn ich ohne den "initialen Ping" auskommen könnte...


    Klaus, auch das können wir abhaken. Nach einem kurzen loggen von iptables war ersichtlich, dass das esp Protokoll blockiert wurde, solange kein Traffic von der Innenseite stattfand. Warum und wieso? Dafür habe ich keine Erklärung, aber eine Lösung.



    Danach war der Tunnelverkehr ohne Beschränkungen und ohne "initialen Ping" von allen Seiten möglich. Du wirst es vermutlich von racoon seine Seite aus einsetzen müssen, aber bei cougar würde ich es trotzdem unbedingt anwenden. Weitere Änderungen habe ich nicht vorgenommen.


    Damit ist das ursprüngliche Problem: OpenWRT mit strongSwan IPSec Tunnel erledigt!?


    Albert