freebsd, ipsec, racoon

Xartax · 10 September 2017

Hallo alle,
wurde im xchat geben hier einen thread aufzumachen und hier ein paar infos zu meinem system zu geben und was ich damit machen will. da dauert etwas bis ich hier alles detailiert darstellen kann, weil doch zeimlich umfangreich

der große schwarze kasten in der mitte des Rack ist mein server, das gelbe lankabel ist der vdsl anschluss. unten ist noch ein tp-link managed switch.
Aktuell geht da alles drüber, Internet, Telefon, Fernsehen.

hier der interne Netzplan,

so, und hier was noch werden soll. Das IPsec-Tunnel Interface soll auf em0 lauschen und der Traffic soll über den router geroutet werden. Aber das geht anscheinen nur wenn man den kernel neu baut, was wegen der aktuell Nutzung nicht gemacht werden kann. Also muss der IPsec tunnel auf tun0 lauschen was mir nich tgefällt.

Xartax · 10 September 2017

Nach dem Mittagessen kann ich nun den 1. Post nicht leider mehr anpassen.

Natürlich kann man auch openVPN verwenden, das hat aber einen große Nachteil, weil dann bei allen PC's als auch Smartphones eine openVPN Client installiert werden muss. Wenn der IPsec service funktioniert, dann ist es einfacher in den Endgeräten. Smartphones unterstützen IPSec von haus aus.

Zu erst wollte ich mich an den Fritzboxen anmelden, mittlerweile denke ich dass es besser ist, wenn die sich beim server anmelden. Also will ich einen IPSec service einrichten. Und wie ich aus verschiedenen Anleitungen herausgelesen habe geht das nur mit dem Interface das die öffentliche IP-Adressse hat. Und das ist bei mir "tun0"

Um nun IPSec richtig konfigurieren zu können muss ich verstehen wie IPSec funktioiert. In den verschiedenen Anleitungen die ich im Internet gefunden habe, wird immer nur erklärt wie man es konfiguriert oder wie das Verschlüsselungsverfahren funktioniert.

Beispiel: beim pppoe wird automatisch das Interface tunX erstellt. X ist die Laufende Nummer 0 beim 1. interface auf tun device. Auch bei openVPN wird das Tunnelinterface tunX vom openVPN Dienst erstellt.

Aber wie funktioniert das bei IPSec? Wenn sich zum beispiel die Fritzbox 1 anmeldet, dann muss dochvfür diese fritzbox ein Tunnelinterface enstehen, wie entsteht das?

Auch ist mir unklar was racoon macht, irgendwie hab ich herausgelesen, dass racoon die schlüssel austauscht und die Authorisierung überprüft. Unklar ist mir auch wie man einen IPSec service konfigurieren muss.

Fragen über Fragen, viel gefunden und dennoch nichts verstanden.

Vielleicht kann mir da jemand Licht ins dunkel bringen.

grüße

Xartax · 11 September 2017

update:
im xchat hat mir jemand strongswan empfohlen.
Aktuell komme ichmit strongswan bis zur fase2

11:43:55.241542 IP tmo-102-2.customers.d1-online.com.isakmp > p4FE8A3A2.dip0.t-ipconnect.de.isakmp: isakmp: phase 1 I ident
11:43:55.241853 IP p4FE8A3A2.dip0.t-ipconnect.de.isakmp > tmo-102-2.customers.d1-online.com.isakmp: isakmp: phase 2/others R inf

das ganze wiederholt sich dann

hat jemand einen tipp wie ich das debuggen kann

Update:
hab festgestellt, dass ipsec die falsche ipsec.conf verwendet hatte. Jetzt verwedet ipsec die richtige ipsec.conf. Jedoch bekomme ich parsing fehler

Xartax · 11 September 2017

update:
hab festgestellt, dass ich den dienst ipsec nicht selbst starten darf.

nun bekomme ich das:

Code:

