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

ATD · 18. Dezember 2015

Zitat von kls

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.

Zitat von kls

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!

Zitat von kls

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.

Zitat von kls

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.

Zitat von kls

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

kls · 29. Dezember 2015

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 ;-). Auch die Zeile

Code

iptables -A input_wan_rule -p esp -j ACCEPT

in /etc/firewall.user ändert nichts daran. Wenn die Verbindung abbricht muß ich auf cougar ipsec neu starten. Erst dann wird sie wieder aufgebaut.

Klaus

ATD · 29. Dezember 2015

Zitat von kls

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

kls · 1. Januar 2016

Auf racoon läuft openSUSE 13.2.
In /etc/sysconfig/SuSEfirewall2 habe ich nur

FW_SERVICES_EXT_UDP="500 4500"

eingetragen.

/etc/ipsec von racoon

Klaus

ATD · 1. Januar 2016

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

kls · 6. Januar 2016

Ich habe die Einträge so gemacht und alles neu gestartet. Ein Neustart von ipsec auf racoon führte aber nach wie vor zum Abbruch des Tunnels, ohne daß cougar versucht hätte, ihn wieder aufzubauen (auch nicht nach 5 Minuten Wartezeit). Aber dein Link zur Literatur führte mich zu dem Parameter "closeaction". Wenn ich den auf "restart" setze, dann kann ich auf racoon ipsec beliebig neu starten und cougar öffnet den Tunnel sofort wieder, praktisch verzögerungsfrei.
Danke, damit hast du mir schon wieder sehr weitergeholfen :-).

Klaus

ATD · 8. Januar 2016

Dann haben wir mit "closeaction" ipsec voll im Griff.

Ist dpdaction auch im Einsatz oder nur closeaction?

Wie sieht es mit der SuSE-Firewall-2 nach einem restart aus? Ping durch, FW_SERVICES_EXT_IP="esp" oder keine Auffälligkeiten?

Albert

kls · 12. Januar 2016

Ob "dpdaction=restart" drin ist oder nicht macht keinen Unterschied.
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.

Allerdings ist es mir gestern doch nochmal passiert, daß die Verbindung abgerissen ist und sich nicht mehr neu aufgebaut hat. Woran das gelegen hat weiß ich aber nicht. Alle meine heutigen Versuche, das Problem nachzustellen, sind gescheitert (d.h. der Tunnel kam immer wieder von selber hoch, egal was ich gemacht habe). 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. Dafür habe ich mit LuCI einen entsprechenden Eintrag gemacht:

Code

config rule
      option target 'ACCEPT'
      option src 'wan'
      option proto 'tcp'
      option dest_port '22'
      option name 'ssh-from-racoon'
      option src_ip '88.198.76.220'

der jetzt am Ende von /etc/config/firewall steht. Es funktioniert aber nicht, und ich vermute, daß das mit den anderen Firewall-Regeln bzgl. racoon zu tun hat, wo ja der gesamte Traffic über das VPN geleitet wird. Kannst du mir da noch einen Tipp geben, wie ich das hinbekomme?
Zur Sicherheit hier nochmal meine komplette /etc/config/firewall:

/etc/config/firewall

Code

config defaults
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option syn_flood '1'


config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option family 'ipv4'
        option target 'ACCEPT'


config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'


config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'


config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option src_ip 'fe80::/10'
        option src_port '547'
        option dest_ip 'fe80::/10'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'


config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'


config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'


config rule
        option name 'Allow-ICMPv6-Forward'
        option src 'wan'
        option dest '*'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'


config zone
        option name 'vpn'
        option network ' '
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        option subnet '88.198.76.220/32 192.168.100.0/24'


config zone
        option name 'lan'
        list network 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'


config zone
        option name 'wan'
        list network 'wan'
        list network 'wan6'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'


config forwarding
        option src 'vpn'
        option dest 'lan'


config forwarding
        option src 'lan'
        option dest 'vpn'


config forwarding
        option src 'lan'
        option dest 'wan'


config include
        option path '/etc/firewall.user'
        option reload '1'


config rule
        option target 'ACCEPT'
        option src 'wan'
        option proto 'tcp'
        option dest_port '22'
        option name 'ssh-from-racoon'
        option src_ip '88.198.76.220'

Alles anzeigen

Klaus

ATD · 12. Januar 2016

Zitat von kls

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?

Zitat von kls

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

kls · 13. Januar 2016

Zitat von ATD

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

Nein, hab ich nicht mehr.

Zitat

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.

Damit ich mich auf cougar einloggen kann, wenn der VPN-Tunnel aus irgend welchen Gründen nicht funktioniert und ich ipsec neu starten muß. Ansonsten habe ich aus der Ferne keine Möglichkeit, den Tunnel wieder aufzubauen.

Zitat

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.

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.

Klaus

ATD · 14. Januar 2016

Zitat von kls

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!?

Zitat von kls

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:

Code

config redirect
        option name 'Allow-SSH-from-racoon'
        option src 'wan'
        option proto 'tcp'
        option src_dport '22'
        option src_ip '88.198.76.220'
        option dest 'lan'
        option dest_ip '192.168.100.1' #bzw. die passende interne Adresse von cougar
        option family 'ipv4'
        option target 'DNAT' #default, kann weggelassen werden
        option enabled 'yes' #default, kann weggelassen werden

Alles anzeigen

Albert

ATD · 31. Januar 2016

Klaus, hat es geholfen oder verfolgst Du den SSH Zugriff nicht mehr?

Albert

kls · 1. Februar 2016

Zitat von ATD

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!?

Alles korrekt.

Mit deinem jüngsten Vorschlag bekomme ich

Warning: Section @redirect[0] (Allow-SSH-from-racoon) refers to a destination address on this router, assuming port redirection

und wenn ich versuche, von racoon aus auf die externe IP von cougar via ssh zuzugreifen, bekomme ich "Connection refused".

Ich lasse jetzt einfach per CRON auf cougar und panther einmal pro Stunde einen ipsec-Restart machen. Wenn also wirklich ein Tunnel abbricht, dann kommt er nach spätestens einer Stunde wieder hoch. Damit klappt es jetzt ganz gut.

Klaus

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

Jetzt mitmachen!

Teilen