Von Router/Firewall via IPSec: Konfiguration?

freitag

Member
OK, nach mehreren Stunden trial-and-error möchte ich demütig um Hilfe bitten...

PP bietet ja vorkonfigurierte Router an, aber wenn ich nun selber einen konfigurieren möchte? Ich habe mir eine ZyXEL ZyWALL USG-20 Firewall gekauft und versuche gerade hinzubekommen dass das Ding sich mit einem PP server verbindet, damit alle Geräte in meinem LAN anonym surfen.

Diese IKE Phase1/2 Einstellungen gibt es dafür: http://i.imgur.com/0iqLi04.png

Welche Parameter muss ich angeben für einen "normalen" Cisco Ipsec IKE? Ich werde zwischendurch mal schauen ob die ZyWALL nicht mehr logs herausrücken kann.

Danke für deine Zeit.

UPDATE: Die Logs sagen, dass ich ein "Recv:[NOTIFY:NO_PROPOSAL_CHOSEN]" bekomme. Nicht verwunderlich bei den Standardeinstellungen. Die Werte müssen ja alle auf der anderen Seite genau gleich sein..
 
Ohne dass du irgendwo User/Passwort eingeben kannst wird das sowieso nix. Du musst deinen Account ja bei PP verifizieren, wofür natürlich user/pass nötig ist.

Edit:
Das No Proposal kommt wahrscheinlich daher, dass du auch keine Auth Methode angegeben hast. Du hast zwar PSK gewählt aber kein Key eingetragen.
 
Ja, richtig. Der Screenshot hat nur den wizard für VPNs gezeigt. Unter den erweiterten Einstellungen konnte ich Benutzername und Passwort eingeben. Ich meine aber, dass der Handshake schon früher missglückt.

Mal ein Beispiel: DH1, 2 oder 5? Wie kann ich die Werte in Erfahrung bringen? Soll ich einfach alle möglichen Proposals hinzufügen und dann hoffen, dass PP einen akzeptiert? :)

Edit 1:
Den PSK habe ich nur hier nicht eingegeben damit er nicht auf dem Screenshot erscheint.

PS: Ich sollte noch erwähnen, dass die Firewall noch hinter einem NAT liegt. Ich bin mir bewusst, dass dies zu Problemen führen kann, wollte es aber doch mal probieren. Momentan haperts ja noch am Grundlegenden und nicht am NAT. Eine Standleitung ohne NAT ist schon bestellt... Meine Frage lautet ja zur Zeit, welche Parameter hier *generell* anzuwenden sind.

Edit 2:
Durch rumprobieren bin ich einen Schritt weiter gekommen. Bekomme jetzt einen "Phase 1 Remote ID mismatch". /me googlet...
 
Für das NAT hast du ja NAT Traversal geschalten, das ist genau dafür.

Ich würde als Encryption Alg AES statt DES nehmen, falls das wählbar ist und bei Authentication Alg eher SHA(1/2). Key Group lass mal DH1.

Bei Phase 2 auch Enc Alg AES, was gibt's da für Protokolle zur Auswahl?
PFS mal einschalten, das sollte PP schon nutzen, da echter Gewinn bei der Privacy.

Edit:
Ipsec ist echt n Mist zu konfigurieren, vor allem stell ich mir das auf nem Router als noch übler vor als auf nem OS wie Linux/Win/OSX.
Da hast dir echt was vorgenommen ;-)
 
Haha, ja, danke :) Aber ich bin mir sicher, die Client-Seite ist dennoch einfacher zu konfigurieren als die PP Server :)

Also, ich habe einfach immer den stärksten Algorithmus gewählt (AES256, SHA512 usw.) und DH5, dann kam ich einen Schritt weiter. DH1 kam immer zurück mit NO_PROPOSAL_CHOSEN.

Jetzt hänge ich noch in Phase 1 an "Remote ID mismatch". Also der PP Server sagt, dass die IP mit der ich mich dorthin verbinde nicht übereinstimmt mit dem was ich hier http://i.imgur.com/c1ZCskl.png angegeben habe.

