[Suche] Empfehlung für Router mit Kabel Deutschland unter openWRT

    Ich habe jetzt mal von racoon her geschaut, was Sache ist, und da kann ich cougar ohne weiteres pingen! Und sobald so ein Ping stattgefunden hat, kann ich den Tunnel auch in umgekehrter Richtung von cougar nach racoon benutzen. Da fehlte anscheinend nur die "Initialzündung" (wie du in Post 235 schon vermutet hattest, aber in der anderen Richtung).


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


    Klaus

    Jetzt habe ich, um ganz sicher zu sein, daß das Setup auch nach einem Reboot noch läuft, den Router neu gebootet, und siehe da, der Tunnel hat sofort funktioniert! Weiß der Geier, was da vorher schiefgelaufen ist. Auf jeden Fall läuft es jetzt mit dem minimalen Setup, wie du es beschrieben hast.


    Danke und noch einen schönen Sonntag!


    Klaus

    Zitat von kls

    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

    I am a newbie to openwrt as well as strongswan. I had :wand :wand :wand until I find your posts. Thanks. Every things work now except the hostname resolution. I can ping by hostname of remote site. Do you have any hints? Thanks again :tup :tup :tup

    Zitat von boc8222

    I can ping by hostname of remote site.


    Zitat von boc8222

    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

    Klaus, ein FW restart blockt bei mir den Datenfluss wieder. Das heißt, der FW ist das Problem und ich bin in der Bringschuld. ;)


    Albert

    Das mit dem ping ist auch nicht so schlimm. Ich lasse einfach auf dem Server per Cron jede Minute einen ping machen, der "öffnet" dann den Tunnel. Aber wenn du doch noch eine saubere Lösung findest, wäre das natürlich nicht schlecht ;-).


    Zum Thema Tunnel zwischen cougar und panther: ich habe jetzt die /etc/ipsec.conf auf panther so geändert:


    "leftfirewall" kennt OpenSwan nicht, daher auskommentiert.
    Der ipsec-Satus sieht damit so aus:


    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").
    Ich frage mich auch, woher panther wissen soll, daß er den Tunnel zu cougar "über racoon" leiten muß.


    Klaus

    Zitat von kls

    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


    Zitat von kls

    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

    Zitat von ATD


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


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


    "aggressive" kennt OpenVpn nicht, und bei den anderen kommt im Log


    Dec 14 16:09:14 panther authpriv.warn pluto[25778]: esp string error: Non initial digit found for auth keylen, just after "aes128-sha1-" (old_state=ST_AA_END)
    Dec 14 16:09:14 panther daemon.err ipsec__plutorun: 034 esp string error: Non initial digit found for auth keylen, just after "aes128-sha1-" (old_state=ST_AA_END)


    und die Verbindung wird gar nicht erst eingetragen.


    Zitat

    Du hast aber ein virtuelles Interface, nicht wahr? Das ginge dann über die Routing Tabelle.


    Ja, es gibt auf panther ein "ipsec0".


    Hier der Vollständigkeit halber das Log eines "ipsec restart" (ohne die drei o.g. Zeilen):


    Klaus

    Zitat von kls

    "aggressive" kennt OpenVpn nicht, und bei den anderen kommt im Log


    Geht das?


    Code
    aggrmode=yes
