Posts by ATD

    Der Tunner zwischen panther und racoon funktioniert damit nach wie vor einwandfrei, aber es kommt offensichtlich kein Tunnel zwischen cougar und panther zustande ("prospective erouted" statt "erouted").


    Versuch's mal in der ipsec.conf unter cougar (oder %default) flogendes:

    Code
    aggressive=yes
            ike=aes128-sha1-modp2048
            esp=aes128-sha1-modp2048

    Ich frage mich auch, woher panther wissen soll, daß er den Tunnel zu cougar "über racoon" leiten muß.


    Bei iptables wäre es ein Eintrag in der /etc/config/firewall -> option subnet '88.xxx.xx.220/32 192.168.1.0/24' bei der Zone vpn. Du hast aber ein virtuelles Interface, nicht wahr? Das ginge dann über die Routing Tabelle.

    Albert

    I can ping by hostname of remote site.

    I can't ping by hostname of remote site PC and server.


    I assume that your second statement is correct.

    You have two options for a name resolution from the remote site.

    1. If you have a few PCs without domain, than put each name and its IP address from the remote site into the OpenWRT local hosts file.

    2. Exists both on local and remote site a real dns server with domains, than fill out the dnsmasq forward settings in LuCI.

    Albert

    Somit ist also deine einfache Installationsanleitung verifiziert.
    Nun wäre es nur noch schön, wenn ich ohne den "initialen Ping" auskommen könnte...


    Tja Klaus, schon klar.

    Auch ich habe noch einmal meine Anleitung verifiziert. Festplatte aus der VM gelöscht und den Original Image neu eingebunden. Alles laut Anleitung aus der Post 194. Zusätzlich habe ich noch die luci-app-ddns installiert und arbeite jetzt mit echten DynDNS Einträgen an allen Seiten um weiter Fehler auszuschließen. Einen zweiten Standort habe ich noch hinzugefügt (zwei IPSec Tunnels). Alles funktioniert soweit. ABER:

    Ich muss einen traceroute oder ping absetzen, bevor die Gegenseite auch pingen kann. Es genügt von einem PC in meinem Subnet den ping abzusetzen, es muss nicht unbedingt am Router erfolgen. Noch unerklärlicher ist es, dass nur die angesprochene Seite funktioniert. Das bedeutet, dass ich für jeden Tunnel einzeln agieren muss, erst danach ist alles OK.

    Ich habe Vermutungen aufgestellt, woran es liegen könnte, aber ich kann momentan nur sagen, woran es nicht liegen kann.

    - Die Gegenseite ist es nicht. Beide unterschiedliche Router arbeiten mit virtuellen Interfaces, kein FW. Beide bedienen über 20 IPSec Tunnels ohne Probleme.
    - Der locale NAT ist es auch nicht, denn wenn da was fehlt, dann wäre es mit dem ersten ping in irgendeiner Richtung alles erledigt.
    - Der Firewall/Forwarding kann es auch nicht sein, sie sind statisch und funktional.
    - IPSec baut den Tunnel auf, also auch nicht schuldig.

    Wie auch immer, mein Image ist BETA 2. Ich werde einfach abwarten, wie Deine Ergebnisse aussehen, denn momentan habe ich keinen Ansatz für das "Problem" nur Workaround. Also melde Dich, nachdem Du auch panther angebunden hast.

    Albert

    Dabei fällt auf, daß in der alten Version in /etc/strongswan.d/charon deutlich mehr Dateien vorhanden sind als in der Neuen.


    Sie sind aber nur für den Tunnel und er steht doch.

    /etc/strongswan.d/charon


    Albert

    Hast du ganz sicher keine der Dateien in /etc/strongswan.d/charon verändert?


    Definitiv nein.

    Das läuft aktuell.


    Albert

    Fehler gefunden. Ich bin immer so vorgegangen, dass ich an dem OpenWRT traceroute/ping probiert habe, dann die Gegenseite und zuletzt der Linux im eigenen Subnet.

    Es funktioniert, ABER nur dann, wenn zuerst von cougar Richtung racoon ein traceroute oder ping abgegeben wurde. Sonst geht nichts über den Tunnel!

    Das wäre erstmal ein Workaround mit Deiner "neuen" Konfiguration.

    Wie es dann weitergeht, das werde ich heute nicht sagen können. ;)

    Albert

    Nur wenn ich ipsec stoppe und die Zeile "option subnet '88.198.76.220/32 192.168.100.0/24'" in /etc/config/firewall auskommentiere, kann ich racoon erreichen - dann allerdings freilich nicht über das VPN.


    1. Internet geht immer?
    2. Wenn Du nach racoon willst, dann immer über seine IP.
    3. Laut Zitat kommst Du an racoon über das Internet ran, wenn ipsec und die IP aus dem FW raus ist. Die Pakete gehen nicht über den Tunnel.
    4. Ist ipsec an und FW mit der IP versehen, dann kommst Du gar nicht mehr an racoon, weil die Pakete an racoon ausschließlich über den Tunnel geroutet werden!

    Das sagt uns relativ klar, was passiert. Beim Punkt 4 haben die Pakete nur eine Chance und das ist der Tunnel. Wenn die Gegenseite nicht antwortet, dann gibt es auch keine Rückmeldung. Mein Bauchgefühl sagt mir, dass es doch racoon ist. Es erscheint mir einfach logisch. Restbestände in FW Cache von der vorhergehenden Installation. Also Neustart.

    Albert

    opkg list_installed


    Albert

    Da stimmt schon was nicht! Ich kann keinen Eintrag auf racoon erkennen!

    In /etc/config/firewall ist bei der zone vpn der Eintrag der IP Adresse von racoon Pflicht. Ob nur die Adresse oder als Subnet, das müsstest Du selbst ausprobieren. Ohne das kann kein Forwarding funktionieren.

    In der /etc/ipsec.conf gilt dasselbe, damit strongSwan weiß, was verschlüsselt werden soll.

    Ausschnitt iptables -nvL.


    Albert

    Das ist doch, bis auf das -I statt -A in der letzten Zeile, genau das, was in der /etc/firwall.user steht, oder?


    Sorry, natürlich -A nicht -I.

    Wo wir noch Unterschiede hatten, das war strongswan-mod-kernel-libipsec. Bei mir ist es NICHT installiert.

    opkg list_installed strongswan*


    Bitte abgleichen.

    Albert

    Gib mal die folgenden vier Befehle an der Console ein, aber bitte nur ein einziges mal und dann nie wieder!

    iptables -t nat -A prerouting_wan_rule -m policy --dir in --pol ipsec -j ACCEPT
    iptables -t nat -A postrouting_wan_rule -m policy --dir out --pol ipsec -j ACCEPT
    iptables -A forwarding_rule -m policy --dir in --pol ipsec -m conntrack --ctstate NEW -j zone_vpn_forward
    iptables -I input_wan_rule -m policy --dir in --pol ipsec -m conntrack --ctstate NEW -j ACCEPT

    und /etc/init.d/firewall restart.

    Albert