Wenn ich das richtig verstanden habe (siehe http://www.dslreports.com/forum/r11094500- ), kann man dort einfach 0.0.0.0 eintragen dann müsste es klappen (das war auch der Defaultwert). Aber der PP Server will wohl mehr wissen...

Ich habe versucht dort alle möglichen IP Adressen einzutragen (also meine ausgehende IP, die lokale vom router...) Noch nicht geglückt. Es gibt auch noch DNS und EMAIL als Auswahl unter Local ID Type. Falls ich nicht PSK nehmen will sondern CERT versuchen möchte (dann stellt der automatisch auf Email um) - liegt das Client-Zertifikat in der OpenVPN konfigurationsdateien-zip rum? Oder liegen da nur die Serverzertifikate drin? Bin mir da grad nicht ganz sicher. Ich google mal weiter...

Edit:
Mein verkorkstes Netzwerksetup sieht momentan übrigens so aus:
4G Stick -> MacBook -> Internet Sharing via Ethernet -> Firewall WAN
Mit einem anderen Macbook bin ich dann in einem Firewall LAN Port zum konfigurieren...
Kein Wunder dass da irgendwie eine falsche IP auf den Weg geschickt wird, haha. Aber Standleitung wie gesagt schon bestellt...

Edit 2:
Aha, http://www.nwlab.net/tutorials/VPN-pfSense-ZyWALL sagt dass Type ID identisch sein muss auf beiden Seiten. Ich muss also vielleicht Local ID Type "DNS" ausprobieren.
 
Dein Problem ist, dass du da echt für alles irgendwas setzen musst und es nicht die Möglichkeit von auto oder so gibt. Bei mir unter OSX muss ich lediglich User/Pass und dann unter Auth Einstellungen den PSK angeben und alles läuft. Der setzt den Rest also passend automatisch.

Probier es in jedem Fall zuerst per PSK, per Zertifikat kann unter IPsec noch sperriger sein...Ich hab da echt schon Std geflucht mit dem Mist...

Du trägst dort die IP Adresse ein, die dein Rechner, in dem Fall also die FW hat. Das ist auch deine lokale Adresse. Da sich die allerdings per DHCP jedesmal ändern kann gibts die 0.0.0.0 Option. Die sollte der PP Server eigentlich akzeptieren.

Ich guck nachher mal unter Linux, was ich da mal hatte als Optionen für PP IPsec, dann kann ich mal paar durchprobieren und dir Feedback geben.

Aha, http://www.nwlab.net/tutorials/VPN-pfSense-ZyWALL sagt dass Type ID identisch sein muss auf beiden Seiten. Ich muss also vielleicht Local ID Type "DNS" ausprobieren.

Was willst n da setzen für DNS? IdR hat n Client hinter nem NAT kein DNS Namen, sondern nur seine IP.
 
Bei mir unter OSX muss ich lediglich User/Pass und dann unter Auth Einstellungen den PSK angeben und alles läuft. Der setzt den Rest also passend automatisch.

Ja, das wäre leichter. Ich will aber auch wenn jemand zu Gast ist und mal schnell ins Internet möchte nicht über meine IP raus geht. Du hast mir ja schon mal geholfen mit pf unter OSX das funktioniert auch super. Aber mittlerweile habe ich keinen Überblick mehr welches Macbook wo was in seiner launchd hat und möchte einfach dass das gesamte Netzwerk anonym ist :)

Ich hab da echt schon Std geflucht mit dem Mist...

Heißt das ich bin jetzt im Club? :)

Du trägst dort die IP Adresse ein, die dein Rechner, in dem Fall also die FW hat. Das ist auch deine lokale Adresse. Da sich die allerdings per DHCP jedesmal ändern kann gibts die 0.0.0.0 Option. Die sollte der PP Server eigentlich akzeptieren.

Unglaublich. Ich habe als Local ID Type IP wieder 0.0.0.0 eingetragen und als Remote ID Type nicht DNS sondern eine IP vom PP Server hardgecodet. Und siehe da, Phase 1 abgeschlossen! Logs: http://i.imgur.com/EbVxEM8.png Remote hier ist eben nicht remote dort oder was weiß ich...

Ok, auf zu Phase 2.... Hängt bei INVALID_ID_INFORMATION Sieht momentan so aus: http://i.imgur.com/hcmVypQ.png
 