pfs=yes
ike=aes128-sha1;modp1024
esp=aes128-sha1;modp1024


    Albert

    Damit gibt es keine Fehlermeldung beim Start mehr.
    Das Log sieht auch interessant aus:


    Ich hatte von 192.168.100.5 aus einen ping auf 192.168.1.1 gemacht, und anscheinend "wollte" panther, "konnte" aber nicht ;-).


    Klaus

    Zitat von kls

    Das Log sieht auch interessant aus:


    Das klappt noch nicht:


    Code
    "cougar": cannot initiate connection without knowing peer IP address (kind=CK_TEMPLATE)


    Vielleicht nur right=cougar.tvdr.de, also ohne % in der ipsec.conf.


    Ggf. /etc/init.d/ipsec reload vor restart.


    Albert

    Mit "right=cougar.tvdr.de" ging es nicht, weil es dafür (noch) keinen DNS-Eintrag gibt. Aber mit "right=192.168.1.1" sieht es so aus:



    Funktionieren tut es aber auch damit nicht.


    Klaus

    Zitat von kls

    Mit "right=cougar.tvdr.de" ging es nicht, weil es dafür (noch) keinen DNS-Eintrag gibt.


    Das ist suboptimal. ;)


    Zitat von kls

    Aber mit "right=192.168.1.1" sieht es so aus:


    Klaus, das ist doch logisch ganz falsch. Du kannst als right nur die externe public IP der Gegenseite eintragen. Entweder mit ddns oder im Klartext wie 188.xxx.xxx.113 wenn es sich nicht schon geändert hat. An die Interne Adresse kommst Du nur über den Tunnel oder durch Portforwards heran, niemals direkt aus dem Internet. Das NAT blockt alle anderen Pakete, die er nicht kennt. Dazu brauchen wir nicht einmal den Firewall.


    Albert

    Zitat von kls

    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

    Zitat von ATD


    Klaus, das ist doch logisch ganz falsch. Du kannst als right nur die externe public IP der Gegenseite eintragen. Entweder mit ddns oder im Klartext wie 188.xxx.xxx.113 wenn es sich nicht schon geändert hat. An die Interne Adresse kommst Du nur über den Tunnel oder durch Portforwards heran, niemals direkt aus dem Internet. Das NAT blockt alle anderen Pakete, die er nicht kennt. Dazu brauchen wir nicht einmal den Firewall.


    Ich dachte, weil du für cougar

    Code
    conn panther
        rightid=@panther.tvdr.de
        right=%panther.tvdr.de
        rightsubnet=192.168.100.0/24


    angegeben hattest, daß ich für panther einfach s/panther/cougar/ machen könnte und ipsec "irgendwie weiß", daß die VPN-Verbindung zwischen panther und cougar "über racoon" läuft. Aber da war ich wohl auf dem Holzweg ;-).


    Da jetzt extra DDNS zu machen gefällt mir nicht so ganz. Vielleicht könnte ich ja meine ursprüngliche Idee wieder aufgreifen, nämlich daß durch geeignete Routing-Einträge die Pakete zwischen cougar und panther halt über racoon (durch den jeweiligen VPN-Tunnel) geroutet werden.


    Klaus

    Zitat von ATD

    Nach einem kurzen loggen von iptables war ersichtlich, dass das esp Protokoll blockiert wurde, solange kein Traffic von der Innenseite stattfand.
    ...
    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.


    Das ist seltsam. Inzwischen tritt das anscheinend nicht mehr auf, ich kann die Verbindung zwischen cougar und racoon beliebig trennen und wieder aufbauen, und der Tunnel steht sofort (auch ohne deine Änderung).
    Meine /etc/firewall.user hatte noch die zwei Zeilen

    Code
    iptables -A forwarding_rule -m policy --dir in --pol ipsec -m conntrack --ctstate N -j zone_vpn_forward
iptables -A input_wan_rule -m policy --dir in --pol ipsec -m conntrack --ctstate N -j ACCEPT


    die du nicht hast. Ich habe die jetzt mal auskommentiert und es funktioniert trotzdem.
    Bis auf weiteres verwende ich jetzt mal auf cougar


    und habe den Ping jede Minute auf racoon abgestellt. Mal sehen, wie es sich im Dauerbetrieb verhält. Sollte die Verbindung doch mal wieder nicht hochkommen, werde ich die "esp"-Zeile von dir aktivieren.


    Zitat


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


    Ja, das ist erledigt und ich habe inzwischen meine ganze Entwicklungsumgebung hierher verlegt :-).
    Nochmals recht vielen Dank für deine unermüdliche und kompetente Hilfe!


    Klaus

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden