Openswan + Kernel 2.4.27 + Woody

[sascha26]

Hallo,

ich wollte mal anfangen ein VPN aufzubauen, aussehen soll es so:

Code: Alles auswählen

W2k-Rechner  ---> Internet ----> Linux-Gateway -----> Lan

W2k-Rechner: dyn IP's
Linux: 
  DSL: dyn. IP
 LanIP: 192.168.1.1 
 Subnet: 192.168.1.x/24

Ich will mich also von ausserhalb auf den VPN-Server verbinden und das Lan nutzen ! Ich denke mal da kommt das mit Roadwarrior ins Spiel ?!?! Allerdings bleib ich eigentlich schon ziemlich früh "hängen" !! Vorgegangen bin ich bis jetzt mit diesem beiden Links:

http://www.debianforum.de/forum/viewtop ... t=openswan
http://www.natecarlson.com/linux/ipsec-x509.php

[ipsec.conf ]

Code: Alles auswählen

version 2.0

config setup
        interfaces="ipsec0=eth0"
        virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16

conn %default
        keyingtries=1
        compress=yes
        authby=rsasig
        leftrsasigkey=%cert
        rightrsasigkey=%cert

conn roadwarrior-net
        leftsubnet=192.168.1.0/24
        also=roadwarrior

conn roadwarrior
        left=192.168.1.1
        leftcert=test.pem
        right=%any
        rightsubnet=vhost:%no,%priv
        auto=add

include /etc/ipsec.d/policies/no_oe.conf

Das erste Probelm ist sobald ich die %defaultroute setze meine Routing nicht mehr stimmt und das Internet weg ist ( also der VPN-Server dient auch als Router ) !

Benutze ich die Konfigurationsdatei so wie Sie hier steht...sieht der Start von ipsec gut aus ( laut ipsec barf )..

[ipsec barf]

Code: Alles auswählen

Sep 12 17:25:08 server ipsec__plutorun: Starting Pluto subsystem...
Sep 12 17:25:09 server pluto[25463]: Starting Pluto (Openswan Version 2.1.5 X.509-1.4.8-1 PLUTO_USES_KEYRR)
Sep 12 17:25:09 server pluto[25463]:   including NAT-Traversal patch (Version 0.6c)
Sep 12 17:25:09 server pluto[25463]: Using KLIPS IPsec interface code
Sep 12 17:25:09 server pluto[25463]: Changing to directory '/etc/ipsec.d/cacerts'
Sep 12 17:25:10 server pluto[25463]:   loaded cacert file 'cacert.pem' (1196 bytes)
Sep 12 17:25:10 server pluto[25463]: Changing to directory '/etc/ipsec.d/crls'
Sep 12 17:25:10 server pluto[25463]:   loaded crl file 'crl.pem' (487 bytes)
Sep 12 17:25:11 server pluto[25463]:   loaded host cert file '/etc/ipsec.d/certs/test.pem' (3490 bytes)
Sep 12 17:25:12 server pluto[25463]: added connection description "roadwarrior-net"
Sep 12 17:25:13 server pluto[25463]:   loaded host cert file '/etc/ipsec.d/certs/test.pem' (3490 bytes)
Sep 12 17:25:13 server pluto[25463]: added connection description "roadwarrior"
Sep 12 17:25:13 server pluto[25463]: attempt to redefine connection "roadwarrior"
Sep 12 17:25:13 server pluto[25463]: listening for IKE messages
Sep 12 17:25:13 server pluto[25463]: NAT-Traversal: ESPINUDP(1) not supported by kernel -- NAT-T disabled
Sep 12 17:25:13 server pluto[25463]: adding interface ipsec0/eth0 192.168.1.1
Sep 12 17:25:13 server pluto[25463]: NAT-Traversal: ESPINUDP(2) not supported by kernel -- NAT-T disabled
Sep 12 17:25:13 server pluto[25463]: adding interface ipsec0/eth0 192.168.1.1:4500
Sep 12 17:25:13 server pluto[25463]: loading secrets from "/etc/ipsec.secrets"
Sep 12 17:25:13 server pluto[25463]:   loaded private key file '/etc/ipsec.d/private/test.key' (1639 bytes)

Allerdings krieg ich dann per ipsec auto --up roadwarrior die Verbindung nicht gesetzt ( 029 "roadwarrior": cannot initiate connection without knowing peer IP address (kind=CK_TEMPLATE) )

Komm da echt nicht weiter..hab ich da ein grundsätzliches Problem mit dem Szenario..oder irgedeinen Config-Fehler ???

gruss

[mistersixt]

Allerdings krieg ich dann per ipsec auto --up roadwarrior die Verbindung nicht gesetzt ( 029 "roadwarrior": cannot initiate connection without knowing peer IP address (kind=CK_TEMPLATE) )

Willkommen im Debianforum!