Protokolle: ESP und AH
Encapsulation: Tunnel und Transport
Dann kann ich auch noch zwischen den hier wählen: http://i.imgur.com/5JzrDbx.png Aus den Logs ergibt sich soweit ich sehen kann bisher kein Unterschied zwischen den beiden.

Hm, ich fühle mich wie auf einem Fehlerkarusell. Habe einfach immer weiter rum probiert.

ESP+Tunnel sowohl als auch ESP+Transport -> INVALID_ID_INFORMATION
AH+Tunnel -> No rule found, Dropping ESP/NAT-T packet
AH+Transport -> Dial an incomplete tunnel has failed for Crypto map.

Auf der Seite die du gepostet hast steht auch folgendes:

Check also the ID type defined in "Phase 1 advanced" is consistent with the type defined in the router.

Ich kann mir also gut vorstellen, dass die Type ID aus dem vorigen Schritt jetzt Probleme bereitet.

Darüber hinaus kann ich noch policies einstellen http://i.imgur.com/KZBpyYg.png Bei Tunnel muss das ein Subnet sein und bei Transport ein Host oder ein Interface (sagt die FW beim eingeben). Ich habe aber "Use Policy Route to control dynamic IPSec rules" und "Enforce Policy" ausgeschaltet in der Hoffnung das es hiermit nichts zu tun haben kann. Bei PP bekommt man ja immer eine 10.* Adresse zugewiesen, das sollte aber nichts mit meiner LAN-Konfiguration zu tun haben.

An meinen eigenen Kommentaren sehe ich wie müde ich eigentlich gerade bin. Ich glaube ich kaufe mir so einen Router den PP verkauft und schaue mir die Konfiguration da drauf an :D
 
Nicht verzagen ;-)
IPsec ist Dreck was die Konfiguration anbelangt, an sich wenn's mal läuft ist es auch ok. Wie gesagt ich guck mir das nachher mal unter meinem Linux an. Da sollten sich paar Szenarios durchspielen lassen, dann kann ich hier mal posten mit welchen Konfigs ne Verbindung klappte.
 
Hab nun gefühlte 2 Std an meiner alten Linux IPsec Config rumprobiert um da mal paar Sachen durchzuspielen. Jetzt hab ich selbst erstmal gefrustet aufgegeben...Das ist echt ne fiese Sache anders kann man's nicht ausdrücken. Man stellt am Client was um, dieser quittiert es mit ner Verbindungsverweigerung. Dann denkt man sich stellt man halt nen anderen Wert ein, plötzlich kennt er die Config nicht mehr...obwohl sie vorhanden ist. Teilweise half nur n Reboot der ganzen Kiste, dass er überhaupt wieder was gemacht hat...
Mal einfach paar Sachen durchspielen wie unter OpenVPN wird da echt zum Geduldsspiel.
 
Ich hab mir jetzt mal das komplette Log des OSX IPsec Clients Racoon angesehen. Dabei kann ich dir zumindest einige Sachen nennen, mit der mein Rechner sich verbinden konnte:

Phase 1:
Encryption Algo : AES256
Authentication Algo: SHA oder SHA1
Key Group: Bei mir dh_group = 1024 Bit (nach der Strongswan Referenz ist das DH2)


Phase 2:
Active Protocol: ESP
Encapsulation: Transport
Encryption Algo: AES256
Authentication Algo: SHA oder SHA1
Perfect Forward Secrecy: Nix gefunden (Kannst ja beides testen)

Ich speicher mir das Log mal ab.

Also das sind die Settings mit denen sich OSX mit PSK erfolgreich verbinden konnte, heißt jetzt nicht automatisch, dass das deine Firewall auch kann, zu unterschiedlich sind da einfach die implementierten IPsec Lösungen der verschiedenen Betriebssysteme oder ner Hardware Lösung wie deiner FW. Aber es bedeutet zumindest, dass die PP Server was damit anfangen können.
Server war übrigens rotterdam.perfect-privacy.com

Viel Erfolg
 
Erst einmal nochmal danke. Das hilft in jedem Fall schonmal weiter.

Ich habe noch einmal von Vorne begonnen, diesmal mit deinen Werten und Rotterdam, und dabei aus Versehen vergessen XAUTH zu benutzen. Plötzlich bekam ich diese logs zu sehen und ein "Tunnel Established": http://i.imgur.com/bawrzzM.png