2017-09-11T12:53:55.103125+02:00 superserver charon: 06[NET] received packet: from ....[500] to ....[500] (580 bytes)
2017-09-11T12:53:55.103184+02:00 superserver charon: 06[ENC] parsed ID_PROT request 0 [ SA V V V V V V ]
2017-09-11T12:53:55.103205+02:00 superserver charon: 06[IKE] received NAT-T (RFC 3947) vendor ID
2017-09-11T12:53:55.103216+02:00 superserver charon: 06[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID
2017-09-11T12:53:55.103243+02:00 superserver charon: 06[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
2017-09-11T12:53:55.103246+02:00 superserver charon: 06[IKE] received draft-ietf-ipsec-nat-t-ike-00 vendor ID
2017-09-11T12:53:55.103248+02:00 superserver charon: 06[IKE] received FRAGMENTATION vendor ID
2017-09-11T12:53:55.103249+02:00 superserver charon: 06[IKE] received DPD vendor ID
2017-09-11T12:53:55.103251+02:00 superserver charon: 06[IKE] ....... is initiating a Main Mode IKE_SA
2017-09-11T12:53:55.103252+02:00 superserver charon: 06[IKE] ......... is initiating a Main Mode IKE_SA
2017-09-11T12:53:55.103294+02:00 superserver charon: 06[ENC] generating ID_PROT response 0 [ SA V V V V ]
2017-09-11T12:53:55.103323+02:00 superserver charon: 06[NET] sending packet: from .........[500] to .........[500] (160 bytes)
2017-09-11T12:53:55.211995+02:00 superserver charon: 06[NET] received packet: from ........[500] to .......[500] (252 bytes)
2017-09-11T12:53:55.212015+02:00 superserver charon: 06[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
2017-09-11T12:53:55.212656+02:00 superserver charon: 06[IKE] remote host is behind NAT
2017-09-11T12:53:55.212671+02:00 superserver charon: 06[IKE] sending cert request for "C=DE, O=private, CN=......."
2017-09-11T12:53:55.212718+02:00 superserver charon: 06[ENC] generating ID_PROT response 0 [ KE No CERTREQ NAT-D NAT-D ]
2017-09-11T12:53:55.212741+02:00 superserver charon: 06[NET] sending packet: from .....[500] to ......[500] (328 bytes)
2017-09-11T12:53:55.512481+02:00 superserver charon: 06[NET] received packet: from ......[23372] to .....[4500] (1180 bytes)
2017-09-11T12:53:55.512515+02:00 superserver charon: 06[ENC] parsed ID_PROT request 0 [ ID CERT SIG CERTREQ ]
2017-09-11T12:53:55.512525+02:00 superserver charon: 06[IKE] ignoring certificate request without data
2017-09-11T12:53:55.512561+02:00 superserver charon: 06[IKE] received end entity cert "C=DE, O=private, CN=......"
2017-09-11T12:53:55.512573+02:00 superserver charon: 06[CFG] looking for RSA signature peer configs matching ......[C=DE, O=private, CN=........]
2017-09-11T12:53:55.512599+02:00 superserver charon: 06[IKE] found 1 matching config, but none allows RSA signature authentication using Main Mode
2017-09-11T12:53:55.512643+02:00 superserver charon: 06[ENC] generating INFORMATIONAL_V1 request 4119200780 [ HASH N(AUTH_FAILED) ]
2017-09-11T12:53:55.512677+02:00 superserver charon: 06[NET] sending packet: from .......[4500] to ........[23372] (108 bytes)

Xartax · 12 September 2017

Da keiner auf das Thema eingeht beende ich das nun

Thread geschlossen

das.chaos · 16 September 2017

Wer wird denn gleich die Flinte ins Korn werfen? Schon mal es versucht mit racoon2 und nen Blick ins BSD Foren Wiki geworfen?

pit234a · 16 September 2017

Aber er hat schon Recht, oder?
Der Eingangsthread ist mit Mühe aufgemacht und sieht gut dokumentiert aus. Die Probleme werden auch klar beschrieben. Aber niemand meldet sich darauf.
Ich weiß, dass ich keine Ahnung davon habe. Sollte das für die anderen Mitglieder hier auch gelten? Früher ist man hier nicht nur kompetent gewesen, sondern auch hilfsbereit.
Es müssen ja nicht immer die großen Weisheiten sein, es macht doch auch Spaß, gemeinsam eine Lösung zu finden und vielleicht sogar noch mehr, als wenn man nur belehrt,
Jedenfalls habe ich diesen Thread verfolgt und war doch sehr erstaunt, dass sich gar niemand zu Wort gemeldet hatte. Seit ich hier Mitglied bin, gab es das noch nicht oft.

Illuminatus · 16 September 2017

Bislang habe ich es hier als üblich erachtet, dass wenn man ein Problem beschreibt, dabei auch Auszüge aus Logs inklusive vollständiger Konfigurationsdateien der beteiligten Dienste (Server+Client) und Versionsnummern mitgeteilt werden - eben weil das Selbstverständlichkeiten sind, die man auch erwarten darf. Oder auch bei VPN Thematiken die Eigenschaften der Zertifikate. Meine Vermutung war, dass der Ersteller mit diesen Angaben schon heraus rücken wird, wenn er merkt dass Antworten nicht zeitnah eingehen.

das.chaos · 17 September 2017

Xartax schrieb:
Um nun IPSec richtig konfigurieren zu können muss ich verstehen wie IPSec funktioiert. In den verschiedenen Anleitungen die ich im Internet gefunden habe, wird immer nur erklärt wie man es konfiguriert oder wie das Verschlüsselungsverfahren funktioniert.

Die Implementierung von ipsec(4) wird in Kapitel 13 aus http://ptgmedia.pearsoncmg.com/images/9780321968975/samplepages/9780321968975.pdf bzw. ab Seite 649 beschrieben. Wobei dieses Buch entweder via Buchhandel oder per Fernleihe ueber oeffentliche Biliotheken _legal_ erhaeltlich ist, statt sich das vollstaendige .pdf per Suchmaschine zu suchen, was moeglicherweise funktionieren wuerde [wobei nicht sicher bin, ob das tatsaechlich funktioniere].

Es kaeuflich zu erwerben waere die beste Option, da die Autoren finanziell unterstuetzt werden, es dem Projekt bzw. der Allgemeinheit nuetzt und solange Kerzen [bei Dunkelheit] ein Medium ist, was ohne elektrischen Strom funktioniert.

pit234a schrieb:
Es müssen ja nicht immer die großen Weisheiten sein, es macht doch auch Spaß, gemeinsam eine Lösung zu finden und vielleicht sogar noch mehr, als wenn man nur belehrt,

Es war _nicht_ Intention zu belehren, sondern eine motivierende Frage im rhetorischen Sinne.

Yamagi · 17 September 2017

Das Buch lohnt sich auf jeden Fall. Es ist sicherlich das beste Buch über unixoide Betriebssystemkernel überhaupt. In seiner Gänze allerdings nur zu verstehen, wenn man ausreichend Vorkenntnisse in Sachen Betriebssystembau hat oder bereit ist zusätzlich zum Lesen viel zu recherchieren und Sekundärliteratur zu lesen.

Davon abgesehen ist IPsec ein sehr komplexes Thema. Das sind neben der Basistechnik mehrere Sekundärprotokolle, Verschlüsselungs- und Authetifizierungmechanismen, etc. Das zu verstehen ist tatsächlich nicht ganz einfach, vor allem wenn man in keinem der Bereiche zumindest einigermaßen bewandert ist. Einen guten Weg sich einzuarbeiten wüsste ich nun auch nicht... Ich würde vielleicht beginnen mich in IPsec selbst und seine Operationsmodi einzulesen, gefolgt von ISAKMP und IKE. Das sollte zumindest die Rolle vom Kernel, sowie von Racoon oder StrongSwan klar machen.

Xartax · 17 September 2017

Hallo,

ich habe den Thread hier aufgemacht, weil ich darum gebeten wurde das Problem detailliert zu schildern. Und weil immer nach der Hardware und mehr gefragt wird, habe ich das vorweg genommen. Ich habe dann alles Schritte dokumentiert und gewartet bis die welche mich darum baten, mir hier weiter helfen. Taten das dann aber nicht. Leider.

Ich denke, dass viele zu viel Perfektion erwarten, Perfektion darin, dass alle, die Hilfe brauchen, immer ganz genau wissen müssen was der, welcher helfen könnte, erwartet.
Aber woher sollte der, der Hilfe erbittet, wissen was der welcher helfen könnte, erwartet?

Man braucht nicht immer die Detaillierte Super-Anleitung, sondern oft reicht auch ein Wegweiser um weiter zu kommen. Ich denke dass niemand von einem Experten hier eine "Schulung" erwartet.

Allerdings hab auch ich Erwartungen and die welche helfen wollen (und es aber dann nicht tun) nämlich die, dass im Dialog erörtert wird was der Helfer braucht und welche Hilfe der Hilfebedürftige braucht. So kommt man sich gegenseitig entgegen.

Nun, hab ich im anderem Forum 2 ähnliche Thread. Der Ansatz war immer ein anderer, aber letzten läuft alles auf ipsec Zertifakte hinaus.

http://www.bsdforen.de/threads/openssl.33778/

http://www.bsdforen.de/threads/htc-one-m8-ipsec-vpn.33779/

Darum, macht es eigentlich keinen Sinn diesen Thread weiter zu füttern. Mir ist es lieber bei den anderen weiter zu machen.

derOliver · 18 September 2017

Xartax schrieb:
Ich denke, dass viele zu viel Perfektion erwarten, Perfektion darin, dass alle, die Hilfe brauchen, immer ganz genau wissen müssen was der, welcher helfen könnte, erwartet.
Aber woher sollte der, der Hilfe erbittet, wissen was der welcher helfen könnte, erwartet?

Einfach von Anfang an so viel Info geben wie möglich. Wenn du das eh schon gesammelt hast, dann her damit. Und beschreibe, was du schon versucht hast und was die konkreten Fehlermeldungen waren. Ich helfe gerne, aber wenn ich jemandem von Anfang an alle Infos aus der Nase ziehen muss, dann hab ich dazu ehrlich gesagt keine Lust

Und dann glaube ich, dass du dir mit IPSec einfach ein Thema ausgesucht hast, zu dem hier im Forum einfach wenige Leute was wissen (mich mit meinem gefährlichem Halbwissen eingeschlossen). Ich denke, das ist in diesem Fall das größte Problem. Es ist ja nicht so, dass dir keiner Helfen will

Xartax · 18 September 2017

derOliver schrieb:
Und dann glaube ich, dass du dir mit IPSec einfach ein Thema ausgesucht hast, zu dem hier im Forum einfach wenige Leute was wissen (mich mit meinem gefährlichem Halbwissen eingeschlossen). Ich denke, das ist in diesem Fall das größte Problem. Es ist ja nicht so, dass dir keiner Helfen will

FreeBSD 11 hat von Haus aus das IPSec bereits im Kernel. IPSec hat einen ziemlich umfangreiche Konfiguration. Wo ich aber keinerlei Information im Internet gefunden habe ist wozu braucht man solche Tools wie racoon oder strongwan. Wozu sind diese da. Ich kann da nur Vermuten. I Internet finde ich Informationen wie man das Konfiguriert, aber nicht wozu diese überhaupt benötigt werden. Da diese Tools aus den Port kommen und zusätzlich installiert werden müssen, gehe ich davon aus, dass IPSec auch ohne diese Tools funktionieren würde wenn man die IPSec.conf entsprechend konfiguriert. Diese Frage wurde mir nicht beantwortet und da braucht es auch keine Detaillierten Angaben sondern nur warum man diese Tools verwendet werden.

2. Problem, Nach vielen auch missglückten Versuchen hab ich es dann geschafft eine Zertifikatsaustausch mit den logs zu beobachten. Jedoch scheiterte die Authorisation wegen vermutlich fehlerhafter Konfiguration von Racoon, strongswan. Ausprobiert hatte ich das mit meinem HTC one M8. Leider, aktzeptierte das Android nur ein mal das Client-Zertifikat als Client-Zertifikat. Und weil alles auf Zertifacte hinausläuft habe ich nach Anleitun, welche ich in Internet gefunden hatte die Zertifikate erstellt. Die erstellten Client-Zertifikate wurden aber nicht mehr als Client-Zertifikate. Beim konfigurieren das Android-VPN muss ich aber ein Client-Zertifikat auswählen. die Liste der Client-Zertifikate ist da aber leer und das Client-Zertifikat wird in der Liste der Server-Zertifikate aufgelistet. Solange aber das Clinet-Zertifikat nicht in der Liste der Client-Zertifikate ausgelistet wird, kann ich einen VPN nicht erstellen.

Die Frage ist also was mache ich beim der Herstellung eines Client-Zertifikates falsch, so dass es nicht als solches erkannt wird. Vielleicht kann mir mal jemand ein Client-Zertifikat erstellen um zu sehen ob das als Cleint-Zertifikat erkannt wird und ich die Möglichkeit des Vergleichens habe. Keine Angst wird nicht verwendet.

Momentan ist also das erstellen eine Client-Zertifikates das primäre Problem. Hier mal ein Versuch und es funktioniert nicht, die Liste der Nutzerzertifikate ist leer.

Code:

X509v3 Basic Constraints critical: CA:FALSE
X509v3 Subject Key Identifier: 44:5C:E6:E3:96:1E:FC:40:42:D0:F4:EA:E4:3D:89:C4:8F:D6:B5:02
X509v3 Key Usage: Digital Signature, Key Encipherment, Data Encipherment
X509v3 Extended Key Usage critical: TLS Web Client Authentication, E-mail Protection, IPSec Tunnel, IPSec User, EAP over Lan
Netscape Cert Type: SSL Client, S/MIME
Netscape Comment: xca certificate

KobRheTilla · 18 September 2017

Xartax schrieb:
FreeBSD 11 hat von Haus aus das IPSec bereits im Kernel. IPSec hat einen ziemlich umfangreiche Konfiguration. Wo ich aber keinerlei Information im Internet gefunden habe ist wozu braucht man solche Tools wie racoon oder strongwan.

Hast du dir dies mal angesehen? https://www.freebsd.org/doc/handbook/ipsec.html

Xartax · 18 September 2017

KobRheTilla schrieb:
Hast du dir dies mal angesehen? https://www.freebsd.org/doc/handbook/ipsec.html

Ja, das war das erste was ich mir angesehen habe.
Jedoch, es gibt die Wahl psk oder Zertifikate. Ich möchte es mit Zertifikaten machen. Wie oben schon beschrieben werden meine Clint-Zertifikate vom Android nicht als solches erkannt. Ich hab das nu mal in einem anderen Adroid Gerät (Nexus7) installiert und da ist es das selbe, das Zertifikat wird nicht als Clint Zertifikat erkannt.

Bevor Android meine Client Zertifikate nicht als solche erkennt, brauch ich über den Rest mir keine Gedanken machen. Da das Problem nun auf zwei verschiedenen Android Geräten das selbe ist, liegt es nicht am Gerät sondern am Zertifikat und da mach ich irgendetwas falsch. Ich hab mal das ausprobiert:

Code:

X509v3 Key Usage critical:
Digital Signature
X509v3 Extended Key Usage critical:
IPSec User
Netscape Cert Type:
SSL Client, S/MIME, Object Signing

Was ist da falsch? Fehlt irgend was? Ist was zu viel? Ich hab mal versucht im Android Quellcode die Stelle zu finden wo entschieden wird ob es ein client oder server Zertifikat iat, bin aber noch nicht fündig geworden.

Yamagi · 18 September 2017

Also, ganz simpel und hoffentlich nicht zu sehr vereinfacht: IPsec ist einfach eine Technik, die es erlaubt den Payload von IP-Paketen zu verschlüsseln und das gesamte Pakte zu authentifizieren. Somit können Dritte das Paket weder verändern, noch die Nutzdaten einsehen. Das Ganze ist ein relativ einfaches, verständliches Verfahren, die meisten Systeme implementieren es aus Effizienzgründen im Kernel.

Das Problem ist allerdings, dass die beiden Gegenseiten erst einmal zusammenkommen müssen. Sie müssen also Fragen klären wie z.B.:

Wer spricht eigentlich mit mir?
Wie soll die Verbindung gesichert werden?
Wie handeln wir einen gemeinsamen Schlüssel für diese Session aus?
Wie oft ersetzen wir den Schlüssel?

Das wird durch eigene Protokolle abgewickelt. Früher waren es zwei Stück. ISAKMP zum Aushandeln der Verbindunsparameter, IKE zum Austauschen der Schlüssel. Irgendwann wurden beide zu dem heute gebräuchlichen IKEv2 zusammengefasst. IKEv2 ist sehr, sehr komplex. Daher wird es nicht im Kernel implementiert, stattdessen im Userland als Dämon. Der Klassiker ist da Racoon, heute nutzt man aber eher das schon öfter gegannte StrongSwan. Und die meisten Netzwerker hassen IKEv2 aufgrund der Komplexität wie die Pest.

Yamagi · 18 September 2017

Xartax schrieb:
Bevor Android meine Client Zertifikate nicht als solche erkennt, brauch ich über den Rest mir keine Gedanken machen. Da das Problem nun auf zwei verschiedenen Android Geräten das selbe ist, liegt es nicht am Gerät sondern am Zertifikat und da mach ich irgendetwas falsch.

Halb blind geraten: Du brauchst DM-Zertifikate mit voller Zertifikatskette. Keine Kette, keine Kekse.

Xartax · 18 September 2017

Yamagi schrieb:
Halb blind geraten: Du brauchst DM-Zertifikate mit voller Zertifikatskette. Keine Kette, keine Kekse.

Ja, man muss das Client-Zertifikat im p12 Format mit dem ca-Zertifikat abspeichern, dann wird alles installiert, das ca und das client-Zertifikat.
Aber, nur durch ausprobieren hab ich das herausgefunden, sonst hab ich das nirgends einen hinweis gefunden.

So, nachdem das Problem nun gelöst ist, geht es an die Konfiguration von strongswan. Ich melde mich dann wieder wenn ich Probleme nicht lösen kann.

Xartax · 18 September 2017

So,

nun geht es ans eingemachte.

Handy und server kommunizieren miteinander aber eben nicht so wie gewünscht

1. Fehler:
..... selecting proposal: .... no acceptable ENCRYPTION_ALGORITHM found

hier das Protokoll

Code:

2017-09-18T16:57:05.956881+02:00 superserver charon: 03[NET] received packet: from 192.168.4.15[500] to xxx.232.162.196[500]
2017-09-18T16:57:05.956923+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-18T16:57:05.957006+02:00 superserver charon: 15[NET] received packet: from 192.168.4.15[500] to xxx.232.162.196[500] (612 bytes)
2017-09-18T16:57:05.957113+02:00 superserver charon: 15[ENC] parsed ID_PROT request 0 [ SA V V V V V V V V ]
2017-09-18T16:57:05.957122+02:00 superserver charon: 15[CFG] looking for an ike config for xxx.yyy.162.196...192.168.4.15
2017-09-18T16:57:05.957131+02:00 superserver charon: 15[CFG]   candidate: %any...%any, prio 24
2017-09-18T16:57:05.957136+02:00 superserver charon: 15[CFG] found matching ike config: %any...%any with prio 24
2017-09-18T16:57:05.957156+02:00 superserver charon: 15[IKE] received NAT-T (RFC 3947) vendor ID
2017-09-18T16:57:05.957159+02:00 superserver charon: 15[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID
2017-09-18T16:57:05.957165+02:00 superserver charon: 15[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
2017-09-18T16:57:05.957170+02:00 superserver charon: 15[IKE] received draft-ietf-ipsec-nat-t-ike-00 vendor ID
2017-09-18T16:57:05.957174+02:00 superserver charon: 15[IKE] received XAuth vendor ID
2017-09-18T16:57:05.957178+02:00 superserver charon: 15[IKE] received Cisco Unity vendor ID
2017-09-18T16:57:05.957181+02:00 superserver charon: 15[IKE] received FRAGMENTATION vendor ID
2017-09-18T16:57:05.957189+02:00 superserver charon: 15[IKE] received DPD vendor ID
2017-09-18T16:57:05.957204+02:00 superserver charon: 15[IKE] 192.168.4.15 is initiating a Main Mode IKE_SA
2017-09-18T16:57:05.957208+02:00 superserver charon: 15[IKE] 192.168.4.15 is initiating a Main Mode IKE_SA
2017-09-18T16:57:05.957215+02:00 superserver charon: 15[IKE] IKE_SA (unnamed)[1] state change: CREATED => CONNECTING
2017-09-18T16:57:05.957237+02:00 superserver charon: 15[CFG] selecting proposal:
2017-09-18T16:57:05.957245+02:00 superserver charon: 15[CFG]   no acceptable ENCRYPTION_ALGORITHM found
2017-09-18T16:57:05.957248+02:00 superserver charon: 15[CFG] selecting proposal:
2017-09-18T16:57:05.957255+02:00 superserver charon: 15[CFG]   no acceptable ENCRYPTION_ALGORITHM found
2017-09-18T16:57:05.957258+02:00 superserver charon: 15[CFG] selecting proposal:
2017-09-18T16:57:05.957263+02:00 superserver charon: 15[CFG]   no acceptable ENCRYPTION_ALGORITHM found
2017-09-18T16:57:05.957265+02:00 superserver charon: 15[CFG] selecting proposal:
2017-09-18T16:57:05.957275+02:00 superserver charon: 15[CFG]   no acceptable DIFFIE_HELLMAN_GROUP found
2017-09-18T16:57:05.957278+02:00 superserver charon: 15[CFG] selecting proposal:
2017-09-18T16:57:05.957283+02:00 superserver charon: 15[CFG]   no acceptable PSEUDO_RANDOM_FUNCTION found
2017-09-18T16:57:05.957285+02:00 superserver charon: 15[CFG] selecting proposal:
2017-09-18T16:57:05.957292+02:00 superserver charon: 15[CFG]   no acceptable PSEUDO_RANDOM_FUNCTION found
2017-09-18T16:57:05.957295+02:00 superserver charon: 15[CFG] selecting proposal:
2017-09-18T16:57:05.957301+02:00 superserver charon: 15[CFG]   no acceptable ENCRYPTION_ALGORITHM found
2017-09-18T16:57:05.957303+02:00 superserver charon: 15[CFG] selecting proposal:
2017-09-18T16:57:05.957309+02:00 superserver charon: 15[CFG]   no acceptable ENCRYPTION_ALGORITHM found
2017-09-18T16:57:05.957311+02:00 superserver charon: 15[CFG] selecting proposal:
.
.
.
.

und hier die ipsec.conf, die ich im internet als Beispiel gefunden habe

Code:

config setup
      #uniqueids=yes
        charondebug="cfg 2, dmn 2, ike 2, net 2"

conn %default
      keyingtries=1
      # always use certificates
      authby=rsasig
      rightrsasigkey=%cert
      auto=add
      # lokaler Endpunkt (left)
      left=%defaultroute
      leftcert=server_cert_xxx.de.crt
      leftupdown=/usr/local/lib/ipsec/updown

conn p2p
      right=%any

conn p2n
      right=%any
      leftsubnet=10.0.0.0/8

conn n2n
      right=%any
      rightsubnetwithin=192.168.0.0/16
      leftsubnet=10.0.0.0/8

#conn xp-n2n
#      right=%any
#      rightid="C=DE, L=Hannover, O=Heise Verlag, CN=ju@ct.heise.de"
#      rightsubnet=192.168.1.2/32
#      leftsubnet=10.0.0.0/8

Xartax · 19 September 2017

ok, bin schon wieder weiter. Einige Fehler in der ipsec.secrets wurden beseitigt.

De Austausch der Schlüssel scheint nun zu funktionieren scheitert aber im Netzwerkaufbau zu scheitern
Interesannt ist wol das: "no matching CHILD_SA config found"
Inder ipsec.conf wie oben bereits hochgeladen hat sich nichts geändert

Hat jemand einen Tipp :confused:

hier den relevanten.

Code:

2017-09-19T11:37:48.606839+02:00 superserver charon: 15[IKE] IKE_SA p2p[2] state change: CONNECTING => ESTABLISHED
2017-09-19T11:37:48.606842+02:00 superserver charon: 15[IKE] scheduling reauthentication in 9913s
2017-09-19T11:37:48.606843+02:00 superserver charon: 15[IKE] maximum IKE_SA lifetime 10453s
2017-09-19T11:37:48.606860+02:00 superserver charon: 15[IKE] sending end entity cert "C=DE, ST=Deutschland, O=privat, CN=intern.xxxx.yy, E=abuse@xxxx.yy"
2017-09-19T11:37:48.606880+02:00 superserver charon: 15[ENC] generating ID_PROT response 0 [ ID CERT SIG ]
2017-09-19T11:37:48.606920+02:00 superserver charon: 15[ENC] splitting IKE message with length of 1436 bytes into 2 fragments
2017-09-19T11:37:48.606933+02:00 superserver charon: 15[ENC] generating ID_PROT response 0 [ FRAG(1) ]
2017-09-19T11:37:48.606952+02:00 superserver charon: 15[ENC] generating ID_PROT response 0 [ FRAG(2/2) ]
2017-09-19T11:37:48.606969+02:00 superserver charon: 15[NET] sending packet: from aaa.bbb.162.196[500] to 192.168.4.15[500] (1252 bytes)
2017-09-19T11:37:48.606978+02:00 superserver charon: 15[NET] sending packet: from aaa.bbb.162.196[500] to 192.168.4.15[500] (256 bytes)
2017-09-19T11:37:48.606992+02:00 superserver charon: 04[NET] sending packet: from aaa.bbb.162.196[500] to 192.168.4.15[500]
2017-09-19T11:37:48.607020+02:00 superserver charon: 04[NET] sending packet: from aaa.bbb.162.196[500] to 192.168.4.15[500]
2017-09-19T11:37:48.611150+02:00 superserver charon: 03[NET] received packet: from 192.168.4.15[500] to aaa.bbb.162.196[500]
2017-09-19T11:37:48.611163+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T11:37:48.611184+02:00 superserver charon: 14[NET] received packet: from 192.168.4.15[500] to aaa.bbb.162.196[500] (124 bytes)
2017-09-19T11:37:48.611201+02:00 superserver charon: 14[ENC] parsed INFORMATIONAL_V1 request 2718894288 [ HASH N(INITIAL_CONTACT) ]
2017-09-19T11:37:49.615571+02:00 superserver charon: 03[NET] received packet: from 192.168.4.15[500] to aaa.bbb.162.196[500]
2017-09-19T11:37:49.615624+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T11:37:49.615632+02:00 superserver charon: 14[NET] received packet: from 192.168.4.15[500] to aaa.bbb.162.196[500] (476 bytes)
2017-09-19T11:37:49.615697+02:00 superserver charon: 14[ENC] parsed QUICK_MODE request 3362626218 [ HASH SA No ID ID ]
2017-09-19T11:37:49.616233+02:00 superserver charon: 14[CFG] looking for a child config for aaa.bbb.162.196/32[udp/l2f] === 192.168.4.15/32[udp]
2017-09-19T11:37:49.616242+02:00 superserver charon: 14[CFG] proposing traffic selectors for us:
2017-09-19T11:37:49.616247+02:00 superserver charon: 14[CFG]  aaa.bbb.162.196/32
2017-09-19T11:37:49.616253+02:00 superserver charon: 14[CFG] proposing traffic selectors for other:
2017-09-19T11:37:49.616256+02:00 superserver charon: 14[CFG]  192.168.4.15/32
2017-09-19T11:37:49.616265+02:00 superserver charon: 14[CFG]   candidate "p2p" with prio 1+1
2017-09-19T11:37:49.616270+02:00 superserver charon: 14[CFG] proposing traffic selectors for us:
2017-09-19T11:37:49.616281+02:00 superserver charon: 14[CFG]  10.0.0.0/8
2017-09-19T11:37:49.616283+02:00 superserver charon: 14[CFG] proposing traffic selectors for other:
2017-09-19T11:37:49.616285+02:00 superserver charon: 14[CFG]  192.168.4.15/32
2017-09-19T11:37:49.616286+02:00 superserver charon: 14[CFG] proposing traffic selectors for us:
2017-09-19T11:37:49.616288+02:00 superserver charon: 14[CFG]  10.0.0.0/8
2017-09-19T11:37:49.616297+02:00 superserver charon: 14[CFG] proposing traffic selectors for other:
2017-09-19T11:37:49.616312+02:00 superserver charon: 14[CFG]  192.168.0.0/16
2017-09-19T11:37:49.616319+02:00 superserver charon: 14[CFG] found matching child config "p2p" with prio 2
2017-09-19T11:37:49.616325+02:00 superserver charon: 14[CFG] selecting traffic selectors for other:
2017-09-19T11:37:49.616375+02:00 superserver charon: 14[CFG]  config: 192.168.4.15/32, received: 192.168.4.15/32[udp] => match: 192.168.4.15/32[udp]
2017-09-19T11:37:49.616383+02:00 superserver charon: 14[CFG] selecting traffic selectors for us:
2017-09-19T11:37:49.617316+02:00 superserver charon: 14[CFG]  config: aaa.bbb.162.196/32, received: aaa.bbb.162.196/32[udp/l2f] => match: aaa.bbb.162.196/32[udp/l2f]
2017-09-19T11:37:49.617320+02:00 superserver charon: 14[IKE] no matching CHILD_SA config found
2017-09-19T11:37:49.617326+02:00 superserver charon: 14[IKE] queueing INFORMATIONAL task
2017-09-19T11:37:49.617332+02:00 superserver charon: 14[IKE] activating new tasks
2017-09-19T11:37:49.617337+02:00 superserver charon: 14[IKE]   activating INFORMATIONAL task
2017-09-19T11:37:49.617362+02:00 superserver charon: 14[ENC] generating INFORMATIONAL_V1 request 136523407 [ HASH N(INVAL_ID) ]
2017-09-19T11:37:49.617384+02:00 superserver charon: 14[NET] sending packet: from aaa.bbb.162.196[500] to 192.168.4.15[500] (92 bytes)
2017-09-19T11:37:49.617393+02:00 superserver charon: 14[IKE] activating new tasks
2017-09-19T11:37:49.617397+02:00 superserver charon: 14[IKE] nothing to initiate
2017-09-19T11:37:49.617410+02:00 superserver charon: 04[NET] sending packet: from aaa.bbb.162.196[500] to 192.168.4.15[500]
2017-09-19T11:37:52.632140+02:00 superserver charon: 03[NET] received packet: from 192.168.4.15[500] to aaa.bbb.162.196[500]
2017-09-19T11:37:52.632155+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T11:37:52.632224+02:00 superserver charon: 14[NET] received packet: from 192.168.4.15[500] to aaa.bbb.162.196[500] (476 bytes)
2017-09-19T11:37:52.632248+02:00 superserver charon: 14[IKE] received retransmit of request with ID 3362626218, but no response to retransmit
2017-09-19T11:37:55.636802+02:00 superserver charon: 03[NET] received packet: from 192.168.4.15[500] to aaa.bbb.162.196[500]
2017-09-19T11:37:55.636816+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T11:37:55.636871+02:00 superserver charon: 14[NET] received packet: from 192.168.4.15[500] to aaa.bbb.162.196[500] (476 bytes)

Xartax · 19 September 2017

Hi,

ich muss noch bemerken, dass die Test-Verbindung im Lan statt gefunden hatte. hier das komplette Log mit einer Externen Verbindung über das intenret

Bei openVPN wird ein tunx Interface erstellt, wie ist das bei IPSec? Ist es da ebenso oder wie funktioniert das? Und, hab ich eventuell ein Firewall Problem? Unten noch die ipf.conf

Wäre nett, wenn sich Jemand sie Mühe macht sich das mal anzusehen. So langsam komm ich mir vor wie ein Alleinunterhalter

Code:

2017-09-19T13:05:35.807794+02:00 superserver charon: 03[NET] received packet: from 80.187.119.162[500] to 79.232.162.196[500]
2017-09-19T13:05:35.807796+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T13:05:35.807881+02:00 superserver charon: 14[NET] received packet: from 80.187.119.162[500] to 79.232.162.196[500] (580 bytes)
2017-09-19T13:05:35.807952+02:00 superserver charon: 14[ENC] parsed ID_PROT request 0 [ SA V V V V V V ]
2017-09-19T13:05:35.807960+02:00 superserver charon: 14[CFG] looking for an ike config for 79.232.162.196...80.187.119.162
2017-09-19T13:05:35.807962+02:00 superserver charon: 14[CFG]   candidate: %any...%any, prio 24
2017-09-19T13:05:35.808118+02:00 superserver charon: 14[CFG] found matching ike config: %any...%any with prio 24
2017-09-19T13:05:35.808154+02:00 superserver charon: 14[IKE] received NAT-T (RFC 3947) vendor ID
2017-09-19T13:05:35.808172+02:00 superserver charon: 14[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID
2017-09-19T13:05:35.808186+02:00 superserver charon: 14[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
2017-09-19T13:05:35.808198+02:00 superserver charon: 14[IKE] received draft-ietf-ipsec-nat-t-ike-00 vendor ID
2017-09-19T13:05:35.808212+02:00 superserver charon: 14[IKE] received FRAGMENTATION vendor ID
2017-09-19T13:05:35.808226+02:00 superserver charon: 14[IKE] received DPD vendor ID
2017-09-19T13:05:35.808243+02:00 superserver charon: 14[IKE] 80.187.119.162 is initiating a Main Mode IKE_SA
2017-09-19T13:05:35.808255+02:00 superserver charon: 14[IKE] 80.187.119.162 is initiating a Main Mode IKE_SA
2017-09-19T13:05:35.808289+02:00 superserver charon: 14[IKE] IKE_SA (unnamed)[3] state change: CREATED => CONNECTING
2017-09-19T13:05:35.808348+02:00 superserver charon: 14[CFG] selecting proposal:
2017-09-19T13:05:35.808411+02:00 superserver charon: 14[CFG]   no acceptable ENCRYPTION_ALGORITHM found
2017-09-19T13:05:35.808416+02:00 superserver charon: 14[CFG] selecting proposal:
2017-09-19T13:05:35.808418+02:00 superserver charon: 14[CFG]   no acceptable ENCRYPTION_ALGORITHM found
2017-09-19T13:05:35.808421+02:00 superserver charon: 14[CFG] selecting proposal:
2017-09-19T13:05:35.808425+02:00 superserver charon: 14[CFG]   no acceptable ENCRYPTION_ALGORITHM found
2017-09-19T13:05:35.808426+02:00 superserver charon: 14[CFG] selecting proposal:
2017-09-19T13:05:35.808432+02:00 superserver charon: 14[CFG]   no acceptable DIFFIE_HELLMAN_GROUP found
2017-09-19T13:05:35.808438+02:00 superserver charon: 14[CFG] selecting proposal:
2017-09-19T13:05:35.808439+02:00 superserver charon: 14[CFG]   no acceptable PSEUDO_RANDOM_FUNCTION found
2017-09-19T13:05:35.808441+02:00 superserver charon: 14[CFG] selecting proposal:
2017-09-19T13:05:35.808445+02:00 superserver charon: 14[CFG]   no acceptable PSEUDO_RANDOM_FUNCTION found
2017-09-19T13:05:35.808447+02:00 superserver charon: 14[CFG] selecting proposal:
2017-09-19T13:05:35.808458+02:00 superserver charon: 14[CFG]   no acceptable ENCRYPTION_ALGORITHM found
2017-09-19T13:05:35.808463+02:00 superserver charon: 14[CFG] selecting proposal:
2017-09-19T13:05:35.808465+02:00 superserver charon: 14[CFG]   no acceptable ENCRYPTION_ALGORITHM found
2017-09-19T13:05:35.808467+02:00 superserver charon: 14[CFG] selecting proposal:
2017-09-19T13:05:35.808469+02:00 superserver charon: 14[CFG]   no acceptable ENCRYPTION_ALGORITHM found
2017-09-19T13:05:35.808470+02:00 superserver charon: 14[CFG] selecting proposal:
2017-09-19T13:05:35.808472+02:00 superserver charon: 14[CFG]   no acceptable ENCRYPTION_ALGORITHM found
2017-09-19T13:05:35.808474+02:00 superserver charon: 14[CFG] selecting proposal:
2017-09-19T13:05:35.808476+02:00 superserver charon: 14[CFG]   no acceptable ENCRYPTION_ALGORITHM found
2017-09-19T13:05:35.808478+02:00 superserver charon: 14[CFG] selecting proposal:
2017-09-19T13:05:35.808480+02:00 superserver charon: 14[CFG]   no acceptable ENCRYPTION_ALGORITHM found
2017-09-19T13:05:35.808484+02:00 superserver charon: 14[CFG] selecting proposal:
2017-09-19T13:05:35.808498+02:00 superserver charon: 14[CFG]   proposal matches
2017-09-19T13:05:35.808540+02:00 superserver charon: 14[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:AES_CBC_128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:3DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024, IKE:DES_CBC/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024, IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024, IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
2017-09-19T13:05:35.808564+02:00 superserver charon: 14[CFG] configured proposals: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519, IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_MD5_96/HMAC_SHA1_96/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_MD5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_1024, IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_MD5/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_8192/MODP_2048/MODP_1024
2017-09-19T13:05:35.808570+02:00 superserver charon: 14[CFG] selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1024
2017-09-19T13:05:35.808591+02:00 superserver charon: 14[IKE] sending XAuth vendor ID
2017-09-19T13:05:35.808612+02:00 superserver charon: 14[IKE] sending DPD vendor ID
2017-09-19T13:05:35.808618+02:00 superserver charon: 14[IKE] sending FRAGMENTATION vendor ID
2017-09-19T13:05:35.808620+02:00 superserver charon: 14[IKE] sending NAT-T (RFC 3947) vendor ID
2017-09-19T13:05:35.808645+02:00 superserver charon: 14[ENC] generating ID_PROT response 0 [ SA V V V V ]
2017-09-19T13:05:35.808676+02:00 superserver charon: 14[NET] sending packet: from 79.232.162.196[500] to 80.187.119.162[500] (160 bytes)
2017-09-19T13:05:35.808698+02:00 superserver charon: 04[NET] sending packet: from 79.232.162.196[500] to 80.187.119.162[500]
2017-09-19T13:05:35.890745+02:00 superserver charon: 03[NET] received packet: from 80.187.119.162[500] to 79.232.162.196[500]
2017-09-19T13:05:35.890762+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T13:05:35.890866+02:00 superserver charon: 14[NET] received packet: from 80.187.119.162[500] to 79.232.162.196[500] (252 bytes)
2017-09-19T13:05:35.890875+02:00 superserver charon: 14[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
2017-09-19T13:05:35.891718+02:00 superserver charon: 14[IKE] remote host is behind NAT
2017-09-19T13:05:35.891748+02:00 superserver charon: 14[IKE] sending cert request for "C=DE, ST=Deutschland, O=privat, CN=Root CA yyyy.de, E=abuse@yyyy.de"
2017-09-19T13:05:35.891810+02:00 superserver charon: 14[ENC] generating ID_PROT response 0 [ KE No CERTREQ NAT-D NAT-D ]
2017-09-19T13:05:35.891827+02:00 superserver charon: 14[NET] sending packet: from 79.232.162.196[500] to 80.187.119.162[500] (391 bytes)
2017-09-19T13:05:35.891856+02:00 superserver charon: 04[NET] sending packet: from 79.232.162.196[500] to 80.187.119.162[500]
2017-09-19T13:05:36.134857+02:00 superserver charon: 03[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500]
2017-09-19T13:05:36.134883+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T13:05:36.134980+02:00 superserver charon: 14[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500] (1340 bytes)
2017-09-19T13:05:36.134989+02:00 superserver charon: 14[ENC] parsed ID_PROT request 0 [ ID CERT SIG CERTREQ ]
2017-09-19T13:05:36.134991+02:00 superserver charon: 14[IKE] ignoring certificate request without data
2017-09-19T13:05:36.135029+02:00 superserver charon: 14[IKE] received end entity cert "C=DE, ST=Deutschland, O=privat, CN=xxxx yyyy, E=xxxx@yyyy.de"
2017-09-19T13:05:36.135052+02:00 superserver charon: 14[CFG] looking for RSA signature peer configs matching 79.232.162.196...80.187.119.162[C=DE, ST=Deutschland, O=privat, CN=xxxx yyyy, E=xxxx@yyyy.de]
2017-09-19T13:05:36.135078+02:00 superserver charon: 14[CFG]   candidate "p2p", match: 1/1/24 (me/other/ike)
2017-09-19T13:05:36.135083+02:00 superserver charon: 14[CFG] selected peer config "p2p"
2017-09-19T13:05:36.135117+02:00 superserver charon: 14[CFG]   using certificate "C=DE, ST=Deutschland, O=privat, CN=xxxx yyyy, E=xxxx@yyyy.de"
2017-09-19T13:05:36.135145+02:00 superserver charon: 14[CFG]   certificate "C=DE, ST=Deutschland, O=privat, CN=xxxx yyyy, E=xxxx@yyyy.de" key: 2048 bit RSA
2017-09-19T13:05:36.135166+02:00 superserver charon: 14[CFG]   using trusted ca certificate "C=DE, ST=Deutschland, O=privat, CN=Root CA yyyy.de, E=abuse@yyyy.de"
2017-09-19T13:05:36.135174+02:00 superserver charon: 14[CFG] checking certificate status of "C=DE, ST=Deutschland, O=privat, CN=xxxx yyyy, E=xxxx@yyyy.de"
2017-09-19T13:05:36.135184+02:00 superserver charon: 14[CFG] ocsp check skipped, no ocsp found
2017-09-19T13:05:36.135211+02:00 superserver charon: 14[CFG] certificate status is not available
2017-09-19T13:05:36.135227+02:00 superserver charon: 14[CFG]   certificate "C=DE, ST=Deutschland, O=privat, CN=Root CA yyyy.de, E=abuse@yyyy.de" key: 2048 bit RSA
2017-09-19T13:05:36.135232+02:00 superserver charon: 14[CFG]   reached self-signed root ca with a path length of 0
2017-09-19T13:05:36.135284+02:00 superserver charon: 14[IKE] authentication of 'C=DE, ST=Deutschland, O=privat, CN=xxxx yyyy, E=xxxx@yyyy.de' with RSA_EMSA_PKCS1_NULL successful
2017-09-19T13:05:36.136429+02:00 superserver charon: 14[IKE] authentication of 'C=DE, ST=Deutschland, O=privat, CN=intern.yyyy.de, E=abuse@yyyy.de' (myself) successful
2017-09-19T13:05:36.136448+02:00 superserver charon: 14[IKE] deleting duplicate IKE_SA for peer 'C=DE, ST=Deutschland, O=privat, CN=xxxx yyyy, E=xxxx@yyyy.de' due to uniqueness policy
2017-09-19T13:05:36.136455+02:00 superserver charon: 14[IKE] queueing ISAKMP_DELETE task
2017-09-19T13:05:36.136457+02:00 superserver charon: 14[IKE] activating new tasks
2017-09-19T13:05:36.136459+02:00 superserver charon: 14[IKE]   activating ISAKMP_DELETE task
2017-09-19T13:05:36.136475+02:00 superserver charon: 14[IKE] deleting IKE_SA p2p[2] between 79.232.162.196[C=DE, ST=Deutschland, O=privat, CN=intern.yyyy.de, E=abuse@yyyy.de]...192.168.4.15[C=DE, ST=Deutschland, O=privat, CN=xxxx yyyy, E=xxxx@yyyy.de]
2017-09-19T13:05:36.136493+02:00 superserver charon: 14[IKE] deleting IKE_SA p2p[2] between 79.232.162.196[C=DE, ST=Deutschland, O=privat, CN=intern.yyyy.de, E=abuse@yyyy.de]...192.168.4.15[C=DE, ST=Deutschland, O=privat, CN=xxxx yyyy, E=xxxx@yyyy.de]
2017-09-19T13:05:36.136501+02:00 superserver charon: 14[IKE] sending DELETE for IKE_SA p2p[2]
2017-09-19T13:05:36.136514+02:00 superserver charon: 14[IKE] IKE_SA p2p[2] state change: ESTABLISHED => DELETING
2017-09-19T13:05:36.136535+02:00 superserver charon: 14[ENC] generating INFORMATIONAL_V1 request 432191884 [ HASH D ]
2017-09-19T13:05:36.136565+02:00 superserver charon: 14[NET] sending packet: from 79.232.162.196[500] to 192.168.4.15[500] (108 bytes)
2017-09-19T13:05:36.136578+02:00 superserver charon: 14[IKE] IKE_SA p2p[2] state change: DELETING => DESTROYING
2017-09-19T13:05:36.136612+02:00 superserver charon: 14[IKE] IKE_SA p2p[3] established between 79.232.162.196[C=DE, ST=Deutschland, O=privat, CN=intern.yyyy.de, E=abuse@yyyy.de]...80.187.119.162[C=DE, ST=Deutschland, O=privat, CN=xxxx yyyy, E=xxxx@yyyy.de]
2017-09-19T13:05:36.136625+02:00 superserver charon: 14[IKE] IKE_SA p2p[3] established between 79.232.162.196[C=DE, ST=Deutschland, O=privat, CN=intern.yyyy.de, E=abuse@yyyy.de]...80.187.119.162[C=DE, ST=Deutschland, O=privat, CN=xxxx yyyy, E=xxxx@yyyy.de]
2017-09-19T13:05:36.136647+02:00 superserver charon: 04[NET] sending packet: from 79.232.162.196[500] to 192.168.4.15[500]
2017-09-19T13:05:36.136659+02:00 superserver charon: 14[IKE] IKE_SA p2p[3] state change: CONNECTING => ESTABLISHED
2017-09-19T13:05:36.136678+02:00 superserver charon: 14[IKE] scheduling reauthentication in 9863s
2017-09-19T13:05:36.136685+02:00 superserver charon: 14[IKE] maximum IKE_SA lifetime 10403s
2017-09-19T13:05:36.136699+02:00 superserver charon: 14[IKE] sending end entity cert "C=DE, ST=Deutschland, O=privat, CN=intern.yyyy.de, E=abuse@yyyy.de"
2017-09-19T13:05:36.136718+02:00 superserver charon: 14[ENC] generating ID_PROT response 0 [ ID CERT SIG ]
2017-09-19T13:05:36.136756+02:00 superserver charon: 14[ENC] splitting IKE message with length of 1436 bytes into 2 fragments
2017-09-19T13:05:36.136766+02:00 superserver charon: 14[ENC] generating ID_PROT response 0 [ FRAG(1) ]
2017-09-19T13:05:36.136792+02:00 superserver charon: 14[ENC] generating ID_PROT response 0 [ FRAG(2/2) ]
2017-09-19T13:05:36.136815+02:00 superserver charon: 14[NET] sending packet: from 79.232.162.196[4500] to 80.187.119.162[30544] (1248 bytes)
2017-09-19T13:05:36.136825+02:00 superserver charon: 14[NET] sending packet: from 79.232.162.196[4500] to 80.187.119.162[30544] (260 bytes)
2017-09-19T13:05:36.136851+02:00 superserver charon: 04[NET] sending packet: from 79.232.162.196[4500] to 80.187.119.162[30544]
2017-09-19T13:05:36.136887+02:00 superserver charon: 04[NET] sending packet: from 79.232.162.196[4500] to 80.187.119.162[30544]
2017-09-19T13:05:36.222325+02:00 superserver charon: 03[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500]
2017-09-19T13:05:36.222341+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T13:05:36.222402+02:00 superserver charon: 13[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500] (124 bytes)
2017-09-19T13:05:36.222412+02:00 superserver charon: 13[ENC] parsed INFORMATIONAL_V1 request 3927567526 [ HASH N(INITIAL_CONTACT) ]
2017-09-19T13:05:37.216099+02:00 superserver charon: 03[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500]
2017-09-19T13:05:37.216126+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T13:05:37.216149+02:00 superserver charon: 13[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500] (476 bytes)
2017-09-19T13:05:37.216242+02:00 superserver charon: 13[ENC] parsed QUICK_MODE request 2412179458 [ HASH SA No ID ID ]
2017-09-19T13:05:37.216836+02:00 superserver charon: 13[IKE] changing received traffic selectors 10.51.162.107/32[udp]=== 79.232.162.196/32[udp/l2f] due to NAT
2017-09-19T13:05:37.217308+02:00 superserver charon: 13[CFG] looking for a child config for 79.232.162.196/32[udp/l2f] === 80.187.119.162/32[udp]
2017-09-19T13:05:37.217316+02:00 superserver charon: 13[CFG] proposing traffic selectors for us:
2017-09-19T13:05:37.217319+02:00 superserver charon: 13[CFG]  79.232.162.196/32
2017-09-19T13:05:37.217321+02:00 superserver charon: 13[CFG] proposing traffic selectors for other:
2017-09-19T13:05:37.217323+02:00 superserver charon: 13[CFG]  80.187.119.162/32
2017-09-19T13:05:37.217325+02:00 superserver charon: 13[CFG]   candidate "p2p" with prio 1+1
2017-09-19T13:05:37.217327+02:00 superserver charon: 13[CFG] proposing traffic selectors for us:
2017-09-19T13:05:37.217328+02:00 superserver charon: 13[CFG]  10.0.0.0/8
2017-09-19T13:05:37.217330+02:00 superserver charon: 13[CFG] proposing traffic selectors for other:
2017-09-19T13:05:37.217331+02:00 superserver charon: 13[CFG]  80.187.119.162/32
2017-09-19T13:05:37.217333+02:00 superserver charon: 13[CFG] proposing traffic selectors for us:
2017-09-19T13:05:37.217337+02:00 superserver charon: 13[CFG]  10.0.0.0/8
2017-09-19T13:05:37.217338+02:00 superserver charon: 13[CFG] proposing traffic selectors for other:
2017-09-19T13:05:37.217340+02:00 superserver charon: 13[CFG]  192.168.0.0/16
2017-09-19T13:05:37.217342+02:00 superserver charon: 13[CFG] found matching child config "p2p" with prio 2
2017-09-19T13:05:37.217348+02:00 superserver charon: 13[CFG] selecting traffic selectors for other:
2017-09-19T13:05:37.217389+02:00 superserver charon: 13[CFG]  config: 80.187.119.162/32, received: 80.187.119.162/32[udp] => match: 80.187.119.162/32[udp]
2017-09-19T13:05:37.217395+02:00 superserver charon: 13[CFG] selecting traffic selectors for us:
2017-09-19T13:05:37.218300+02:00 superserver charon: 13[CFG]  config: 79.232.162.196/32, received: 79.232.162.196/32[udp/l2f] => match: 79.232.162.196/32[udp/l2f]
2017-09-19T13:05:37.218306+02:00 superserver charon: 13[IKE] no matching CHILD_SA config found
2017-09-19T13:05:37.218309+02:00 superserver charon: 13[IKE] queueing INFORMATIONAL task
2017-09-19T13:05:37.218315+02:00 superserver charon: 13[IKE] activating new tasks
2017-09-19T13:05:37.218320+02:00 superserver charon: 13[IKE]   activating INFORMATIONAL task
2017-09-19T13:05:37.218342+02:00 superserver charon: 13[ENC] generating INFORMATIONAL_V1 request 4003565619 [ HASH N(INVAL_ID) ]
2017-09-19T13:05:37.218367+02:00 superserver charon: 13[NET] sending packet: from 79.232.162.196[4500] to 80.187.119.162[30544] (92 bytes)
2017-09-19T13:05:37.218388+02:00 superserver charon: 13[IKE] activating new tasks
2017-09-19T13:05:37.218398+02:00 superserver charon: 13[IKE] nothing to initiate
2017-09-19T13:05:37.218422+02:00 superserver charon: 04[NET] sending packet: from 79.232.162.196[4500] to 80.187.119.162[30544]
2017-09-19T13:05:40.308292+02:00 superserver charon: 03[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500]
2017-09-19T13:05:40.308294+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T13:05:40.308362+02:00 superserver charon: 13[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500] (476 bytes)
2017-09-19T13:05:40.308370+02:00 superserver charon: 13[IKE] received retransmit of request with ID 2412179458, but no response to retransmit
2017-09-19T13:05:43.430946+02:00 superserver charon: 03[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500]
2017-09-19T13:05:43.430963+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T13:05:43.430981+02:00 superserver charon: 13[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500] (476 bytes)
2017-09-19T13:05:43.430993+02:00 superserver charon: 13[IKE] received retransmit of request with ID 2412179458, but no response to retransmit
2017-09-19T13:05:46.430323+02:00 superserver charon: 03[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500]
2017-09-19T13:05:46.430342+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T13:05:46.430359+02:00 superserver charon: 13[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500] (476 bytes)
2017-09-19T13:05:46.430367+02:00 superserver charon: 13[IKE] received retransmit of request with ID 2412179458, but no response to retransmit
2017-09-19T13:05:49.329797+02:00 superserver charon: 03[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500]
2017-09-19T13:05:49.329820+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T13:05:49.329836+02:00 superserver charon: 13[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500] (476 bytes)
2017-09-19T13:05:49.329845+02:00 superserver charon: 13[IKE] received retransmit of request with ID 2412179458, but no response to retransmit
2017-09-19T13:05:52.320424+02:00 superserver charon: 03[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500]
2017-09-19T13:05:52.320440+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T13:05:52.320497+02:00 superserver charon: 13[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500] (476 bytes)
2017-09-19T13:05:52.320504+02:00 superserver charon: 13[IKE] received retransmit of request with ID 2412179458, but no response to retransmit
2017-09-19T13:05:55.350682+02:00 superserver charon: 03[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500]
2017-09-19T13:05:55.350686+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T13:05:55.350722+02:00 superserver charon: 13[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500] (476 bytes)
2017-09-19T13:05:55.350732+02:00 superserver charon: 13[IKE] received retransmit of request with ID 2412179458, but no response to retransmit
2017-09-19T13:05:56.330041+02:00 superserver charon: 03[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500]
2017-09-19T13:05:56.330043+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T13:05:58.400495+02:00 superserver charon: 03[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500]
2017-09-19T13:05:58.400514+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T13:05:58.400526+02:00 superserver charon: 14[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500] (476 bytes)
2017-09-19T13:05:58.400534+02:00 superserver charon: 14[IKE] received retransmit of request with ID 2412179458, but no response to retransmit
2017-09-19T13:06:01.340837+02:00 superserver charon: 03[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500]
2017-09-19T13:06:01.340857+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T13:06:01.340962+02:00 superserver charon: 14[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500] (476 bytes)
2017-09-19T13:06:01.340975+02:00 superserver charon: 14[IKE] received retransmit of request with ID 2412179458, but no response to retransmit
2017-09-19T13:06:04.360587+02:00 superserver charon: 03[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500]
2017-09-19T13:06:04.360589+02:00 superserver charon: 03[NET] waiting for data on sockets
2017-09-19T13:06:04.360786+02:00 superserver charon: 14[NET] received packet: from 80.187.119.162[30544] to 79.232.162.196[4500] (476 bytes)
2017-09-19T13:06:04.360791+02:00 superserver charon: 14[IKE] received retransmit of request with ID 2412179458, but no response to retransmit

Code:

root@superserver:/var/log # cat /etc/ipf.conf
#####   block alles     #########
#block out log  on tun0 all
#block in log  on tun0 all

#####  locale Netze sind kein ziel im Internet  #######
block out  quick  on tun0 from any to { 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12 }


#####  ipsec service    #########
pass in  log on tun0 proto esp all
pass in  log on tun0 proto ah all
pass in  log on tun0 proto udp from any to any port = { 500, 4500 }





#####   SSH             #########
pass in log first quick on tun0 proto tcp from any to 172.17.20.1 port = 22 keep state


#####   Entertain       #########
#       Mutlicast erlauben
pass in  quick on { tun0, vlan6 } proto udp  from any to 224.0.0.0/4
pass out quick on { tun0, vlan6 } proto udp  from any to 224.0.0.0/4
#       igmp erlauben
pass in  quick on { tun0, vlan6 } proto igmp  from any to any
pass out quick on { tun0, vlan6 } proto igmp  from any to any


#####   Ping            #########
pass in  quick on tun0 proto icmp  from any to any
pass out quick on tun0 proto icmp  from any to any


#####   DNS Service     #########
pass out quick on tun0 proto udp from any to any port = 53    # Anfrage
pass in  quick on tun0 proto udp from any port = 53  to any   # Antwort!


#####   sendmail        ########
pass out quick on tun0 proto tcp/udp from any to any  port = 25  keep state
pass in  quick on tun0 proto tcp/udp from any port = 993 to any  keep state


#####   Http Service    ########
pass in  quick on tun0 proto tcp from any to any port = { 80, 443 } keep state
pass out quick on tun0 proto tcp from any to any port = { 80, 443 } keep state

#####   traceroute      ########
pass out quick on tun0 proto udp from any to any  port 33434:33464
pass in  quick on tun0 proto udp from any to any  port 33434:33464

#####   xchat           ########
pass out quick on tun0 proto tcp from any to any  port = 6667 keep state
pass in  quick on tun0 proto tcp from any  port = 6667 to any

#####   portsnap        ########
pass out quick on tun0 proto tcp/udp from any to any  port = {20,21} keep state

#####   whois           ########
pass out quick on tun0 proto tcp/udp from any to any  port = {43} keep state

#####   VoIP,SIP        ########
pass in   quick on tun0 proto udp from 217.0.0.0/16 to 192.168.8.0/24
pass out  quick on tun0 proto udp from any to 217.0.0.0/16 port = 5060


#####   vlan 4          ########
pass out quick on tun0 proto tcp/udp from 192.168.4.0/24  to any keep state
pass in  quick on tun0 proto tcp/udp from 192.168.4.0/24  to any keep state

#####   vlan 6          ########
pass out quick on tun0 proto tcp/udp from 192.168.6.0/24  to any keep state
pass in  quick on tun0 proto tcp/udp from 192.168.6.0/24  to any keep state

#####   vlan 8          ########
pass out quick on tun0 proto tcp/udp from 192.168.8.0/24  to any keep state
pass in  quick on tun0 proto tcp/udp from 192.168.8.0/24  to any keep state

Illuminatus · 19 September 2017

Ich möchte empfehlen dass du die Beispiele von der StrongSwan Projektseite selbst auf dein Setup anpasst:
https://wiki.strongswan.org/projects/strongswan/wiki/ConfigurationExamples
https://www.strongswan.org/testing/testresults4/ikev1/nat-two-rw/

Wenn ich es richtig sehe ist dein Beispiel von heise aus dem Jahr 2003 AD (Bewusstes Trolling deinerseits?). Screenshots oder Textauszüge deiner Client-IPSec Konfiguration sind auch hilfreich bei der Fehlersuche. Wie kommst du darauf dass es ein Firewall-Problem sein könnte? Es gibt doch ein- und ausgehende Kommunikation über Port 500 und 4500. Bei Zweifel und und zum groben Ausschließen: FW temporär deaktivieren im kontrollierten Setup.

Xartax · 19 September 2017

Illuminatus schrieb:
Ich möchte empfehlen dass du die Beispiele von der StrongSwan Projektseite selbst auf dein Setup anpasst:
https://wiki.strongswan.org/projects/strongswan/wiki/ConfigurationExamples
https://www.strongswan.org/testing/testresults4/ikev1/nat-two-rw/

Die Links kenne ich bereits, wenn ich damit klär käme hätte ich hier kein Thema aufgemacht.

Illuminatus schrieb:
Wenn ich es richtig sehe ist dein Beispiel von heise aus dem Jahr 2003 AD (Bewusstes Trolling deinerseits?).

Ich habe verschiedene ipsec.conf Beispiele, die ich im Internet gefunden habe ausprobiert. Die oben veröffentlichte ipsec.conf hab im Internet gefunden und steht so in meiner ipsec.conf.
Dass diese "meine" ipsec.conf nicht optimal ist, davon geh ich aus. Mich aber "Bewusstes Trolling" zu unterstellen hat mich schwer gekränkt.
Mann sollte sehr vorsichtig sein Jemanden als TROLL zu bezeichnen. Denn man könnte dieser Person bitter unrecht tun.

Illuminatus schrieb:
Screenshots oder Textauszüge deiner Client-IPSec Konfiguration sind auch hilfreich bei der Fehlersuche.

Das ist nicht möglich, weil ich keine "Client-IPSec Konfiguration" habe. Denn der "Client" ist ein Smartphone mit Android drauf.

Illuminatus schrieb:
Wie kommst du darauf dass es ein Firewall-Problem sein könnte? Es gibt doch ein- und ausgehende Kommunikation über Port 500 und 4500.

Es ist nicht diese Kommunikation gemeint, sondern die des Tunnels. Ich weiß bis heute nicht und hab auch nichts im Internet gefunden, das mir sagt ob ein neues Interface erzeugt wird oder ob die locale Tunnel IP, in meinem Fall 10.0.0.0/8 als Alias im tun0 Interface erzeugt wird. Generell ist die Firewall ziemlich scharf eingestellt, da wäre es schon möglich dass die Erzeugung des Tunnels an dieser firewall configuration scheitern könnte. Darum meine Frage.

Illuminatus schrieb:
Bei Zweifel und und zum groben Ausschließen: FW temporär deaktivieren im kontrollierten Setup.

Genau das habe ich bei anderen Problemen Bereits ausprobiert, mit dem Nachteil, dass mein Netzwerk dann nicht mehr richtig funktioniert. warum das so ist weis ich nicht. Behoben kann das nur mit einem Neustart des System werden. (FrreBSD 11.0, bug?)

Ich möchte allen die mir bis jetzt geholfen haben von ganzem Herzen Danken.

Illuminatus · 20 September 2017

Xartax schrieb:
Das ist nicht möglich, weil ich keine "Client-IPSec Konfiguration" habe. Denn der "Client" ist ein Smartphone mit Android drauf.

Hm, das macht es natürlich ein wenig kompliziert, da gebe ich dir selbstverständlich Recht. Und wie sieht es aus wenn du per Hand ein paar Begriffe und Zeilen abtippst - und zwar von den Feldern in deinem Android OS, wo du grundlegende Angaben deiner IPSec Verbindung eingetragen hast? Denkst du das lässt sich zumuten bzw. bewerkstelligen?

https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection

Code:

left|rightsubnet =

Instead of specifying a subnet, %dynamic can be used to replace it with the IKE address, having the same effect
as omitting left|rightsubnet completely. Using %dynamic can be used to define multiple dynamic selectors,
each having a potentially different protocol/port definition.

Ich fand es für die Pflege der Firewall jedoch immer einfacher, wenn jeder Client ein spezifisches rightsubnet /32 erhalten hat und auf explizite leftsubents zugreifen durfte.

leftsourceip möchtest du in der manpage ggf. auch nachschlagen.

Xartax · 20 September 2017

@Illuminatus:

ich was das: "IKE_SA p2p[3] state change: CONNECTING => ESTABLISHED" bedeutet.
Es bedeutet, dass die Verbinung steht.

Das hier: "found matching child config "p2p" with prio 2"
Das bedeutet, dass meine con p2p als zutreffend erkannt wurde.

dann kommt das: "no matching CHILD_SA config found"
Da fehlt also eine Konfiguration, hab schon das Internet durchsucht aber nicht wirklich was gefunden.

Ich hab zwar was gefunden, dass das mit einen 2. Aushandeln des Schlüssels in Phase 2 sein soll, aber nichts was da auf eine Konfiguration hinweisen könnte, Außer bei der strongswan.conf.

Bei racoon.conf gibt es doch das sainfo{.....} solche ähnliche angaben habe ich bei strongswan noch nicht gefunden. Außer, bei einem recht komplexen beispiel.

irgend wo fehlt noch eine konfiguration, aber wo?

Was mein Smartphone betrifft, da kann man nicht viel eingeben:
Benutzername, Passwort, Client-Certifikat
Das war es dann schon. Ich hab auch schon das Internet durchstöbert um herauszufinden wie das Android tickt, vielleicht braucht man da noch extras im Zertifikat.
Einmal hab ich was gefunden aber dann nicht wieder, leider, kann dir also nicht mehr sagen was ich da gefunden habe, irgendwas mit ID:...

Nachdem er für die CLIENT_CA keine passende (no matching) Konfiguration gefunden hat wird die Verbindung abgebrochen.

Ja, da fehlt also noch eine Konfiguration, aber welche und wo?

hier meine Strongswan.conf ist nur in der IP angepasst

Code:

# strongswan.conf - strongSwan configuration file
#
# Refer to the strongswan.conf(5) manpage for details
#
# Configuration changes should be made in the included files

charon {
        load_modular = yes
        dns1 = 172.17.20.1
        plugins {
                include strongswan.d/charon/*.conf
        }
}

include strongswan.d/*.conf

freebsd, ipsec, racoon

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

das.chaos

Guest

Well-Known Member

in geheimer Mission

das.chaos

Guest

Possessed With Psi Powers

Well-Known Member

Systemheld

Well-Known Member

used register

Well-Known Member

Possessed With Psi Powers

Possessed With Psi Powers

Well-Known Member

Well-Known Member

Well-Known Member

Well-Known Member

in geheimer Mission

Well-Known Member

in geheimer Mission

Well-Known Member

Wir schützen deine Privatsphäre