Archiv verlassen und diese Seite im Standarddesign anzeigen : freeswan - Linux-Gateway/Linux-Roadwarrior
schuelsche
01.07.03, 15:43
Hallo Ihrs,
so langsam treibt mich diese FreeS/WAN-Geschichte zur Verzweiflung... Eigentlich kann das doch alles nicht so schwierig sein, vor allem weil's soviele Tutorials gibt und Leute, die das schon geschafft haben... Aber mir gelingt es nicht!
Also, ich versuche nun seit ca. 1 Woche diese Geschichte zum Laufen zu bringen.
Ich habe hier einen Linux-Server mit SuSE Linux 8.2 drauf (linuxserver) der als Gateway zwischen einem Netz 192.168.10.0 und 192.168.20.0 fungiert.
Weiterhin habe ich hier einen Rechner (client) im Netzwerk 192.168.20.0 mit der IP 192.168.20.2.
Auf dem linuxserver habe ich freeS/WAN 1.99 installiert. Mittels openssl habe ich ein paar Zertifikate nach der Anleitung von www.shinewelt.de/linux erstellt, es gibt also auf der Gateway-Seite die Zertifikate gatecert.pem und gatekey.key. Ebenfalls auf dem Gateway habe ich zwei Roadwarriorzertifikate erstellt, roadwarrior.key und roadwarriorcert.pem. (Die Umwandlungen für spätere Win2k-Clients mittels openssl x509 haben auch funktioniert.).
So, dann gehts zur ipsec.secrets-Konfiguration:
Das erste, was ich in sämtlichen Tutorials nicht verstehe, ist, dass die ipsec.secrets nur aus einer Zeile bestehen soll, und zwar ": RSA gatekey.key "passwort". Irgendwo habe ich gelesen, dass hier das passwort im Klartext stehen soll. Wenn ich mir meine ipsec.secrets anschaue, dann steht da drin
":RSA {.... dann folgt der ellenlange verschlüsselte Schlüssel über mehrere Zeilen....}"
Ich habe jetzt am Ende noch dazu geschrieben:
": RSA gatekey.key "passwort"
Ist das so richtig oder muss ich den ellenlangen Schlüssel rauslöschen? Darf in dieser Datei NUR letztgenannter RSA stehen??
Ein "ipsec verify" auf dem gateway bringt ok-Meldungen ausser bei "Looking for forward key for linuxserver Host not found.[FAILED]
In den Fehlermeldungen auf freeswan.org hab ich dazu nix gefunden ;-( Und der Key liegt doch schon auf dem gateway auch in den entsprechenden Verzeichnissen...
Weiter gehts dann mit der ipsec.conf:
Leider benutzen die meisten Tutorials und Hilfen abwechselnd left oder right für das lokale Netzwerk und umgekehrt... Auch oben genanntes Tutorial bringt mich ab diesem Punkt nicht mehr weiter, da dieses von der Benutzung eines Win2k-Clients als Roadwarrior ausgeht. Ich will aber zunächst mal einen Linux-Rechner (eben den oben genannten) hierfür benutzen.
Muss ich auf diesem Client auf freeswan vollständig installieren?
Und welche Dateien vom Gateway muss ich dann auf den Client wohin kopieren?
Und wenn ich nun diesen client mit dem gateway verbinden will, wie muss dann die config auf dem gateway aussehen und wie auf dem client (der client hat eine feste ip - 192.168.20.2) und der linuxserver hat ja zwei ip's (192.168.20.1 und 192.168.10.1).
Ich bin jetzt zum Einen ratlos, welche Sachen ich in der ipsec.conf eintragen muss...
Die soll ja dann so aussehen, wobei ich davon ausgehe, dass left mein lokales Netz auf dem Gateway sein soll, also 192.168.10.0 und right das Netzwerk des Clients, also 192.168.20.0:
config setup
.... (klar)
conn %default
leftrsasigkey= ??? (%cert oder das ganze Zertifikat?? Und wenn ja, von wem -client oder server?)
rightsasigkey= ??? (wie oben)
conn test
left=?? (%any, 192.168.10.0, ????)
leftcert=??? (welches zert)
right= ?? (%defaultroute? wo geht das dann hin??
rightcert=.??
rightid=???
rightsubnet=???
auto=add
pfs=yes
Und im Gegenzug muss ja wahrscheinlich auf dem Linuxclient irgendwas in der config eingetragen werden??! Was?
Und schliesslich und zu guter Letzt:
wenn alles eingerichtet ist, wie starte ich dann auf dem Linuxrechner die Verbindung? Was muss ich dafür auf der Shell eingeben??
Puuhh... sorry, dass es so lang geworden ist, aber ich wollte möglichst viele Infos reinpacken...
Ich hoffe, dass jemand helfen kann, vielleicht gibts auch noch ausführlichere Tutorials als das bei tecchannel, (die c't wie auch das linuxmagazin hab ich auch schon durchgeforstet), oder bei linux01.gwdg.de/~cthiel1/howtos...
Grüsse
schuelsche
erstes grundlegendes Problem:
Du benutzt den Standard Freeswan 1.99 OHNE X509 Patch. Geh mal freeswan.ca und zieh dir da das passende, bzw. strongsec.com
ich bastel seit 2 oder 3 Monaten an den x509 Zertifikaten um meine win2k möhre mit nem Linux rechner zu verbinden... ich bekomms einfach nicht hin... schon deprimierend :(
schuelsche
02.07.03, 09:51
Hi rudelm,
in diesem Thread
http://www.linuxforen.de/forums/showthread.php?s=&threadid=81509
steht, dass bei SuSE 8.2 und freeswan 1.99 der Patch bereits drin sei. Ich habe ja auch das Zertifikat etc. für Win2k erstellen können. Nur dieses Zertifikat brauche ich doch nicht, wenn ich zwei Linux-Rechner miteinander verbinden will?!
In dem Tutorial von freeswan-org steht zur Road Warrior Konfiguration nur, dass auf beiden freeswan laufen soll. Das x509-Zertifikat brauche ich dann später, wenn ich eine Verbindung zu einem Win2K-Warrior machen will. So habe ich das zumindest verstanden...
Nur weiss ich jetzt immer noch nicht, ob die ganzen Zertifikate, die ich auf dem gateway erstellt habe, nun auf den linux-client müssen oder ob ich hier noch wieder eigene Zertifikate erstellen muss...
Ich will doch eigentlich nur zu Übungszwecken einfach den Laptop aus dem anderen Netzwerk mit dem Gateway per VPN verbinden... Und ich habe dazu leider keine 4 Rechner und zwei Hubs, wie im Linuxmagazin "angeordnet" zur Verfügung, sondern leider nur einen Gateway-Rechner mit zwei Netzwerkkarten und ein Laptop, dass per Crossoverkabel mit diesem Gateway verbunden ist und in einem anderen Netz "funkt". Eigentlich gehts ja "nur" noch um die Config und das Hin-. und Herschieben der erstellten Zertifikate, aber so langsam weiss ich gar nciht mehr, wo da was hin muss...
Grübelgrüsse
schuelsche
Hi,
also erst mal danke für den ersten Link aus deinem Posting, das Tutorial beschrieb irgendwie ganz andere Positionen der Zertifikate, endlich bin ich mal nen schritt weitergekommen mit ipsec :)
Also da du nur 2 Netze miteinander verbinden möchtest, machst du das am besten mit Preshared Keys. das habe ich auch als erstes gemacht und halt x509 jetzt als nächsten schritt gewählt.
ich würde dir auch raten dich auf der freeswan mailing liste und in dem archiv mal umzuschauen.
freeswan.ca und da unter support. da hab ich jetzt auch wieder ne mail hingeschickt weil ich nicht mehr weiter weiß mit den zertifikaten :(
schuelsche
02.07.03, 15:21
Hi rudelm,
also ich kann Dir noch jede Menge weitere Links auf Tutorials liefern, die ich mittlerweile durchgeackert habe ;-)
Momentan hänge ich an der ipsec.config fest... Die Zertifikate und alles habe ich ja schon erstellt, jetzt sollte nur noch irgendwie eine Verbindung zustande kommen... Und das klappt nicht. Irgendwie stimmen meine configs eben nicht. Ich bin ja schon soweit zurück, dass ich mittlerweile nur noch ein VPN im gleichen Netzwerk machen will... Quasi zwei Rechner, verbunden über LAN. Einer hat die IP 192.168.10.1 (Server) und der andere die IP 192.168.10.2 (Client). Zertifikate liegen auf dem Server. Beide Rechner haben Linux SuSE 8.2 mit FreeS/WAN 1.99.
Wie muss die config aussehen? Gibts doch nicht, dass das so schwer ist???
Ach so, hier noch ein paar Tutorial-Links:
http://www.fbi-lkt.fh-karlsruhe.de/lab/info01/Semesterarbeiten/Ws02-03/Betriebssysteme/Linux-IPSEC/ipsec1.html
http://www.fbi-lkt.fh-karlsruhe.de/lab/info01/Semesterarbeiten/Ws02-03/Betriebssysteme/Linux-IPSEC/ipsec2.html
Unter SuSE Linux 8.2:
/usr/share/doc/packages/freeswan/x509-step-by-step//freeswan-1.html
/usr/share/doc/packages/freeswan/x509-install.html
Linux HowTos online:
http://www.tldp.org
http://www.strongsec.com/freeswan/install.htm
http://www.freeswan.ca/docs/WindowsInterop
http://www.shinewelt.de/linux
http://www.dcc-asia.de/tech/vpn/index_content.html
http://linux01.gwdg.de/~cthiel1/howtos/freeswan/freeswan-4.html
Die diversen heise-Artikel:
http://www.heise.de/security/artikel/38014
http://www.heise.de/02/05/216
http://www.heise.de/02/05/220
... to be continued ...
Grüsse
schuelsche
Also ich würde wie gesagt erst mal mit den Preshared Keys versuchen das ganze zu starten, da kannste z.B. hier mal gucken: http://jixen.tripod.com
ich hab hier mal nen auszug aus meiner kleinen howto Anleitung die ich hier erstellt habe beim Praktikum:
Aufbau der ipsec.conf datei in /etc
Die Einschübe müssen entweder ein Tab sein, oder 8 Leerzeichen
config setup
interfaces="ipsec0=eth2" <= musst du bei dir wohl auf eth0 stellen
# Debug-logging controls: "none" for (almost) none, "all" for lots.
klipsdebug=all
plutodebug=dns
# Bereits aufgebaute und dann getrennte Verbindungen (durch Timeouts) wieder unter der gleichen IP ermoeglichen
uniqueids=yes
# Add connections here.
conn test
#Authentifizieren durch gemeinses Secret
authby=secret
#Remote IP Adresse (Right), Ziel Adresse des Tunnels
right=192.168.226.31 <= klar, die IPs musste noch auf dein Netz anpassen
rightsubnet=192.168.226.0/24
rightnexthop=192.168.226.1
#Local IP Adresse (Left), Anfangs Adresse des Tunnels
left=192.168.253.4
leftsubnet=192.168.253.0/24
leftnexthop=192.168.253.1
#Verbindung automatisch in die Liste der Verbindungen hinzufügen, aber nicht wählen
auto=add
pfs=yes
· abspeichern
· Der Befehl zum erzeugen des Preshared Keys lautet: ipsec ranbits 128
· Den erzeugten Key zwischenspeichern in der Ablage, dann in die Datei /etc/ipsec.secrets abspeichern
Aufbau Datei /etc/ipsec.secrets
<VPN Gatewayrechner IP Adresse> <Zieladresse des Tunnels, bzw. IP des anderen VPN Teilnehmers> : PSK "<dein preshared key>"
· Datei abspeichern
· Datei nur Root rechte geben mit: chmod +700 ipsec.secrets
das Gleiche musst du dann auch auf dem anderen Rechner in der ipsec.conf eintragen, allerdings musst du die IP Adressen noch tauschen (klar, weil andere Seite)
damit konnte ich bei mir ne Connection aufbauen zu nem win2k client, da musste man dann mit dem ipsec tool von ebootis was machen, aber im moment scheinst du ja nur linux zu linux zu brauchen.
das starten der Verbindungen müsstest du mal in der Freeswan doku gucken, ich glaub das war was mit "ipsec auto add verbindungsname" oder so.
Ich hänge im moment an folgender Meldung fest...
"Informational Exchange message for ISAKMP SA must be encrypted" oder "invalid cookie"
schuelsche
03.07.03, 15:09
Hi,
Dir, rudelm, ebenso vielen Dank für den letzten Link, das ist schon irgendwie hilfreich, zumindest krieg ich damit wenigstens mal wieder einen Überblick ;-) ... oder auch nicht...
Jedenfalls hab ich jetzt mal ne grundsätzliche Frage:
ich habe es jetzt die ganze Zeit so gemacht, dass ich die jeweiligen ipsec.conf's (also auf server und client) "gespiegelt" habe, das heisst, wenn auf dem server in der "conn roadwarrior" left=192.168.10.1 stand, dann stand dies in der ipsec.conf vom client in right.
Wenn ich mir die von Dir genannte Doku anschaue, dann muss die ipsec.conf auf beiden Rechnern haargenau gleich aussehen?! Nur mit unterschiedlichen lefts?!
Bezüglich Deiner ipsec.secrets-Datei: wie genau muss die aussehen, wenn mein Gatewayrechner die IP 192.168.10.1 hat? Und Zieladresse des tunnels ist dann die IP des Clients? Also quasi so:
192.168.10.1 192.168.10.2 : PSK
... und die speichere ich dann auf beiden in der ipsec.conf?!
Und dann nochwas:
jetzt will ich eigentlich nur mal so'ne VPN-Verbindung innerhalb des LANS (!) hinbekommen, damit überhaupt mal was tut. Geht so'ne VPN-Verbindung überhaupt so quasi Client zu Client-mässig?? Müsste doch, oder?! Oder brauche ich auf der einen Seite immer einen Gateway?
Verwirrte Grüsse,
schuelsche
hi schuelsche,
also:
1) es ist schon richtig das du die Einträge left und right spiegelst. Du solltest dir folgendes merken: left steht für local, right für remote. Soll heißen, wenn dein left gateway die 10.1 ist, dann ist dein right die 10.2. Auf dem anderen Gateway wäre dann local die 10.2 und right die 10.1
2) in der ipsec.conf werden nur die Verbindungsbeschreibungen beschrieben, also z. B.
#Authentifizieren durch gemeinses Secret
authby=secret
in der ipsec.secrets stehen deine Preshared Keys, kurz PSK.
das wäre dann z.B. für die oben genannte erste Seite:
192.168.10.1 192.168.10.2 : PSK "passwort_oder_eine_zahlenkombination"
auf der anderen Seite müsstest du jetzt in der ipsec.secrets nur die IPs tauschen, das PSK muss natürlich gleichbleiben!
3) ja das müsste Client zu Client gehen, denke ich zumindest. Ich hatte das bei mir hier zuhause auch mal vor zu probieren, zwischen nem linux rechner und nem w2k rechner... bin aber aus Frustration und Zeitmangel da nicht weiter gekommen. Evtl. mach ich das im August, dann ist mein Praktikum vorbei
Ich hab heute Email von einem der Freeswan Entwicklern bekommen, bei meinem Problem scheint es sich um nen Fehler mit den Zertifkaten zu handeln. Mal sehen, entweder morgen oder Montag werde ich mal versuchen neue Zertifikate zu erzeugen um dann nen neuen Versuch zu starten.
greets
Zuerst musst du dich anhand der Situation für preshared secrets, automatic keyed connection oder X.509 Zertifikate benutzen willst. Letzteres braucht den Patch von A. Steffen.
Für die Fehlerbehebung sind folgende Angaben wichtig:
ipsec.conf
$ ipsec verify
$ tail -f /var/log/warn # wärend der Verbindungsaufname
und die Ausgabe von $ ipsec setup restart
Gruss, Andy
PS: Ich habe gerade die Prüfung bei Andreas Steffen abgelegt, ich hoffe der IPsec Teil ist richtig ;)
ah geil, nen direkten Draht zum x509 meister *freu*
ja mal sehen das ich jetzt noch mal die zertifikate neu erzeuge, sonst hau ich dich noch mal an rapidmax ;)
mal hoffen das die Prüfung positiv verläuft ;)
Original geschrieben von rudelm
ah geil, nen direkten Draht zum x509 meister *freu*
Naja, ein direkter Draht ist das eine, praktische Erfahrung das andere: Abgesehen, dass ich die Grundlagen verständlich vermittelt bekam, hatte ich leider noch keine Zeit mich intensiv damit auseinanderzusetzen.
Apropos: Rate mal in welchem Raum er sein Büro hat? Genau: E509 :D
ja mal sehen das ich jetzt noch mal die zertifikate neu erzeuge, sonst hau ich dich noch mal an rapidmax ;)
mal hoffen das die Prüfung positiv verläuft ;)
thx, frag einfach...
Gruss, Andy
schuelsche
04.07.03, 10:52
Im folgenden poste ich jetzt mal mein "kleines" HowTo.
Die Verbindung mittels PSK steht jetzt glaube ich ;-)))) Danke rudelm für den Hinweis.
Unten hab ich dann noch Fragen....
lclient --------------- lgateway -------------- firmenrechner
192.168.110.2 192.168.110.1 192.168.50.23
192.168.50.85
Ein Rechner (linuxclient; SuSE Linux 8.2 mit FreeS/WAN 1.99) im 192.168.110.0-Netz:
IP 192.168.110.2 und Netzmask 255.255.255.0 (eth0)
Rechnername lclient, Domain local
Namerserver 192.168.50.85 (=lgateway), Domain firma
Routing 192.168.110.1
Ein Gateway (linuxserver; SuSE Linux 8.2 mit FreeS/WAN 1.99)
IP 192.168.110.1 und Netzmask 255.255.255.0 (eth1)
IP 192.168.50.85 und Netzmask 255.255.255.0 (eth0)
Rechnername lgateway, Domain local (eth1)
Rechnername lgateway, Domain firma (eth0)
Nameserver 192.168.50.85, Domain firma
Routing: 192.168.50.85
Routing table:
Destination: 192.168.110.0; Gateway: 192.168.110.1; Netmask: 255.255.255.0; Device: eth0
Destination: 192.168.50.0; Gateway: 192.168.50.85; Netmask: 255.255.255.0; Device: eth1
[x]Enable IP Forwarding
Gateway hängt im Firmennetzwerk. Dort gibt es den Firmenrechner mit der IP 192.168.50.23 (mit SuSE Linux 8.1), der später angepingt werden können soll und der somit quasi für das Firmennetzwerk steht.
Eine Firewall ist auf keinem Rechner aktiv.
Folgende /etc/ipsec.conf liegt auf dem LGATEWAY:
# /etc/ipsec.conf - FreeS/WAN IPsec configuration file
# More elaborate and more varied sample configurations can be found
# in FreeS/WAN's doc/examples file, and in the HTML documentation.
# basic configuration
config setup
# Interface, über das die IPsec-Verbindungsanfragen eingehen
interfaces="ipsec0=eth1"
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
conn %default
keyingtries=1
conn roadwarrior
# Lokale IPAdresse (Anfangsadresse des Tunnels)
left=192.168.110.1
# Lokales Netz das erreicht werden soll
leftsubnet=192.168.50.0/255.255.255.0
# Adresse des lokalen Routers
leftnexthop=
# Remote IPAdresse (Zieladresse des Tunnels)
right=192.168.110.2
rightsubnet=
rightnexthop=
# Serverseite:add (automatisch hinzufügen); Clientseite:start (manuelles Starten)
auto=add
# Identifizierung durch secret oder rsasig (dann keys)
authby=secret
# Perfect Forwarding Secrecy
pfs=yes
Folgende /etc/ipsec.conf liegt auf dem LCLIENT:
# /etc/ipsec.conf - FreeS/WAN IPsec configuration file
# More elaborate and more varied sample configurations can be found
# in FreeS/WAN's doc/examples file, and in the HTML documentation.
# basic configuration
config setup
# Lokale IP-Adresse angeben (bei defaultroute automatisch)
interfaces=%defaultroute
klipsdebug=none
plutodebug=none
plutoload=%search
plutostart=%search
conn %default
keyingtries=1
conn roadwarrior
# Lokale IPAdresse (Anfangsadresse des Tunnels)
left=%defaultroute
leftsubnet=
leftnexthop=
# Remote IPAdresse (Zieladresse des Tunnels)
right=192.168.110.1
rightsubnet=192.168.50.0/255.255.255.0
rightnexthop=
auto=start
# Identifizierung durch secret oder rsasig (dann keys)
authby=secret
pfs=yes
Auf dem LGATEWAY wird nun ein PreSharedKey mittels der Eingabe "ipsec ranbits 128" auf der Shell erzeugt: 0x59718df3_dedb810c_ec4298d3_bbe8826e.
Dieser PSK wird wie folgt beschrieben in die beiden ipsec.secrets eingetragen.
Auf dem LGATEWAY wird nun die /etc/ipsec.secrets geöffnet und folgendes eingetragen:
# This file holds shared secrets or RSA private keys for inter-Pluto
# authentication. See ipsec_pluto(8) manpage, and HTML documentation.
#
# RSA private key for this host, authenticating it to any other host
# which knows the public part. Suitable public keys, for ipsec.conf, DNS,
# or configuration of other implementations, can be extracted conveniently
# with "ipsec showhostkey".
# Anfangsadresse=IP LGATEWAY Endadresse=IP LCLIENT : PSK "..."
192.168.110.1 192.168.110.2 : PSK "0x59718df3_dedb810c_ec4298d3_bbe8826e"
Auf dem LCLIENT wird jetzt die /etc/ipsec.secrets geöffnet und folgendes eingetragen:
# This file holds shared secrets or RSA private keys for inter-Pluto
# authentication. See ipsec_pluto(8) manpage, and HTML documentation.
#
# RSA private key for this host, authenticating it to any other host
# which knows the public part. Suitable public keys, for ipsec.conf, DNS,
# or configuration of other implementations, can be extracted conveniently
# with "ipsec showhostkey".
# Anfangsadresse=IP LCLIENT Endadresse=IP LGATEWAY : PSK "..."
192.168.110.2 192.168.110.1 : PSK "0x59718df3_dedb810c_ec4298d3_bbe8826e"
Jetzt wird auf dem LGATEWAY die ipsec-Verbindung gestartet mittels der Eingabe "ipsec setup start" auf der Konsole.
Folgende Ausgabe erscheint auf dem Bildschirm:
lgateway:~ # ipsec setup start
ipsec_setup: Starting FreeS/WAN IPsec 1.99...
ipsec_setup: ipsec ipsec_3des ipsec_md5 ipsec_sha1
ipsec_setup: done
lgateway:~ #
Ebenso wird jetzt die ipsec-Verbindung auf dem LCLIENT gestartet mittels der Eingabe "ipsec setup start" auf der Konsole.
Folgene Ausgabe erscheint dabei auf dem Bildschirm:
lclient:/var/log # ipsec setup start
ipsec_setup: Starting FreeS/WAN IPsec 1.99...
ipsec_setup: ipsec ipsec_3des ipsec_md5 ipsec_sha1
ipsec_setup: done
lclient:/var/log #
Auf dem LGATEWAY überprüft man mit "ipsec verify" den Stand der Dinge. Dabei kommt folgende Ausgabe:
lgateway:~ # ipsec verify
Checking your system to see if IPsec was installed and started correctly
Version check and ipsec on-path [OK]
Checking for KLIPS support in kernel [OK]
Checking for RSA private key (/etc/ipsec.secrets) [OK]
Checking that pluto is running [OK]
DNS checks.
Looking for forward key for lgateway Host not found, try again.
[FAILED]
Does the machine have at least one non-private address [OK]
lgateway:~ #
Auf dem LCLIENT überprüft man ebenfalls mit "ipsec verify" den Stand der Dinge. Dabei kommt folgende Ausgabe:
lclient:/ # ipsec verify
Checking your system to see if IPsec was installed and started correctly
Version check and ipsec on-path [OK]
Checking for KLIPS support in kernel [OK]
Checking for RSA private key (/etc/ipsec.secrets) [OK]
Checking that pluto is running [OK]
DNS checks.
Looking for forward key for lclient [FAILED]
Does the machine have at least one non-private address [FAILED]
lclient:/ #
Nachdem ich zuerst auf dem LGATEWAY die FreeS/WAN mit "ipsec setup start" und anschliessend auf dem LCLIENT mit "ipsec setup start" starte, lässt sich der LGATEWAY vom CLIENT aus nicht mehr über "ping 192.168.110.1" anpingen. Ebensowenig funktioniert es in die umgekehrte Richtung. Der Ping bleibt einfach stehen, es passiert nix. Die Rechner können sich erst wieder anpingen, wenn auf beiden (!) FreeS/WAN über "ipsec setup stop" gestoppt werden.
Ein erneutes "ipsec verify" bringt immer noch obige Meldungen auf beiden Rechnern.
Auf dem LGATEWAY rufe ich auf: vi /var/log/messages:
Ab dem Zeitpunkt des FreeS/WAN-Starts stehen hier folgende Meldungen:
2208 ipsec_setup: Starting FreeS/WAN IPsec 1.99...
2209 kernel: ipsec_3des_init(alg_type=15 alg_id=3 name=3des): ret=0
2210 kernel: ipsec_md5_init(alg_type=14 alg_id=2 name=md5): ret=0
2211 kernel: ipsec_sha1_init(alg_type=14 alg_id=3 name=sha1): ret=0
2212 ipsec_setup: ipsec ipsec_3des ipsec_md5 ipsec_sha1
2213 ipsec_setup: KLIPS ipsec0 on eth1 192.168.110.1/255.255.255.0 broadcast 192 .168.110.255
2214 ipsec__plutorun: Starting Pluto subsystem...
2215 pluto[4583]: Starting Pluto (FreeS/WAN Version 1.99)
2216 pluto[4583]: including X.509 patch with traffic selectors (Version 0.9.23 )
2217 pluto[4583]: including NAT-Traversal patch (Version 0.5a) [disabled]
2218 pluto[4583]: ike_alg_register_enc: Activating OAKLEY_AES_CBC: Ok (ret=0)
2219 pluto[4583]: ike_alg_register_enc: Activating OAKLEY_BLOWFISH_CBC: Ok (ret= 0)
2220 pluto[4583]: ike_alg_register_hash: Activating OAKLEY_SHA2_256: Ok (ret=0)
2221 pluto[4583]: ike_alg_register_hash: Activating OAKLEY_SHA2_512: Ok (ret=0)
2222 pluto[4583]: ike_alg_register_enc: Activating OAKLEY_TWOFISH_CBC: Ok (ret=0 )
2223 pluto[4583]: ike_alg_register_enc: Activating OAKLEY_SSH_PRIVATE_65289: Ok (ret=0)
2224 pluto[4583]: Changing to directory '/etc/ipsec.d/cacerts'
2225 pluto[4583]: loaded cacert file 'crl.pem' (694 bytes)
2226 pluto[4583]: error in X.509 certificate
2227 pluto[4583]: loaded cacert file 'RootCA.der' (1177 bytes)
2228 pluto[4583]: Changing to directory '/etc/ipsec.d/crls'
2229 linuxserver pluto[4583]: loaded crl file 'crl.pem' (694 bytes)
2230 pluto[4583]: loaded my default X.509 cert file '/etc/x509cert.der' (1219 bytes)
2231 ipsec_setup: ...FreeS/WAN IPsec started
2232 ipsec_setup: ^M^[[80C^[[10D^[[1;32mdone^[[m^O
2233 pluto[4583]: | from whack: got --esp=3des
2234 pluto[4583]: | from whack: got --ike=3des
2235 pluto[4583]: added connection description "roadwarrior"
2236 pluto[4583]: listening for IKE messages
2237 pluto[4583]: adding interface ipsec0/eth1 192.168.110.1
2238 pluto[4583]: loading secrets from "/etc/ipsec.secrets"
2239 /etc/hotplug/net.agent[4491]: No HW description found ... exiting
2240 /etc/hotplug/net.agent[4484]: No HW description found ... exiting
2241 /etc/hotplug/net.agent[4498]: No HW description found ... exiting
2242 /etc/hotplug/net.agent[4504]: No HW description found ... exiting
2243 pluto[4583]: "roadwarrior" #1: responding to Main Mode
2244 pluto[4583]: "roadwarrior" #1: Peer ID is ID_IPV4_ADDR: '192.168.110.2'
2245 pluto[4583]: "roadwarrior" #1: sent MR3, ISAKMP SA established
2246 pluto[4583]: "roadwarrior" #2: responding to Quick Mode
2247 pluto[4583]: "roadwarrior" #2: IPsec SA established
Auf dem LCLIENT stehen ab dem FreeS/WAN-Start in /var/log/messages folgende Meldungen:
4274 ipsec_setup: Starting FreeS/WAN IPsec 1.99...
4275 kernel: ipsec_3des_init(alg_type=15 alg_id=3 name=3des): ret=0
4276 kernel: ipsec_md5_init(alg_type=14 alg_id=2 name=md5): ret=0
4277 kernel: ipsec_sha1_init(alg_type=14 alg_id=3 name=sha1): ret=0
4278 ipsec_setup: ipsec ipsec_3des ipsec_md5 ipsec_sha1
4279 ipsec_setup: KLIPS ipsec0 on eth0 192.168.110.2/255.255.255.0 broadcast 192. 168.110.255
4280 ipsec__plutorun: Starting Pluto subsystem...
4281 pluto[5367]: Starting Pluto (FreeS/WAN Version 1.99)
4282 pluto[5367]: including X.509 patch with traffic selectors (Version 0.9.23)
4283 pluto[5367]: including NAT-Traversal patch (Version 0.5a) [disabled]
4284 pluto[5367]: ike_alg_register_enc: Activating OAKLEY_AES_CBC: Ok (ret=0)
4285 pluto[5367]: ike_alg_register_enc: Activating OAKLEY_BLOWFISH_CBC: Ok (ret=0 )
4286 pluto[5367]: ike_alg_register_hash: Activating OAKLEY_SHA2_256: Ok (ret=0)
4287 pluto[5367]: ike_alg_register_hash: Activating OAKLEY_SHA2_512: Ok (ret=0)
4288 pluto[5367]: ike_alg_register_enc: Activating OAKLEY_TWOFISH_CBC: Ok (ret=0)
4289 pluto[5367]: ike_alg_register_enc: Activating OAKLEY_SSH_PRIVATE_65289: Ok ( ret=0)
4290 ipsec_setup: ...FreeS/WAN IPsec started
4291 ipsec_setup: ^M^[[111C^[[10D^[[1;32mdone^[[m^O
4292 pluto[5367]: Changing to directory '/etc/ipsec.d/cacerts'
4293 pluto[5367]: loaded cacert file 'cacert.pem' (1651 bytes)
4294 pluto[5367]: Changing to directory '/etc/ipsec.d/crls'
4295 pluto[5367]: loaded crl file 'crl.pem' (694 bytes)
4296 pluto[5367]: could not open my default X.509 cert file '/etc/x509cert.der'
4297 pluto[5367]: OpenPGP certificate file '/etc/pgpcert.pgp' not found
4298 pluto[5367]: | from whack: got --esp=3des
4299 pluto[5367]: | from whack: got --ike=3des
4300 pluto[5367]: added connection description "roadwarrior"
4301 pluto[5367]: listening for IKE messages
4302 pluto[5367]: adding interface ipsec0/eth0 192.168.110.2
4303 pluto[5367]: loading secrets from "/etc/ipsec.secrets"
4304 pluto[5367]: "roadwarrior" #1: initiating Main Mode
4305 pluto[5367]: "roadwarrior" #1: Peer ID is ID_IPV4_ADDR: '192.168.110.1'
4306 pluto[5367]: "roadwarrior" #1: ISAKMP SA established
4307 pluto[5367]: "roadwarrior" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+ DISABLEARRIVALCHECK
4308 pluto[5367]: "roadwarrior" #2: sent QI2, IPsec SA established
4309 ipsec__plutorun: 104 "roadwarrior" #1: STATE_MAIN_I1: initiate
4310 ipsec__plutorun: 106 "roadwarrior" #1: STATE_MAIN_I2: sent MI2, expecting MR 2
4311 ipsec__plutorun: 108 "roadwarrior" #1: STATE_MAIN_I3: sent MI3, expecting MR 3
4312 ipsec__plutorun: 004 "roadwarrior" #1: STATE_MAIN_I4: ISAKMP SA established
4313 ipsec__plutorun: 112 "roadwarrior" #2: STATE_QUICK_I1: initiate
4314 ipsec__plutorun: 004 "roadwarrior" #2: STATE_QUICK_I2: sent QI2, IPsec SA es tablished
4315 /etc/hotplug/net.agent[5264]: No HW description found ... exiting
4316 /etc/hotplug/net.agent[5277]: No HW description found ... exiting
4317 /etc/hotplug/net.agent[5291]: No HW description found ... exiting
4318 /etc/hotplug/net.agent[5285]: No HW description found ... exiting
Nach diesen Meldungen gehe ich davon aus, dass eine Verbindung hergestellt wurde, da ja in den Zeilen 2243ff (LGATEWAY) und 4308ff (LCLIENT) irgendwas von wegen ISAKMP SA established steht. Zumindest steht dies im Tutorial von freeswan.org so im Troubleshooting-Guide:
a connection is established when you see messages like this:
000 #21: "myconn" STATE_MAINI4 (ISAKMP SA established)...
000 #2: "myconn" STATE_QUICKI2 (sent QI2, IPsec SA established)
Ich versuche dann auf dem lclient die Connection zu starten (denn diese muss ja vom Client aus gestartet werden!) durch die Eingabe von "ipsec auto --up roadwarrior".
Folgende Meldung erscheint auf dem Bildschirm:
lclient:/ # ipsec auto --up roadwarrior
112 "roadwarrior" #3: STATE_QUICK_I1: initiate
004 "roadwarrior" #3: STATE_QUICK_I2: sent QI2, IPsec SA established
Anschliessend pinge ich einfach mal den Client im 192.168.50.0-Netzwerk mit der IP 192.168.50.23 an:
lclient:/ # ping 192.168.50.23
PING 192.168.50.23 (192.168.50.23) 56(84) bytes of data.
64 bytes from 192.168.50.23: icmp_seq=1 ttl=63 time=9.64 ms
64 bytes from 192.168.50.23: icmp_seq=2 ttl=63 time=19.3 ms
Ein Ping auf die IP des LGATEWAY 192.168.110.1 funktioniert allerdings immer noch nicht, dafür funktioniert ein Ping auf die andere IP des LGATEWAY 192.168.50.85. Auch ein Ping vom LGATEWAY in Richtung des LCLIENT funktioniert nicht.
Allerdings weiss ich nicht, ob der Ping auf das Netzwerk 192.168.50.0 durch das VPN funktioniert oder weil ich ja im kleinen Netzwerk eigentlich mit drin bin über den Gateway.
Laut freeswan.org "How to Configure"-Guide kann man die Pakete, die auf dem Client existieren, mit dem Kommando "tcpdump -i wlan0" testen: (bei mir wäre das ja dann eth0, da "tcpdump -i wlan0" die Fehlermeldung "tcpdump: bind: No such device" bringt):
es passiert gar nix.
Ich schicke dann mal probeweise einen Ping vom Firmenrechner (IP 192.168.50.23) auf den lclient und kann dann im tcpdump lesen:
10:47:19.635891 192.168.110.1 > lclient.local: ESP(spi=0xec15c3e0,seq=0xd)
10:47:19.637554 lclient.local > 192.168.110.1: ESP(spi=0xa69e611e,seq=0xd)
10:47:20.645632 192.168.110.1 > lclient.local: ESP(spi=0xec15c3e0,seq=0xe)
10:47:20.652353 lclient.local > 192.168.110.1: ESP(spi=0xa69e611e,seq=0xe)
10:47:21.601758 arp who-has lclient.local tell 192.168.110.1
10:47:21.609408 arp reply lclient.local is-at 0:a:e6:5e:a3:d7
Da hier irgendwas von ESP steht und es in beide Richtungen funktioniert, ist wohl eine VPN-Verbindung zustandegekommen (laut dem freeswan.org "How to Configure"-Guide).
Folgende Fragen habe ich jedoch im Moment:
Wieso schlägt der DNS check fehl?!
Der DNS-Check auf dem Gateway ergibt ja "Looking for forward key for linuxserver Host not found, try again. [FAILED]".
Was bedeutet das überhaupt? Was ist denn der forward key? Und dieses "Host not found" - ist das ein Befehl oder was ist das? Hat diese Fehlermeldung evtl. was mit der Fehlermeldung in den /var/log/messages in Zeile 2226 zu tun ("error in X.509 certificate")??
Und wieso schlägt der DNS-Check auf dem Client fehl, und zwar so komplett? Hier bekomme ich ja auch die Meldung "Does the machine have at least one non-private address [FAILED]". Was soll mir das sagen? Der LCLIENT hat doch eine IP!
Und hat vielleicht auch hier die Fehlermeldung "Looking for forward key for lclient [FAILED]"
was mit der Fehlermeldung in den /var/log/messages in Zeile 4296 zu tun ("could not open my default X.509 cert file '/etc/x509cert.der'")
Auf dem lclient selbst habe ich mit openssl x509 etc noch gar keine Zertifikate erstellt, sondern lediglich die auf dem lgateway erstellten rüberkopiert. Muss ich auch hier eigene Zertifikate erstellen??
Grundsätzlich:
oben habe ich ja eine VPN-Verbindung nur mit PreSharedKeys (PSK) hergestellt. Trotzdem wird beim Starten von FreeS/WAN nach den Zertifikaten gesucht. Wie bekomme ich die denn wieder raus? Oder sucht FreeS/WAN die eben immer automatisch beim Start durch das installierte X509-Gezeugs?
Warum funktioniert der Direktping nicht (lclient -> lgateway)? Werde mir hierzu zwar nochmal genau den Hinweis aus dem freeswan.org-Tutorial auf "Other Configuration Possibilities" ansehen, aber vielleicht hat ja jemand einen Hinweis.
So wie es momentan ist, gehe ich davon aus, dass die VPN-Verbindung wirklich zustandekam. An für sich hätte ich gedacht, dass der lclient in diesem Fall vom lgateway eine neue IP zugeteilt bekommt, mit der er sich dann im 192.168.50.0-Netz bewegt. Wieso ist das nicht so? Bzw. wird das überhaupt in einem Fall so sein?
Grüsse
schuelsche,
die hofft, dass dieses lange Posting irgendjemand hilft und mir meine Fragen beantworten kann ;-)
puh.... das war lang :D
Das du dein Gateway nicht anpingen kannst, ist glaube ich ein öfters vorkommendes Problem. Da müssen dann mehrere Tunnel aufgebaut werden. Steht des öfteren in der Mailing liste und in der Freeswan Doku.
Die Meldung mit dem x509 failed kommt immer noch, weil du ja freeswan mit x509 unterstützung installiert hast, folglich versucht der bei jedem start mal nachzugucken ob da was für x509 und zertifikate parat liegt.
Die Fehlermeldung mit der no_official_IP_Adress ist klar, du hast nur private IP Adressen verwendet (192.168.X.X)
hm, mit dem DNS hab ich mich noch nicht beschäftigt, genauso wie die komplizierteren Freeswan Verbindungstypen.
@Rapidmax:
Ich hab heute ne Mail vom A. Steffen bekommen, er meint der Fehler liegt auf der Windows seite bei der Fehlermeldung:
"Informational Exchange message for ISAKMP SA must be encrypted"
Ich sollte doch mal in der oakley.log von Windows nachgucken... nun ja, ich hatte zwar nen link für das log mit in die Mail gepackt, aber egal ;)
ich hab wieder die Meldung mit dem invalid cookie, aber auch noch HandleFirstPacketResponder failed cbad034e...
7-04: 11:41:46:690 constructing ISAKMP Header
7-04: 11:41:46:690 constructing HASH (null)
7-04: 11:41:46:690 constructing DELETE
7-04: 11:41:46:690 constructing HASH (ND)
7-04: 11:41:46:690 Construct ND hash message len = 28 pcklen=80 hashlen=20
7-04: 11:41:46:690 Construct ND Hash mess ID 104af635
7-04: 11:41:46:690 ND Hash skeyid_a 738d63f196e66d48c6ae3a312f7a6a3c
7-04: 11:41:46:690 a3a2ae41
7-04: 11:41:46:690 ND Hash message 0000001c0000000101100001642b01cd
7-04: 11:41:46:690 59573ec1bd20a240fc4cd2f6
7-04: 11:41:46:690 Throw: State mask=111f
7-04: 11:41:46:690 Doing tripleDES
7-04: 11:41:46:690
7-04: 11:41:46:690 Sending: SA = 0x002380D8 to 192.168.253.4.500
7-04: 11:41:46:690 ISAKMP Header: (V1.0), len = 84
7-04: 11:41:46:690 I-COOKIE 642b01cd59573ec1
7-04: 11:41:46:690 R-COOKIE bd20a240fc4cd2f6
7-04: 11:41:46:690 exchange: ISAKMP Informational Exchange
7-04: 11:41:46:690 flags: 1 ( encrypted )
7-04: 11:41:46:690 next payload: HASH
7-04: 11:41:46:690 message ID: 104af635
7-04: 11:41:46:10c Reaper deleting SA 2380d8
7-04: 11:41:46:10c Deleting SA 002380D8
7-04: 11:41:46:10c Cancelling Timeout ed780
7-04: 11:41:46:10c ClearFragList
7-04: 11:41:52:10c
7-04: 11:41:52:10c Receive: (get) SA = 0x00000000 from 192.168.253.4.500
7-04: 11:41:52:10c ISAKMP Header: (V1.0), len = 1516
7-04: 11:41:52:10c I-COOKIE 642b01cd59573ec1
7-04: 11:41:52:10c R-COOKIE bd20a240fc4cd2f6
7-04: 11:41:52:10c exchange: Oakley Main Mode
7-04: 11:41:52:10c flags: 1 ( encrypted )
7-04: 11:41:52:10c next payload: ID
7-04: 11:41:52:10c message ID: 00000000
7-04: 11:41:52:10c invalid cookie received
7-04: 11:41:52:10c HandleFirstPacketResponder failed cbad034e
7-04: 11:41:52:10c constructing ISAKMP Header
7-04: 11:41:52:10c constructing NOTIFY 4
7-04: 11:41:52:10c ProcessFailure: sa:0057F984 centry:00000000 status:cbad034e
7-04: 11:41:52:10c Notify already constructed. Ignoring. Sa 0057F984
7-04: 11:41:52:10c Throw: State mask=2000000
7-04: 11:41:52:10c
7-04: 11:41:52:10c Sending: SA = 0x0057F984 to 192.168.253.4.500
7-04: 11:41:52:10c ISAKMP Header: (V1.0), len = 56
7-04: 11:41:52:10c I-COOKIE 642b01cd59573ec1
7-04: 11:41:52:10c R-COOKIE bd20a240fc4cd2f6
7-04: 11:41:52:10c exchange: ISAKMP Informational Exchange
7-04: 11:41:52:10c flags: 0
7-04: 11:41:52:10c next payload: NOTIFY
7-04: 11:41:52:10c message ID: 39f9146e
7-04: 11:41:53:10c
7-04: 11:41:53:10c Receive: (get) SA = 0x00000000 from 192.168.253.4.500
7-04: 11:41:53:10c ISAKMP Header: (V1.0), len = 84
7-04: 11:41:53:10c I-COOKIE 642b01cd59573ec1
7-04: 11:41:53:10c R-COOKIE 046b930b152b0a4f
7-04: 11:41:53:10c exchange: Oakley Main Mode
7-04: 11:41:53:10c flags: 0
7-04: 11:41:53:10c next payload: SA
7-04: 11:41:53:10c message ID: 00000000
7-04: 11:41:53:10c Responder received header with responder cookie non-zero
7-04: 11:41:53:10c Responding with new SA 0
7-04: 11:41:53:10c HandleFirstPacketResponder failed cbad034e
7-04: 11:41:53:10c constructing ISAKMP Header
7-04: 11:41:53:10c constructing NOTIFY 4
7-04: 11:41:53:10c ProcessFailure: sa:0057F984 centry:00000000 status:cbad034e
7-04: 11:41:53:10c Notify already constructed. Ignoring. Sa 0057F984
7-04: 11:41:53:10c Throw: State mask=2000000
7-04: 11:41:53:10c
7-04: 11:41:53:10c Sending: SA = 0x0057F984 to 192.168.253.4.500
7-04: 11:41:53:10c ISAKMP Header: (V1.0), len = 56
7-04: 11:41:53:10c I-COOKIE 642b01cd59573ec1
7-04: 11:41:53:10c R-COOKIE 046b930b152b0a4f
7-04: 11:41:53:10c exchange: ISAKMP Informational Exchange
7-04: 11:41:53:10c flags: 0
7-04: 11:41:53:10c next payload: NOTIFY
7-04: 11:41:53:10c message ID: 463a572a
7-04: 11:41:55:10c
7-04: 11:41:55:10c Receive: (get) SA = 0x00000000 from 192.168.253.4.500
7-04: 11:41:55:10c ISAKMP Header: (V1.0), len = 1516
7-04: 11:41:55:10c I-COOKIE 642b01cd59573ec1
7-04: 11:41:55:10c R-COOKIE bd20a240fc4cd2f6
7-04: 11:41:55:10c exchange: Oakley Main Mode
7-04: 11:41:55:10c flags: 1 ( encrypted )
7-04: 11:41:55:10c next payload: ID
7-04: 11:41:55:10c message ID: 00000000
7-04: 11:41:55:10c invalid cookie received
7-04: 11:41:55:10c HandleFirstPacketResponder failed cbad034e
7-04: 11:41:55:10c constructing ISAKMP Header
7-04: 11:41:55:10c constructing NOTIFY 4
7-04: 11:41:55:10c ProcessFailure: sa:0057F984 centry:00000000 status:cbad034e
7-04: 11:41:55:10c Notify already constructed. Ignoring. Sa 0057F984
7-04: 11:41:55:10c Throw: State mask=2000000
7-04: 11:41:55:10c
7-04: 11:41:55:10c Sending: SA = 0x0057F984 to 192.168.253.4.500
7-04: 11:41:55:10c ISAKMP Header: (V1.0), len = 56
7-04: 11:41:55:10c I-COOKIE 642b01cd59573ec1
7-04: 11:41:55:10c R-COOKIE bd20a240fc4cd2f6
7-04: 11:41:55:10c exchange: ISAKMP Informational Exchange
7-04: 11:41:55:10c flags: 0
7-04: 11:41:55:10c next payload: NOTIFY
7-04: 11:41:55:10c message ID: 8910e8a6
7-04: 11:41:58:10c
7-04: 11:41:58:10c Receive: (get) SA = 0x00000000 from 192.168.253.4.500
7-04: 11:41:58:10c ISAKMP Header: (V1.0), len = 1516
7-04: 11:41:58:10c I-COOKIE 642b01cd59573ec1
7-04: 11:41:58:10c R-COOKIE bd20a240fc4cd2f6
7-04: 11:41:58:10c exchange: Oakley Main Mode
7-04: 11:41:58:10c flags: 1 ( encrypted )
7-04: 11:41:58:10c next payload: ID
7-04: 11:41:58:10c message ID: 00000000
7-04: 11:41:58:10c invalid cookie received
7-04: 11:41:58:10c HandleFirstPacketResponder failed cbad034e
7-04: 11:41:58:10c constructing ISAKMP Header
7-04: 11:41:58:10c constructing NOTIFY 4
7-04: 11:41:58:10c ProcessFailure: sa:0057F984 centry:00000000 status:cbad034e
7-04: 11:41:58:10c Notify already constructed. Ignoring. Sa 0057F984
7-04: 11:41:58:10c Throw: State mask=2000000
7-04: 11:41:58:10c
7-04: 11:41:58:10c Sending: SA = 0x0057F984 to 192.168.253.4.500
7-04: 11:41:58:10c ISAKMP Header: (V1.0), len = 56
7-04: 11:41:58:10c I-COOKIE 642b01cd59573ec1
7-04: 11:41:58:10c R-COOKIE bd20a240fc4cd2f6
7-04: 11:41:58:10c exchange: ISAKMP Informational Exchange
7-04: 11:41:58:10c flags: 0
7-04: 11:41:58:10c next payload: NOTIFY
7-04: 11:41:58:10c message ID: d0e8cb2f
7-04: 11:42:13:10c
7-04: 11:42:13:10c Receive: (get) SA = 0x00000000 from 192.168.253.4.500
7-04: 11:42:13:10c ISAKMP Header: (V1.0), len = 84
7-04: 11:42:13:10c I-COOKIE 642b01cd59573ec1
7-04: 11:42:13:10c R-COOKIE 046b930b152b0a4f
7-04: 11:42:13:10c exchange: Oakley Main Mode
7-04: 11:42:13:10c flags: 0
7-04: 11:42:13:10c next payload: SA
7-04: 11:42:13:10c message ID: 00000000
7-04: 11:42:13:10c Responder received header with responder cookie non-zero
7-04: 11:42:13:10c Responding with new SA 0
7-04: 11:42:13:10c HandleFirstPacketResponder failed cbad034e
7-04: 11:42:13:10c constructing ISAKMP Header
7-04: 11:42:13:10c constructing NOTIFY 4
7-04: 11:42:13:10c ProcessFailure: sa:0057F984 centry:00000000 status:cbad034e
7-04: 11:42:13:10c Notify already constructed. Ignoring. Sa 0057F984
7-04: 11:42:13:10c Throw: State mask=2000000
7-04: 11:42:13:10c
7-04: 11:42:13:10c Sending: SA = 0x0057F984 to 192.168.253.4.500
7-04: 11:42:13:10c ISAKMP Header: (V1.0), len = 56
7-04: 11:42:13:10c I-COOKIE 642b01cd59573ec1
7-04: 11:42:13:10c R-COOKIE 046b930b152b0a4f
7-04: 11:42:13:10c exchange: ISAKMP Informational Exchange
7-04: 11:42:13:10c flags: 0
7-04: 11:42:13:10c next payload: NOTIFY
7-04: 11:42:13:10c message ID: 4d652dd8
Tja. weiter weiß ich auch nicht. Die Zertifikate stehen in dem MMC von Windows 2k als gültig drin. Bei der ipsec.conf habe ich auch drauf geachtet statt st=NRW S=NRW zu nehmen. Noch ne Idee? Die Zertifikate hatte ich also gerade noch einmal komplett neu erzeugt... ich komm einfach nicht über isakmp 1 hinnaus :(
Bei den Preshared Keys hatte ich ja wenigstens mal nen Tunnel stehen und SA 1...
Hallo Leute,
macht es euch doch nicht so schwer ich weiß das ipsec/freeswan thema ist nicht das leichteste hab auch ewig gebraucht mit konfig. und windoofs.
Also am besten und einfachsten ist das tool von ebootis -> http://vpn.ebootis.de/
und dann habe ich die Beispielkonfig. von einer Hochschule für technik benutzt.
Wird alles erklärt auf der basis von ebootis und pgpnet mit PSK oder X.509 Zertif.
Funktioniert einwandfrei -->
http://www.fbi-lkt.fh-karlsruhe.de/lab/info01/Semesterarbeiten/
Ws02-03/Betriebssysteme/Linux-IPSEC/
Ich hoffe das bringt dir oder euch weiter
Gruß efkay
Hab gerade mit die Anleitung angeguckt von der Uni Karlsruhe... Von der Art wie die Zertifikate hergestellt werden unterscheiden sich eigentlich alle Anleitungen...
Wenn ich ipsec auto --listall mache, zeigt er mir ja auch korrekt die Zertifikate an mit Aussteller und Unterschrift
[root@FreeSwan-VPN root]# ipsec auto --listall
000
000 List of Public Keys:
000
000 Jul 04 12:37:26 2003, 2048 RSA Key 0sAwEAAd2, until Jul 01 10:09:03 2013 ok
000 ID_DER_ASN1_DN 'C=DE, ST=NRW, L=Moenchengladbach, O=ADA, OU=ASC, CN=rudelm, E=markus.rudel@ada.de'
000
000 List of User/Host Certificates:
000
000 Jul 04 12:37:26 2003, count: 1
000 subject: 'C=DE, ST=NRW, L=Moenchengladbach, O=ADA, OU=ASC, CN=rudelm, E=markus.rudel@ada.de'
000 issuer: 'C=DE, ST=NRW, L=Moenchengladbach, O=ADA, OU=ASC, CN=Freeswan Test CA, E=markus.rudel@ada.de'
000 pubkey: 2048 RSA Key 0sAwEAAd2
000 validity: not before Jul 04 10:09:03 2003 ok
000 not after Jul 01 10:09:03 2013 ok
000
000 List of CA Certificates:
000
000 Jul 04 12:37:18 2003, count: 1
000 subject: 'C=DE, ST=NRW, L=Moenchengladbach, O=ADA, OU=ASC, CN=Freeswan Test CA, E=markus.rudel@ada.de'
000 issuer: 'C=DE, ST=NRW, L=Moenchengladbach, O=ADA, OU=ASC, CN=Freeswan Test CA, E=markus.rudel@ada.de'
000 pubkey: 2048 RSA Key 0sAwEAAf2
000 validity: not before Jul 04 09:57:15 2003 ok
000 not after Jun 16 09:57:15 2014 ok
000
000 List of CRLs:
000
000 Jul 04 12:37:19 2003, revoked certs: 0
000 issuer: 'C=DE, ST=NRW, L=Moenchengladbach, O=ADA, OU=ASC, CN=Freeswan Test CA, E=markus.rudel@ada.de'
000 updates: this Jul 04 10:13:01 2003
000 next Aug 03 10:13:01 2003 ok
Bin immernoch kein Stück weiter. Das ganze soll hier ja auch ohne irgendwelche Extra Programme funktionieren die Geld kosten (PGP ist dort ja nur beschrieben als frei für Privatpersonen).
Und scheinbar ist ja der Fehler doch auf der Windows Seite, wenn man sich da so das Log anguckt... Bloß da ist eignetlich auch alles ok... jetzt bin ich auch wieder an dem Punkt angelangt wo ich auch vor ein paar Wochen war, Ratlosigkeit *G*
wieso Kosten? Hast du dir das von ebootis mal durchgelesen bzw. ausprobiert das tool ist echt geil und es funzt einwandfrei mit x509 und psk
ebootis ist klar, aber das andere: PGP Net, das ist nicht kostenlos für Firmen.
Mit dem ebootis tool bekomm ich einfach nur Connections mit PSK hin, mit Certificaten nicht :(
ich hab dir doch den link von der uni geschickt ich habe das eins zu eins übernommen es läuft.
Kann das sein das du vielleicht Client-Seitig deine in der ipsec-conf --> rightca=...
Das falsche cert eingebaut hast oder die mmc ist noch falsch kann natürlich auch sein
Wo hast du das Zertifikat verstaut und wo das CA Zertifikat?
Mach mal nen Screenshot, dann muss ich nicht Windows booten...
Gruss, Andy
Hi,
ein kleiner Beitrag aus der Praxis. Irgendwie wird hier viel durcheinander gewürfelt. Es handelt sich in der anfangs beschriebenen Grundkonfiguration um SuSE 8.2 mit einer bereits "x509-gepatchten" FreeS/Wan-Version. Das ganze Teil läuft übrigens nicht im Kernel ab sondern als Modul.
Diese Konfiguration legt mir gerade in der Firma den Zugang für 8 WinClients lahm. Man kann mit LinuxClients über x509-Zertifikate einwandfrei zugreifen. Jeder WinClient mit x509-Zertifikat hat Pech gehabt.
Der Zugang für WinClients funktioniert nur dann, wenn man sich ganz rudimentär sein freeswan holt, patcht, Kernel kompiliert und arbeitet. Die SuSE-Spezialisten hatten bei der Zusammenstellung der Pakete mal wieder ihre Verkaufszahlen im Kopf. Das lenkt ab.
Mit der obigen SuSE-Spielzeug-Konfiguration kommt in Sachen WinClient und x509cert keiner weiter! Oder beweist mir jemand das Gegenteil? :) Vielleicht gibts ja wieder mal ne Fehlerkorrektur von SuSE und sie schmieren weiter zu "WindowsMalSehnObEsGeht" ab.
Grüße
rfi
hi,
ich habe das wie folgt gemacht ...
die beiden Pakete freeswan und km_freswan von der SuSE Distri installiert ...
entprechend als Modul eingebaut (wie bei der Paketbeschreibung von km_freeswan beschrieben)
dann IPSec im Runlevel-Editor aktiviert..
danach hatte ich das neue Interface ipsec0
danach bin ich nach folgender Doku vorgegangen und konnte
problemlos den Tunnel von einem Win2K Rechner aus aufbauen ..
http://www.shinewelt.de/linux/w2k_roadwarrior_freeswan.pdf
grüsse,
wisnitom,
danke für den link zur Anleitung! So was habe ich schon lange gesucht :)
schuelsche
07.07.03, 07:31
Hi,
Original geschrieben von wisnitom
hi,
ich habe das wie folgt gemacht ...
die beiden Pakete freeswan und km_freswan von der SuSE Distri installiert ...
entprechend als Modul eingebaut (wie bei der Paketbeschreibung von km_freeswan beschrieben)
dann IPSec im Runlevel-Editor aktiviert..
mmmhhh, also bislang hatte ich km_freeswan gar nicht installiert - was ist das eigentlich?
Habe das jetzt nachgeholt, allerdings finde ich nicht die von Dir beschriebene "km_freeswan" Paketbeschreibung, nur die normale von freeswan in /usr/share/doc/packages/freeswan/x509-step-by-step/freeswan.html. Meintest Du die?
danach bin ich nach folgender Doku vorgegangen und konnte
problemlos den Tunnel von einem Win2K Rechner aus aufbauen ..
http://www.shinewelt.de/linux/w2k_roadwarrior_freeswan.pdf
... das kann ich bestimmt schon bald auswendig ;-)
Nachdem die VPN-Verbindung mit PSK ja nun geklappt hat, habe ich das mal mit dem x509-Zertifkaten erneut probiert. Klappt nicht. Ich werde jetzt doch mal freeswan patchen, wie es rfi erneut angeraten hat, wenn das mit der SuSE-Standardkonfiguration doch nicht geht.
Vorab habe ich aber eine Frage:
wie kann ich denn beim Erstellen der Zertifikate überprüfen, ob sie "lesbar" sind?
Also ich erstelle das Zertifikat mit dem "sh /usr/lib/..../CA.sh -newca"-Befehl. Und dann wandele ich es ins x509-Format um mit "openssl x509 -in demoCA/cacerts.pem -outform der -out /etc/ipsec.d/cacerts/RootCA.der".
Um später die Rightid rauszubekommen kann ich ja die erstellten Zertifikate mit "openssl x509 - in Zertifikat.pem -noout -subject" auslesen. Das müsste doch jetzt mit dem RootCA.der auch gehen mit der Eingabe "openssl x509 -in RootCA.der -noout -text" ??! Ich bekomme dann die Fehlermeldung "unable to load certificate; 1991:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:666:Expecting: TRUSTED CERTIFICATE".
Also gehe ich davon aus, dass das Zertifikat nicht richtig erstellt wurde und daher dies integrierte x509-Zeugs nicht funktioniert, weshalb ich es eben jetzt mal patchen werde.
Aber ist das überhaupt der richtige Befehl oder ist es überhaupt möglich, das so zu überprüfen?
Grüsse
schuelsche
ok, hier mal ein paar screenshots wie es aussieht:
http://www.centurio.net/vpn/ca1.jpg
http://www.centurio.net/vpn/ca2.jpg
http://www.centurio.net/vpn/ca3.jpg (http://www.centurio.net/vpn/c31.jpg)
http://www.centurio.net/vpn/ca4.jpg
http://www.centurio.net/vpn/ca5.jpg
ipsec.conf vom Win2k Rechner
der sucht doch dann einfach nach einem Stammzertifikat das halt unten auf die Beschreibung in der right CA zutrifft. das rudelm Zertifikat weißt den Rechner dann doch beim Freeswan aus.
conn test
left=%any
#left=192.168.226.31
leftsubnet=192.168.226.0/24
leftnexthop=192.168.226.1
right=192.168.253.4
rightca="C=DE,S=NRW,L=Moenchengladbach,O=ADA,OU=ASC,CN=Free swan Test CA,Email=markus.rudel@ada.de"
rightsubnet=192.168.253.0/24
rightnexthop=192.168.253.1
network=auto
auto=start
pfs=yes
Also weiter als isakmp sa komm ich nicht weiter. :(
Wo hast du die Zertifikate des Windows- Clients Hingepackt?
Hast du das tool von Marcus Müller jetzt benutzt oder nicht?
Ich sitzte auch an dieser stelle fest! Ich bekomme nur erst gar keine verbindung zum server, obwohl alle configs mir als richtig erscheinen. :(
ganz exakt nach Anleitung.
Also ich habe mir ein pks12 file erzeugt (w2000.p12) und dann habe ich es über "alle Aufgaben, importieren" dann hinzugefügt. dann hab ich noch das export passwort eingetippt und halt noch gesagt "automatisch den platz zuweisen"
das ebootis tool habe ich benutzt.
Ich habe das soweit fertig.
Ich kann jetzt von meinem lokalen entpunkt gesehen meine VPN- Tunnel aufbauen.
Jetzt möchte ich aber auch von den Rechner Zuhause Zugriff auf das Netz haben. Dazu muss ich ja nun eine internetadresse haben, die auf mein Netz verweist. Ich habe mich für DynDNS entschieden und habe mir auf der DynDNS.oprg auch gleich eine Seite geben lassen. Doch jetzt hat sich mir die frage gestellt, wo ich diese Adresse jetzt eintragen muss.
Die angaben, wie das mit dem internen netz machen muss findet man ja an jeder ecke, doch mit dem tunneln über das Internet, keinen schimmer.
Ich gehe davon aus, das ich die angaben am XP- Client in der ipsec eintragen muss und auch am server in der ipsec.conf.
Doch in welche spalte, bzw ...=name@dyndns.org
Irgendwelche Ideen oder sogar selbst schon gemacht???
Original geschrieben von schuelsche
mmmhhh, also bislang hatte ich km_freeswan gar nicht installiert - was ist das eigentlich?
Habe das jetzt nachgeholt, allerdings finde ich nicht die von Dir beschriebene "km_freeswan" Paketbeschreibung, nur die normale von freeswan in /usr/share/doc/packages/freeswan/x509-step-by-step/freeswan.html. Meintest Du die?
hi,
wenn ich yast2 öffne .. software installieren .. suche .. freeswan .. dann bekomme ich
2 pakete zur auswahl ... freeswan und km_freeswan ... wähle ich km_freeswan aus,
und wähle unten den reiter beschreibung .. dann steht die beschreibung des paketes und
ganz unten in der beschreibung stehen die befehle, wie du die module in den kernel
einbinden kannst. ohne dieses paket geht es nicht, bei anderen distris musst du oft
für die ipsec implementation den kernel patchen, bei suse reicht es, wenn du die module
einbindest ..
grüsse,
schuelsche
08.07.03, 06:16
Hi,
@wisnitom
Vielen Dank für die ausführliche Erklärung über km_freeswan... bislang hatte ich das tatsächlich nicht installiert. Vielleicht liegt es auch daran, dass ich beim Start von Freeswan mit "ipsec setup start" nie den Eintrag "using /lib/modules/2.4.20-4GB/...." vorgefunden habe. Werde das jetzt mal testen.
Ausserdem habe ich gestern versucht, mit hilfe von http://joerg.fruehbrodt.bei.t-online.de/vpn_3.html Freeswan "richtig" zu installieren. Ich habe also gepatcht und dann "make menugo" gemacht und der Rechner war fortan für ungefähr 5 Stunden beschäftigt... Ist das normal? Bzw. ist das normal, dass das Kompilieren des Kernels, was das offensichtlich war, so lange braucht?! Dann kann das ja heiter werden mit dem Installieren von Freeswan...
Ich musste die Aktion dann leider abbrechen, weil ich sonst den Rechner im Geschäft die ganze Nacht hätte laufen lassen müssen und das ist ihm nicht zuzumuten ;-)
Allerdings bekomme ich heute ne Fehlermeldung beim Start von Freeswan, dass irgendwelche IPSEC-commands nicht gefunden werden. Dabei hab ich den Kernel doch noch gar nicht installiert gehabt?! Naja, ich installier jetzt nochmal das SuSE-Package normal und schau mal, was dann passiert...
@rudelm:
Du hattest hier http://www.linuxforen.de/forums/showthread.php?threadid=80331
das gleiche Problem wie ich (als Freeswan noch funktionierte): nämlich dass der Linuxserver nach dem Start nicht mehr anpingbar war und deshalb die Freeswan-Verbindung nur beendet werden kann, wenn man am Linuxserver Freeswan beendet. Wie hast Du denn dieses Problem gelöst?
Grüsse
schuelsche
Hi schuelsche:
das lag an der Firewall Einstellung. Die ließ die Pakete nur in der Richtung von meinem Rechner zum Freeswan Rechner, aber nicht zurück. Nachdem er das für den Port 500 in der Firewall auf ANY/ANY gestellt hatte, konnte ich auch durch den ipsec tunnel dann mich per ssh verbinden.
Wenn man allerdings nicht mehr an den Rechner dran kommt, nach dem IPSec aktiviert wurde, dann fällt mir auch nichts anderes ein als direkt an den Rechner gehen und da dann den ipsec Dienst deaktivieren.
Ich hab jetzt erst mal mein Notebook mit zur Arbeit genommen. Ich werde mal versuchen die Zertifikate mit einem anderen Tool unter Linux herzustellen, und zwar mit der TinyCA (http://tinyca.sm-zone.net/). Mal sehen ob das funzt :)
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.