Aber auch nur wenn ich PFS in Phase 2 deaktiviere (Phase 1 funktioniert mit DH2). Mit PFS bekomme ich ein NO_PROPOSAL_CHOSEN.

Wie ist die Verbindung möglich ohne Username und Passwort? Wird auf dem Transportlayer erst einmal keine Authentication benötigt?

Sobald ich XAUTH mit Username und Passwort aktiviere, bekomme ich wieder mein INVALID_ID_INFORMATION. Username und Passwort sind übrigens korrekt, weil ich ein "XAUTH failed" erhalte wenn ich z. B. den Benutzernamen absichtlich falsch eingebe.

Auf dieser Seite http://www.manualslib.com/manual/363426/Thegreenbow-Zywall-10-Greenbow-Vpn-Client.html?page=10 steht zu INVALID_ID_INFORMATION folgendes:

check if « Phase 2 " ID (local address and network address) is correct and match what is expected by the remote endpoint

Ich frage mich was der PP Server hier erwartet. Meine Auswahlmöglichkeiten sind bei encapsulation "Transport" begrenzt auf "Interface IP" oder "Host". Ich probiere immer rum hier alle möglichen Sachen auszuprobieren. Zuletzt HOST 0.0.0.0 als lokale Policy und Interface IP vom WAN als remote policy. Habe auch mal HOST und dann die direkte IP vom rotterdam1 server ausprobiert. Aber alle Kombinationen führen bisher zu exakt dem gleichen Invalid ID Fehler.

Mein racoon (L2TP/IPSec) zeigt mir an genau der gleichen Stelle übrigens die gleiche Fehlermeldung, macht aber trotzdem weiter: http://i.imgur.com/7koOl2J.png Ich glaube aber das ist was anderes, weil die Fehlermeldung in der FW log vom PP Server ausgeht (ich bin dann der Remote) und in meiner Console app womöglich von racoon selbst (PP ist dann der Remote).

Ok, noch eine Nacht drüber schlafen ;) Danke für dein Mutmachen.
 
Es wird zunächst mal deine Maschine autorisiert, das erfolgt wahlweise mit PSK oder Zertifikat. Hier jetzt erstmal mit PSK. Danach kommt es erst zur User Autorisierung.

NAT Traversal hast du weiterhin geschalten oder?

Der PP Server erwartet eigentlich von den Clients nix besonderes. Er muss ja auf Zugriff durch Roadwarrior (also clients mit wechselnder IP) eingestellt sein und akzeptiert von der Seite eigentlich jegliche IP.
Ich vermute fast, dass die Probs eher von deiner FW kommen als vom PP Server.

Evtl funktioniert das mit der FW nicht hinter nem NAT so wirklich.

Edit:
Ich werd mir auch nochmal mein Log durchsehen ob da was mit der ID Mismatch zu finden ist.
Da du in deinem Log diese Meldung von Racoon bekommst scheint das Prob aber schon lokal zu sein.
 
Danke für deinen Input. Mit jedem Kommentar fallen wieder neue Puzzelstücke auf ihren Platz finde ich.

Genau. Ich werde das Ding mal auf die Arbeit mitnehmen und mit meinem IT-Kollegen versuchen mich ohne NAT zu verbinden. Ich habe auch noch Zugang zu einem anderen IPSec VPN, werde es auch mal damit versuchen. Und dann bald mit meiner eigenen Standleitung, habe schon die Bestellbestätigung erhalten.

Time will tell :)
 
Ach ja:
Diese mismatched ID Meldung hab ich auch:

15.02.15 17:16:26,359 racoon[515]: mismatched ID was returned - ignored because nat traversal is being used.

Ich kann's mir nur so vorstellen, dass racoon als ID nicht die IP von dem Rechner bekommt, von dem aus die IPsec Verbindung gestartet wurde (das war in dem Fall ja einer mit lokaler IP), sondern die IP meines DSL Routers, was auch Sinn macht, denn aufgrund des NAT kommuniziert der PP Server ja mit der IP meines Routers, der diese wieder auf die lokale umsetzt. Genau diesen mismatch ignoriert racoon, weil nat traversal gesetzt ist. Wenn nun deine FW das nicht macht, sondern darauf besteht, dass ihre IP im Paket enthalten ist, klappt das nicht, denn im Paket ist natürlich die öffentliche IP des DSL Routers enthalten.