Woher soll das Linux-GW wissen, welche IP Dein Roadwarrior hat? "ipsec auto --up blabla" geht nur dann, wenn Du die IP der Gegenseite weisst. Mehr als "ipsec auto --add blabla" geht in Deinem Fall nicht. Da Du sogar 2 dyn. IP-Adressen hast, ist das nicht so trivial. Dein Linux-GW sollte zumindest eine DYNDNS-Adresse haben, so dass Du das Gateway immer mit einem DNS-Namen ansprechen kannst. Die Verbindung solltest Du immer vom Roadwarrior zum VPN-Server machen, also beim VPN-Server immer nur "ipsec auto --add blabla" und beim Roadwarrior dann "ipsec auto --add blabla" und dann "ipsec auto --up blabla". Dann die Logfiles begutachten.

Gruss, mistersixt.

[sascha26]

Also ich bin jetzt mal soweit das bei einem ping folgendes kommt:

C:\vpn>ping 192.168.100.1

Ping wird ausgeführt für 192.168.100.1 mit 32 Bytes

IP-Sicherheit wird verhandelt.
IP-Sicherheit wird verhandelt.
IP-Sicherheit wird verhandelt.
IP-Sicherheit wird verhandelt.

Ping-Statistik für 192.168.100.1:
Pakete: Gesendet = 4, Empfangen = 0, Verloren =
Ca. Zeitangaben in Millisek.:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

Allerdings kommt das nun immer, also erfolgt kein "richtiger" Ping. Wo könnte da noch ein Fehler sein ??

[Luke.S]

ein klassischer Timeout.

Du musst die Verbindunt erst aufgebaut haben, bevor ein ping funktioniert.

ping -t x.x.x.x

[meister_ede]

Bist Du schon weiter gekommen? Ich hab mich vor kurzem auch mit dem heiklen Thema IPSec beschäftigt. Ist nicht ganz leicht und es gibt viele Fehlerquellen. Hab es am ende aber doch geschafft. Wenn Du noch nicht am Ziel bist:

1) Zum Verständnis: Du musst kein ipsec auto ausführen, wenn sich der RW am Gateway einwählt. (nur umgekehrt)

2) wenn du dir das internet abschiest, wenn du ipsec startest, liegt das vielleicht an der opportunistic encryption, die ja alles verschlüsseln will, was den router verlässt. setzt mal die entsprechende disable_oe Zeile direkt nach der 'version 2'-Zeile, bei dir ist die ja ganz unten
was sagt 'route' nachdem Du ipsec gestartet hast?

3) Ich würde erstmal mit PSK authentifizieren. das ist doch erstmal viel weniger fehleranfällig: also authby=secret, in ipsec.secret:
%any <öffentliche_router_ip> : "<geheimnis>"
trag erst mal die momentane IP des Routers hart ein, auch wenn die nach der nächsten einwahl weg ist. ist ja nur zum testen (alles ohne > und <)

4) Hast du im Windows eine Firewall an? Bei XP per default der Fall. Zum Testen komplett deaktivieren.

Gib nicht auf, sondern poste

[sascha26]

Hallölle,

erstmal danke für die Hilfe..also weiter getestet hab ich jetzt noch nicht...auch noch nicht die Tipps hier vom Board...kommt erst alles am WE. Aber eine Fehlermeldung hab in den Logs gefaunden und zwar:

Code: Alles auswählen

but no connection
has been authorized

