Klaus, noch ein versuch, wenn Du magst.
Nachdem die neue ipsec.conf aktiviert wurde, versuche bitte in der /etc/config/firewall, in der zone 'lan' option masq '1' zu option masq '0' zu setzen. Ich glaube, das interne Netz sollte nicht maskiert werden.
Poste dann die Ausgabe von iptables -L.
Was mir noch einfällt, mit 'ipsec statusall' vorher und nachher überprüfen auf welche IPs er mit left=%any bzw. left=%defaultroute lauscht.
Ist die Adresse 188.xx.xx.113 auch statisch?
Albert
Nichts von dem, was da steht, ist für mich nachvollzieh- bzw. anwendbar.
Die passende Anleitung ist es definitiv nicht. Er redet von der LuCI Automatik, was mit den Script endet.
"Finally we have a look at the script. It injects all the additionally required settings according to /etc/config/ipsec into the OpenWrt firewall."
Aber eine /etc/config/ipsec ist bei Dir nicht vorhanden.
Darüber hinaus enthält Deine iptables -L -n Ausgabe den esp Protokoll und udp 500 lediglich in der zone_wan_forward, wo sie nichts zu verlieren haben. In der zone_wan_input und zone_wan_output fehlen sie dagegen. Den udp 4500 vermisse ich gänzlich.
Ein halbwegs vernünftiger iptables -L Ausgabe dürfte ungefähr so (bzw. analog dazu) aussehen.
So forschen wir also weiter.
Albert
Kannst du mir vielleicht eine /etc/config/firewall geben, die diese iptable-Einstellungen bewirkt?
Nur mit Vorbehalt zurzeit. Warum Vorbehalt: die Doku erwähnt, dass die Zone VPN mit LuCI angelegt werden sollte und hat keinen physikalischen Interface.
Soweit warst Du schon, "Die Zone 'vpn' habe ich mittels LuCI auch noch anlegen können.". Meine Vermutung ist, dass wenn Du VPN mit LuCI anlegst, dann entsteht doch die /etc/config/ipsec und hat einen Inhalt.
Wenn es so ist, dann würde es mich sehr interessieren, was dort drin steht! Wenn nicht, dann hätte ich noch eine Idee.
Noch etwas: The iptables rules generated for this section rely on the state match which needs connection tracking to work. At least one of the src or dest zones needs to have connection tracking enabled through either the masq or the conntrack option. Das habe ich jetzt entsprechend geändert.
Albert
Kann es sein, dass man das ganze, wenn man OpenVPN nutzt, via Webinterface (LUCI) machen kann? Sieht hier auf dem ersten Blick so aus:
http://wiki.openwrt.org/doc/howto/vpn.client.openvpn.tun
naja meines Wissen ist strongswan halt ipsec und openvpn halt openvpn das sind zwei komplett unterschiedliche Sachen.
Hast du dir das schon mal durchgelesen?
http://wiki.openwrt.org/doc/howto/vpn.ipsec.basics
ka ob das hilft war nur der erste Treffer in google 
Grüße
Martin
Hmm, kann es sein, daß man OpenVPN und StrongSWAN nicht "mischen" kann?
OpenVPN und strongSwan auf demselben Server mit dem gleichen Protokoll kann es nicht gehen. Sind die Protokolle unterschiedlich, z.B. IPSec und PPTP, dann kann es schon funktionieren, aber wofür die Mühe? An Deiner Stelle würde ich strongSwan doch noch eine Chance geben. OpenVPN soll um Einiges behäbiger sein, was die Benchmarks betrifft. Wie auch immer, auf dem Server stehst Du in beiden Fällen vor dasselbe Problem: Firewall Konfiguration. 
Also StrongSWAN auf dem Server und OpenVPN auf dem Client?
Was läuft auf dem Client? OpneVPN?
Wenn Du die Lust noch nicht verloren hast, gehen wir die Sache Schritt für Schritt durch:
1. Zeige bitte die Ausgabe von ifconfig. Deine /etc/config/network kenne ich schon, aber wer weiß.
2. Lege die Zone nach birnenschnitzels Anleitung an:
(LuCI -> Network -> Firewall -> Zones -> Add
Name: vpn
Input: reject
Output: accept
Forward: reject
Allow forward from source zones: Haken.
Alles Andere nicht definieren, kein Haken!)
und zeige bitte den Screenshot mit der VPN Zone ab Zone ==> Forwardings.
Ich hoffe vpn: (empty) wird dann angezeigt.
Albert
An Deiner Stelle würde ich strongSwan doch noch eine Chance geben.
Gerne! Wäre mir auch lieber, nur *eine* Variante zu haben ;-).
Zitat
...auf dem Server stehst Du in beiden Fällen vor dasselbe Problem: Firewall Konfiguration.
Nur damit da kein Mißverständnis besteht: das Problem ist der Client! Der Server (openSUSE 13.2 mit StrongSWAN) funktioniert wunderbar mit einem anderen Client (OpenWRT 10.03.1 "Backfire" mit openSWAN).
Zitat
Was läuft auf dem Client? OpneVPN?
Auf dem "Problem-Client" läuft openWRT 15.05 mit StrongSWAN 5.3.3-1.
Zitat
Wenn Du die Lust noch nicht verloren hast,...
Keinesfalls - ich brauch unbedingt eine Lösung!
Danke, daß du so viel Geduld hast ;-).
Zitat
1. Zeige bitte die Ausgabe von ifconfig. Deine /etc/config/network kenne ich schon, aber wer weiß.
Zitat
2. Lege die Zone nach birnenschnitzels Anleitung an:
...
und zeige bitte den Screenshot mit der VPN Zone ab Zone ==> Forwardings.
Ich hoffe vpn: (empty) wird dann angezeigt.
Siehe Anhang.
Klaus
OK, das sind weitere verwertbare Informationen.
Der Client ist OpenWRT mit einem public IP und mit einem Subnet. Du hast aber auch einen Server.
88.xx.xx.220[racoon.tvdr.de] hat keine lokale IP
Wieso hat er keinen Subnet, nur public IP? Ich spreche es deswegen an, weil dass die Sache enorm vereinfachter würde, wenn er auch einen Subnet hätte. Du willst doch nicht auf einem public IP, sondern auf die Adresse(n) dahinter landen. Oder?
Auf dem Screenschot wird die These von birnenschnitzel deutlich bestätigt, warum die Tunnel nicht greift. Auf dem Bild als forward liegt wan vor vpn! Genau darin liegt unser (lösbares) Problem, bzw. es gibt bereits forwards, aber verquer.
Morgen, nicht gleich früh, kommt von mir mehr. 
Albert
Wieso hat er keinen Subnet, nur public IP?
Der Server ist nur ein einzelner Rechner, der beim Provider steht und eine feste IP hat. Es gibt keine Rechner "dahinter".
Über das VPN habe ich meinen OpenWRT-Router zuhause (und dessen lokales Netz) an den Server angebunden, so daß dieser z.B. Emails in mein lokales Netz zustellen kann, obwohl mein Router alle 24 Stunden eine neue IP von der Telekom bekommt. OK, letzteres Problem wäre bei Kabel-Deutschland nicht mehr so dramatisch, weil da die IP konstant bleibt, so lange der KD-Router (ich betreibe ihn im Bridge-Mode) nicht neu gebootet wird. Aber grundsätzlich muß ich auch hier damit zurecht kommen, daß die IP nicht fest ist.
Klaus
warum eigentlich nicht VPN ueber ssh (Option -w) nutzen? Die dazu noetigen ssh Features sollten ja immerhin sogar auf so einem verkorksten Router-System wie z.B. OpenWRT laufen:-)
Klaus, ich habe mir das Basic angesehen. Dort steht:
"We cannot provide a graphical user interface at the moment but at least it is a solid alternative to commercial IPsec appliances."
"The major challenge is handling all of those files automatically with a clean integration into the OpenWrt configuration concept."
Außerdem ist es so, dass Du die /etc/config/ipsec manuell anlegen musst. Dort wird alles definiert, was gebraucht wird. Anschließend musst Du das Script ausführen, welche alles nötige für Charon automatisch generiert. Wenn Du das Script anschaust, dann wird ersichtlich, dass z.B. ipsec.conf, aber auch strongswan.conf gelöscht und anschließend verlinkt werden.
Ich habe jetzt die /etc/config/ipsec für Dich erstellt. Das Script wurde für eine net2net Szenario geschrieben. Ich bin mir nicht sicher, was ich bei remote_subnet einzutragen habe, denn den haben wir nicht. Mache also erstmal einen dry run und prüfe mit LuCI ob ipsec startet. Wenn ja, dann müssen wir die neu erstellte ipsec.conf noch einmal betrachten.
Vergiss nicht in der /etc/config/ipsec die richtige IP und das PSK einzutragen!
"Before you start Charon with the web interface you should make a dry run from command line. This will show you if there are any errors in your generated configuration file /etc/ipsec.conf. Afterwards you can control startup behaviour with LuCI."
Die FW Zone hast Du gestern anlegen können, das hier also ist die nächste Hürde.
Albert
und die erzeugte ipsec.conf besteht nur aus der Zeile
version 2
Upps. Was und wie hast Du ursprünglich konfiguriert, bevor Du den Thread gestartet hast?
Albert
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