Ein Test direkt mit einer im Internet gültigen öffentlichen IP könnte diese Theorie entweder untermauern oder widerlegen :)
 
Habe jetzt die Standleitung, bekomme aber den gleichen Fehler. NAT-Probleme können wir also schonmal ausschließen. Ich glaube das Problem liegt einfach daran, dass ich keine Ahnung davon habe wie genau die IPs/Subnetze konfiguriert werden müssen. Darüber hinaus verstehe ich viele Begriffe im Einzelnen (Bridge, PPP, L2TP, Tunnel,...), aber nicht wie die richtig zusammen arbeiten müssen für genau meinen Usecase.

Ich versuche es jetzt mal wirklich Schritt für Schritt. Sorry im Voraus falls ich Dinge durcheinander werfe.

Ich muss zunächst einmal wählen ob ich in IPSec den Tunnel- oder Transport-Modus benutzen möchte [1]. Ich gehe mal davon aus, dass der PP Server beides unterstützt. Tunnel muss funktionieren, weil racoon das ja wohl bei L2TP über Ipsec benutzt. Transport muss funktionieren, weil es für dich klappt; und ohne XAUTH kann ich mich im Transport-Modus ja auch verbinden.

Die Fehlermeldung INVALID_ID_INFORMATION fand ich hier [2] noch mal gut erklärt:

Both sides of the tunnel must have the correct endpoint IP and remote subnet information entered as advertised by the other end of the tunnel. If there is a mismatch between what one side is advertising as the accessible remote subnet behind itself and what is configured on the other end of the tunnel the tunnel will show as not connected and the log will display the INVALID_ID_INFORMATION message. Double check that both sides are using the appropriate Remote Subnet.

Was mich genau wieder zu Schritt eins zurückführt:

Auf [3] steht so schön mit einem Bild [4] beschrieben, dass man sich zuerst klar machen soll welche Subnetze auf welcher Seite liegen.

Jedoch gilt die ganze Subnetz-Geschichte nur im Tunnel-Modus. Denn wenn ich Transport-Modus als Encapsulation wähle, kann ich als "Local ID" und "Remote ID" nicht den Typ "Subnetz" wählen, sondern nur ein Interface oder eine IP direkt. Hier [5] hat jemand z. B. als Encapsulation "Tunnel" gewählt und konnte so als "Local Addr Type" SUBNET (192.168.0.0/24) wählen. Das kann ich nicht, wenn ich Transport wähle.

Nun bin ich etwas verwirrt darüber, dass auf meinem MacBook in meiner ifconfig ein ppp0 durch IPSec/L2TP angelegt wird mit "inet 10.11.15.131 --> 10.11.15.129 netmask 0xff000000". Ich dachte, dass LinkLayer-Protokol wäre L2TP, ist PPP nicht eine Alternative zu L2TP in dem Fall? Auf der linken Seite des PPP liegt meine interne VPN IP (10.11.15.131) aber was ist 10.11.15.129? Meine interne IP im Netz auf der anderen Seite des Tunnels? Jedenfalls dachte ich mir hier, dass das Remote-Subnetz wohl 10.0.0.0/8 sein muss wegen der netmask in der ifconfig.

Also habe ich versucht mich im Tunnel-Modus mit der "Remote ID" 10.0.0.0/8 und der "Local ID" 192.168.7.0/24 zu verbinden. Dachte also, dass die Remote ID nun stimmen müsste. Habe aber wieder nur ein INVALID_ID_INFORMATION bekommen. Auch mit "0.0.0.0". Muss ich vielleicht auf meiner FW auch ein PPP zum Benutzen in dem Tunnel einrichten? Oder vielleicht irgendeine Bridge? Vielleicht ein virtuelles Interface? Ich habe ja 192.* und nicht 10.* wie der PP Server mir auf meinem Macbook zuordnet. Also brauche ich wohl irgendeinen Tunnel... Die GUI auf [6] ist meiner GUI eigentlich recht ähnlich. Dort wird erst ein Tunnel aufgesetzt mit den richtigen Subnetzen.