Also es sieht so aus als ob die Verbindung steht..zumindest sehe ich beide IP`s die was austauschen wollen..allerdings kommt dann die o.g. Fehlermeldung..vll. sagt das ja jmd was ?!?


gruss und danke

[meister_ede]

conn roadwarrior
left=192.168.1.1

hier muss die öffentliche IP des Routers stehen, wenn %defaultroute nicht funktioniert (was schon sehr seltsam ist).

[sascha26]

Nabend,

also ich hab mal noch en bissi weiter getestet komm aber über diese Fehlermeldung "but no connection has been authorized" nicht raus. Hier mal meine aktuellen Config-Dateien:

ipsec.conf / Gateway

Code: Alles auswählen

version 2.0

config setup
        interfaces=%defaultroute
        klipsdebug=all
        plutodebug=all

conn %default
        keyingtries=1
        compress=yes
        authby=rsasig
        leftrsasigkey=%cert
        rightrsasigkey=%cert

conn roadwarrior
        left=%defaultroute
        leftsubnet=192.168.100.0/24
        leftcert=gate.pem
        right=%any
        auto=add
        pfs=yes

include /etc/ipsec.d/policies/no_oe.conf

Trotz "%defaultroute" bleibt jetzt wenigstens mal meine Internetverbindung bestehen !

ipsec.conf / roadwarrior

Code: Alles auswählen

conn roadwarrior
 left=%any
 right=my.dyndns.org
 rightsubnet=192.168.100.0/24 
 rightca="C=DE,S=test,L=testhausen,O=vpn-home,OU=IT,CN=test,Email=test@gmx.de"
 network=auto
 auto=start
 pfs=yes

So ganz weiss ich im Moment nicht was ich noch probieren soll / kann !!!

gruss

[meister_ede]

Ich empfehle zum Testen wirklich erstmal nur mit PSK zu authentifizieren. Wie oben gesagt:
Gateway:

in ipsec.conf authby=secret, in ipsec.secret:
%any <öffentliche_router_ip> : "<geheimnis>"
trag erst mal die momentane IP des Routers hart ein, auch wenn die nach der nächsten einwahl weg ist. ist ja nur zum testen (alles ohne > und <)

RW:

Code: Alles auswählen

conn roadwarrior
      left=%any
      right=my.dyn.org

      rightsubnet=192.168.100.0/24
      presharedkey="<geheimnis>"
      network=ras
      auto=start
      pfs=yes

bin mal gespannt ob das klappt. Und denk an die Win-Firewalls, falls Du eine hast.

[sascha26]

Hi,

also ich hab das jetzt mal mit den geänderten Einstellungen von Arbeit aus probiert funzt aber weiterhin nicht..bekomme keinen Ping. Jetzt kann jetzt natürlich hier am Netzwerk liegen. Muss ich hier noch nen Eintrag beim roadwarrior machen wenn auf Arbeit auch noch en Router dazwischen ist ?? Von zu hause is das ganze halt schlecht zu testen..es sei den im internen Netzwerk oder ?!

gruss

[meister_ede]

Zum einen wird die Firewall auf der Arbeit sicherlich VPN Traffic blocken. Zum anderen unterstützt Dein VPN-Gateway kein NAT-T (kann man in Deinem Log oben sehen). NAT-Traversal (=NAT-T) kann eingesetzt werden, wenn einer der VPN-Partner genattet ist und das ist bei Dir, wenn Du auf der Arbei bist, der Fall. Du hast die entsprechende Unterstützung nicht mit in den Kernel kompiliert (wenn man OpenSWAN installiert, patcht man die Kernel-Quellen).
In der README der OpenSwan-Quellen steht

make nattpatch | (cd /usr/src/linux-2.4 && patch -p1 && make bzImage)

Ich rate aber auch hier erst mal eine VPN-Einwahl über eine direkte Internetverbindung aufzubauen, so das NAT-T nicht zum einsatz kommt. Im LAN testen geht in die hose, wenn Du Deine Konfigdateien nicht umkrempelst.

[sascha26]

Zum einen wird die Firewall auf der Arbeit sicherlich VPN Traffic blocken. Zum anderen unterstützt Dein VPN-Gateway kein NAT-T (kann man in Deinem Log oben sehen). NAT-Traversal (=NAT-T) kann eingesetzt werden, wenn einer der VPN-Partner genattet ist und das ist bei Dir, wenn Du auf der Arbei bist, der Fall. Du hast die entsprechende Unterstützung nicht mit in den Kernel kompiliert (wenn man OpenSWAN installiert, patcht man die Kernel-Quellen).
In der README der OpenSwan-Quellen steht

make nattpatch | (cd /usr/src/linux-2.4 && patch -p1 && make bzImage)

Ich rate aber auch hier erst mal eine VPN-Einwahl über eine direkte Internetverbindung aufzubauen, so das NAT-T nicht zum einsatz kommt. Im LAN testen geht in die hose, wenn Du Deine Konfigdateien nicht umkrempelst.

Moin,

also den Patch hab ich eingespielt wenn ich mich jetzt nicht stark irre ! Aber werd mir mal en "Opfer" suchen mit dem ich das ganze mal testen kann mit einer direkt Internetverbindung! Aber langsam glaub ich das ganze wird nie funktionieren Trotzdem schonmal riesen Dank für deine Hilfe und Geduld

gruss

[Dono]

Hallo!
Ich stecke auch fest. Ich bekomme eine SA aber immer "IP-Sicherheit wird verhandelt".
Gibts was neues dazu?

[gucki]

Hallo!
Ich stecke auch fest. Ich bekomme eine SA aber immer "IP-Sicherheit wird verhandelt".
Gibts was neues dazu?

sowas ähnliches hatte ich auch mal. Hab mir damals nen Wolf gesucht. Die Symtome waren folgende:

- Linuxbox hat so getan als ab alles okay war "SA esteblished" usw.
- Win2K wollte keine Verbindung aushandeln

Bei mir lags damals daran das die Serien-Nr des Root-Zertifaktes 0 war und auch das Rechnerzertifikat für die W2K Kiste die gleiche Serien-Nr. hatte. Ansonsten kuck mal ins Ereignisprotokoll deiner Windowskiste.

Gruß Gucki

[sascha26]

Hallo,

also mit PSK funktioniert das ganze nun von Arbeit aus. Musste in der ipsec.conf auf dem Gateway folgende Einträge hizufügen:

Code: Alles auswählen

config setup 
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16

conn roadwarrior
rightsubnet=vhost:%no,%priv

Als nächstes sind nu die Zertifikate dranne

gruss