Wie dem auch sei, versuche ich den Transport-Modus zu benutzen, muss ich als Local ID und Remote ID jeweils den Typ "Host" oder "Interface IP" angeben. Nun müssen diese Dinge ja die Spezifikation auf dem PP Server matchen, sonst bekomme ich den INVALID_ID_INFORMATION. Das verstehe ich aber jetzt nicht - soll ich hier die Interne IP angeben? Die ist ja 192.*

Du siehst, ich habe so ein Bild [4] nie aufgezeichnet. Da ich aber hier kein bereits fest bestehendes Netz sondern Greenfield habe, kann ich mir ja frei aussuchen was ich haben will. Aber selbt wenn ich die Kette auf Papier hätte, wüsste ich imemr noch nicht worauf genau sich Local ID und Remote ID bezieht. Meine Local ID muss das matchen was als Remote ID im PP Server angeben ist? Auf [7] steht wieder was ganz anderes zu INVALID_ID_INFORMATION:

Aggressive Mode request error. Check the following: SA name in remote peer must be the same as the local unit’s unique firewall identifier in
the VPN settings (and vice-versa).

SA name und firewall identifier? Ich dachte wir reden hier über Subnetze? Ich bin gerade etwas verwirrt.

Du hast geschrieben:

... Wenn nun deine FW das nicht macht, sondern darauf besteht, dass ihre IP im Paket enthalten ist, klappt das nicht, denn im Paket ist natürlich die öffentliche IP des DSL Routers enthalten. ...

Nun, in meiner FW Log steht, dass die Message INVALID_ID_INFORMATION von [IP eines PP Servers port 500] an [meine WAN IP port 500] geschickt wird. Also klagt nicht die FW sondern der Server wenn ich das richtig verstehe.

Ok, vielleicht muss ich komplett auf DNS verzichten und nur über eine hardgekodete öffentliche IP des PP Servers gehen und die als "Remote ID" eintragen. Gerade probiert, gleiche Fehlermeldung wie immer.

:(


[1] https://en.wikipedia.org/wiki/IPsec#Modes_of_operation
[2] http://www.cohesiveft.com/dnld/CohesiveFT-VNS3-3.x_IPsec-Troubleshooting.pdf Seite 9
[3] http://www.enterprisenetworkingplan...ild-an-IPSEC-VPN-Without-Losing-Your-Mind.htm
[4] http://www.enterprisenetworkingplanet.com/img/2009/10/ipsec_diagram.jpeg
[5] http://www.dslreports.com/faq/8377
[6] https://live.paloaltonetworks.com/docs/DOC-6791
[7] http://www.vpncasestudy.com/download/troubleshoot/Troubleshooting_IKE_VPN.pdf Seite 6
 
Ich muss zunächst einmal wählen ob ich in IPSec den Tunnel- oder Transport-Modus benutzen möchte [1]. Ich gehe mal davon aus, dass der PP Server beides unterstützt. Tunnel muss funktionieren, weil racoon das ja wohl bei L2TP über Ipsec benutzt. Transport muss funktionieren, weil es für dich klappt; und ohne XAUTH kann ich mich im Transport-Modus ja auch verbinden.

Die Fehlermeldung INVALID_ID_INFORMATION fand ich hier [2] noch mal gut erklärt:


Also die INVALID_ID Sache hat mE nichts mit den Subnetzen zu tun. Zuerst muss mal die Verbindung FW PP Server stehen.

Racoon verwendet bei L2TP/IPsec nicht den Tunnel, sondern den Transport Modus. Zumindest finde ich in meinem Log nur Transport Mode. Der PP Server sollte beides können, L2TP muss aber über'n Transport Modus, soweit ich das in Erinnerung hab, Tunnel geht da nicht.


Jedoch gilt die ganze Subnetz-Geschichte nur im Tunnel-Modus. Denn wenn ich Transport-Modus als Encapsulation wähle, kann ich als "Local ID" und "Remote ID" nicht den Typ "Subnetz" wählen, sondern nur ein Interface oder eine IP direkt. Hier [5] hat jemand z. B. als Encapsulation "Tunnel" gewählt und konnte so als "Local Addr Type" SUBNET (192.168.0.0/24) wählen. Das kann ich nicht, wenn ich Transport wähle.


Das mit den Subnetzen ist halt bei dir auch sehr starr, das Subnetz hinter dem PP Server ist einfach das komplette Internet also 0.0.0.0/0, denn du willst ja über diesen surfen und nicht in ein spezielles LAN-Subnetz kommen. Desweiteren sollte dir der PP Server ein Subnetz zuweisen in dem du mit ihm kommunizierst, das ist einfach wie bei openvpn irgendein lokales Netz mit ner 10er IP. Probier das mal unter deinem MacBook aus, verbinde dich zu PP, gib auf dem Terminal ifconfig ein und dann siehst du ein Interface ppp0, dem ne 10er IP zugewiesen wurde, dazu musst du gar nix machen, das macht der PP Server.
Ich würde also eher den Transport Modus wählen und die Subnetze dem PP Server machen lassen.

Nun bin ich etwas verwirrt darüber, dass auf meinem MacBook in meiner ifconfig ein ppp0 durch IPSec/L2TP angelegt wird mit "inet 10.11.15.131 --> 10.11.15.129 netmask 0xff000000". Ich dachte, dass LinkLayer-Protokol wäre L2TP, ist PPP nicht eine Alternative zu L2TP in dem Fall? Auf der linken Seite des PPP liegt meine interne VPN IP (10.11.15.131) aber was ist 10.11.15.129? Meine interne IP im Netz auf der anderen Seite des Tunnels? Jedenfalls dachte ich mir hier, dass das Remote-Subnetz wohl 10.0.0.0/8 sein muss wegen der netmask in der ifconfig.


Die 10.11.15.129 ist die interne IP des PP Servers mit der du durch den Tunnel kommunizierst. Wie gesagt, das macht der Server alles von selbst da musst du nix zutun.


Also habe ich versucht mich im Tunnel-Modus mit der "Remote ID" 10.0.0.0/8 und der "Local ID" 192.168.7.0/24 zu verbinden. Dachte also, dass die Remote ID nun stimmen müsste. Habe aber wieder nur ein INVALID_ID_INFORMATION bekommen. Auch mit "0.0.0.0". Muss ich vielleicht auf meiner FW auch ein PPP zum Benutzen in dem Tunnel einrichten? Oder vielleicht irgendeine Bridge? Vielleicht ein virtuelles Interface? Ich habe ja 192.* und nicht 10.* wie der PP Server mir auf meinem Macbook zuordnet. Also brauche ich wohl irgendeinen Tunnel... Die GUI auf [6] ist meiner GUI eigentlich recht ähnlich. Dort wird erst ein Tunnel aufgesetzt mit den richtigen Subnetzen.


Das sollte deine FW von allein machen, aber das kann sie wohl nicht. Da liegt wohl auch der Hase im Pfeffer.


Wie dem auch sei, versuche ich den Transport-Modus zu benutzen, muss ich als Local ID und Remote ID jeweils den Typ "Host" oder "Interface IP" angeben. Nun müssen diese Dinge ja die Spezifikation auf dem PP Server matchen, sonst bekomme ich den INVALID_ID_INFORMATION. Das verstehe ich aber jetzt nicht - soll ich hier die Interne IP angeben? Die ist ja 192.*


Der PP Server erwartet keine spezielle IP, was auch nicht geht, jeder hat ne andere. Du solltest hier die IP angeben, mit der du mit dem PP Server kommunizierest. Hast du direkt ne öffentliche IP zugewiesen, dann diese, geht die Verbindung über ein NAT, dann deine lokale IP, welche die FW hat.

Was insgesamt natürlich sein kann, ist dass der Modus unter dem der PP Server läuft nicht mit deiner FW kompatibel ist, das rauszukriegen ist halt schwierig.
 
Habe nun mal von der anderen Seite aus angefangen zu graben: http://www.dslreports.com/forum/r29876859-

Mein nächster Schritt ist jetzt dieses IKE-Paket abzufangen um zu sehen was genau da von der FW an den PP Server geschickt wird. Vielleicht kann man das gleiche auch mit Android machen und dann einfach vergleichen (habe zwar kein Android, kann man sich aber sicher besorgen).

Ich werde es auch mal vermehrt mit Cisco IPSec versuchen, also Tunnel-Modus. Dann wird gar kein L2TP gebraucht und am Ende ist es vielleicht sogar etwas schneller.

Du bist wie ein imaginärer Freund in dieser Herausforderung, vielen Dank ;)
 
Back
Top