FreeS/Wan 2.04 / Win / Schlüsselübergabe Problem

[mc_gyver]

Guten Abend,

ich hätte da mal ein kleines Problem mit einem FreeS/Wan-Server und einem Win-XP-Clienten.
Und komme einfach nicht wirklich weiter.
Eigentlich wollte ich nur mein WLAN sicherer machen udn es mit Zertifikaten verschlüsseln.
Ich habe folge Testumgebung im LAN:

Einen Debian Woody FreeS/Wan-2.04 Server, mit gepatchtem 2.4.26 Kernel.
-> IP 192.168.23.254
-> Subnetmask 255.255.255.0

Und einen WIN-XP Clienten mit dem Tool von http://vpn.ebootis.de/
-> IP 192.168.23.5
-> Subnetmask 255.255.255.0

Ich wollte Testweise nur für diese Verbindung einen VPN-Tunnel bauen um im Erfolgsfall jeglichen
Datentransfer der Wireless-Funker zu verschlüsseln.
Tja also habe ich den Kernel gepatched mit Freeswan, Zertifikate erstellt
->RootCA = rootcert
->eines für Debian (Server) = lxcert
->und eines für den WinXp = bagnbcert

die ipsec.secrets Datei angepassed und schlussendlich die ipsec.conf editiert -> siehe Anhang.
Soweit so gut! "ipsec barf" bringt beim starten von ipsec auch keine Fehler. Das Zertifikat ist auch auf Windows übertragen.
Wenn ich nun aber von WinXP einen Tunnel starten möchte, d.h. das VPN mit dem Tool von Marcus Müller an mache
und den Server (192.168.23.254) anpinge. Kommt auf Windows Seite IP-sicherheit wird verhandelt, eigentlich sollte
dies ja weggehen nach einer Weile tut es aber nicht.
Ein NetworkSniffer zeigt regen Verkehr mit ISAKMP Protokollen.
Auf der Linux Seite gibt ipsec abrf nun folgendes aus:

Code: Alles auswählen

 packet from 192.168.23.5:500: received Vendor ID Payload; ASCII hash: 
                                                  \036+Qi\005\031\034}|\026|?5\007da
 "wlan" #1: responding to Main Mode
 "wlan" #1: Peer ID is ID_DER_ASN1_DN: 'C=DE, ST=Berlin, L=Berlin, O=GNET,   
                                CN=bagnbcert, E=bagnb@lx.org'
 "wlan" #1: sent MR3, ISAKMP SA established
 "wlan" #1: cannot respond to IPsec SA request because no connection is known for 
         192.168.23.254[C=DE, ST=Berlin, L=Berlin, O=GNET, CN=lxcert, E=lx@lx.org]...
         192.168.23.5[C=DE, ST=Berlin, L=Berlin, O=GNET, CN=bagnbcert, E=bagnb@lx.org]
 "wlan" #1: no Phase1 state for Quick mode notification
 "wlan" #1: Quick Mode I1 message is unacceptable because it uses a previously used 
                Message ID 0x60aeca84 (perhaps this is a duplicated packet)
 "wlan" #1: sending encrypted notification INVALID_MESSAGE_ID to 192.168.23.5:500

Ein tcpdump -i ipsec0 zeigt keinerlei packete an.

Und ipsec auto status zeigt folgendes:

Code: Alles auswählen

interface ipsec0/eth0 192.168.23.254
%myid = (none)
debug none
"wlan": 255.255.255.0/24===192.168.23.254[C=DE, ST=Berlin, L=Berlin, O=GNET, CN=lxcert, E=lx@lx.org]...192.168.23.5[C=DE, ST=Berlin, L=Berlin, O=GNET, CN=bagnbcert, E=bagnb@lx.org]===255.255.255.0/24; unrouted; eroute owner: #0
"wlan":   CAs: 'C=DE, ST=Berlin, L=Berlin, O=GNET, CN=rootcert, E=root@lx.org'...'C=DE, ST=Berlin, L=Berlin, O=GNET, CN=rootcert, E=root@lx.org'
"wlan":   ike_life: 3600s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 1
"wlan":   policy: RSASIG+ENCRYPT+COMPRESS+TUNNEL+PFS; prio: 24,24; interface: eth0; 
"wlan":   newest ISAKMP SA: #1; newest IPsec SA: #0; 
"wlan":   IKE algorithms wanted: 5_000-1-5, 5_000-2-5, 5_000-1-2, 5_000-2-2, flags=-strict
"wlan":   IKE algorithms found:  5_192-1_128-5, 5_192-2_160-5, 5_192-1_128-2, 5_192-2_160-2, 
"wlan":   IKE algorithm newest: 3DES_CBC_192-SHA-MODP1024
"wlan":   ESP algorithms wanted: 3_000-1, 3_000-2, flags=-strict
"wlan":   ESP algorithms loaded: 3_168-1_128, 3_168-2_160, 
#1: "wlan" STATE_MAIN_R3 (sent MR3, ISAKMP SA established); EVENT_SA_REPLACE in 3196s; newest ISAKMP

Hat von euch jemand eine Idee an was das legen könnte?
Danke im vorraus für eure Mühe! THX



Anhang:

ipsec.conf -> auf dem Debian FreeS/Wan2.04 Server


config setup
interfaces="ipsec0=eth0"
uniqueids=yes

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

conn wlan
right=192.168.23.5
rightsubnet=255.255.255.0/24
rightid="C=DE, ST=Berlin, L=Berlin, O=GNET, CN=bagnbcert, E=bagnb@.org"
rightcert=bagnb.pem
left=192.168.23.254
leftsubnet=255.255.255.0/24
leftcert=lxcert.pem
leftid="C=DE, ST=Berlin, L=Berlin, O=GNET, CN=lxcert, E=lx@lx.org"
auto=add

conn block
auto=ignore
conn private
auto=ignore
conn private-or-clear
auto=ignore
conn clear-or-private
auto=ignore
conn clear
auto=ignore
conn packetdefault
auto=ignore


ipsec.conf -> auf dem WinXP-Client

conn wlan
left=192.168.23.5
right=192.168.23.254
rightca="C=DE, S=Berlin, L=Berlin, O=GNET, CN=rootcert, E=root@lx.org"
network=auto
auto=start
pfs=yes

[mistersixt]

Kurze Frage: in der conn wlan vom Debian-Rechner steht da:

Code: Alles auswählen

...
 rightid="C=DE, ST=Berlin, L=Berlin, O=GNET, CN=bagnbcert, E=bagnb@.org"
...

Fehlt am Ende nicht das lx von lx.org?

Gruss, mistersixt.

[mc_gyver]

wie peinlich!
Muss irgendwie bei den vielen Tests abhanden gekommen sein.
An der Fehlermeldung ändert sich aber nix, wenn ich die richtige rightid eintrage!

Was mir noch aufgefallen ist, ist das ipsec verify
folgendes anzeigt:

Code: Alles auswählen

Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path                                         [OK]
Linux FreeS/WAN 2.04
Checking for KLIPS support in kernel                                    [OK]
Checking for RSA private key (/etc/ipsec.secrets)                       [FAILED]
ipsec showhostkey: no default key in "/etc/ipsec.secrets"
Checking that pluto is running                                          [OK]
Two or more interfaces found, checking IP forwarding                    [OK]
Checking NAT and MASQUERADEing

Opportunistic Encryption DNS checks:
Looking for TXT in forward map: lx                                 [MISSING]
Does the machine have at least one non-private address?  [FAILED]

Kann es evt. an den .pem Dateien der zertifikate liegen? Bei den meisten HowTos mussten diese in das /ipsec.d/ Verzeichniss. Hatte ich sie aber dort mekerte Pluto rum das er das cert file nicht fand also habe ich die .pem-dateien in das /ipsec.d/certs/ Verzeichniss kopiert. Dann mekert pluto nicht mehr, aber ein VPN habe ich dadurch immer noch nicht .
Danke dir mister sixt für deine mühen.

[lobo]

Ich würde sagen, deine left-/rightsubnet parameter sind falsch.

Probier mal:
(sofern die Rechner im gleichen Netz liegen)

leftsubnet=192.168.23.0/24
rightsubnet=192.168.23.0/24

Ein Tip von mir wäre, OpenSWAN zu verwenden, da die Entwicklung von FreeSWAN soweit ich weiß sein Ende genommen hat. OpenSWAN hat auch schon alle wichtigen Patches wie x509 Zertifikate und NAT-T integriert.

Hier ist noch so ziemlich die beste Anleitung für ein VPN mit x509 Zertifikaten zwischen Linux und Windows Maschinen:
http://www.natecarlson.com/linux/ipsec-x509.php

Am besten aktivierst du unter Windows auch den Oakley Log.

Gruss

Jochen

[mc_gyver]

Es scheint irgendwas mit den subnet Parametern zu tun haben.

Wenn ich auf dem Clienten und auf dem Server die rightsubnet & die leftsubnet auf 192.168.23.0/24 dann bekomme ich bei Windows ein-zwei mal IP-Sicherheit wird verhandelt und dann einen erfolgreichen ping. Danach geht leider gar nichts mehr im ganzen Netzwerk. Ich kann vom ganzen Netzwerk den Server (192.168.23.254) nicht mehr anpingen. Auch wenn ich freeswan stoppe, komme ich nicht auf den Server, es hilf hier nur ein Neustart des Systems.

Wenn ich irgendwo keine right oder leftsubnet angebe kommt der gleiche Fehler wie vorher.

Was dein Tipp betrifft mit dem Openswan, würde ich dies gerne versuchen, gibt es ein ein backport für Woody? Und muss ich Freeswan wieder deinstallieren?
Erstmal Herzlichen Dank für die Anregungen, einen Schritt bin ich nun weiter, .

[mistersixt]

Das Gute an OpenSwan ist vor allen Dingen, dass das sofort mit Kernel-2.6 läuft, da muss man nix mehr patchen und keinen Kernel selber compilieren. Einfach einen Debian-2.6er-Kernel nehmen und die Userland-Tools installieren ("apt-get install openswan ipsec-tools" --> bei sarge und sid ist es dabei, einen Backport für Woody habe ich spontan nicht gefunden), die Config-Files können fast identisch von FreeSwan übernommen werden.

Gruss, mistersixt.

[lobo]

Es scheint irgendwas mit den subnet Parametern zu tun haben.

Wenn ich auf dem Clienten und auf dem Server die rightsubnet & die leftsubnet auf 192.168.23.0/24 dann bekomme ich bei Windows ein-zwei mal IP-Sicherheit wird verhandelt und dann einen erfolgreichen ping. Danach geht leider gar nichts mehr im ganzen Netzwerk. Ich kann vom ganzen Netzwerk den Server (192.168.23.254) nicht mehr anpingen. Auch wenn ich freeswan stoppe, komme ich nicht auf den Server, es hilf hier nur ein Neustart des Systems.

Wenn sich die Rechner im gleichen Netz befinden, wirst du für den Tunnel eine andere Subnetmask nehmen müssen. Dass nachher nichts mehr funktioniert ist logisch, da das Betriebssystem versucht alle Pakete die auf den left-/rightsubnet Bereich passen durch den Tunnel zu schicken.
Neustart ist keine kluge Lösung, schon mal "ipsec -delete" probiert Und wenn gar nichts hilft einfach den IPSec Dienst neustarten.

Du könntest mal 192.168.23.0/30 als left-/rightsubnet nehmen und den beiden Rechner die miteinander kommunizieren sollen, die IPs 192.168.23.253 und 192.168.23.254 geben, falls das möglich ist (hoffentlich hab ich richtig gerechnet, sonst wirds peinlich ).

...
Was dein Tipp betrifft mit dem Openswan, würde ich dies gerne versuchen, gibt es ein ein backport für Woody? Und muss ich Freeswan wieder deinstallieren?
Erstmal Herzlichen Dank für die Anregungen, einen Schritt bin ich nun weiter, .

Für Woody gibt es leider noch keinen Backport, aber ich werde vielleicht einen machen wenn ich Zeit finde. Ansonsten nimmst du einfach einen 2.6er Kernel mit IPSec Unterstützung wie mistersixt schon geschrieben hat oder kompillierst dir einen eigenen 2.4.x Kernel mit OpenSWAN Patches. Die Userland Tools lassen sich auch recht einfach mit "make programs && make install" nach /usr/local installieren.

Gruss

Jochen

[mc_gyver]

Neustart ist keine kluge Lösung, schon mal "ipsec -delete" probiert Und wenn gar nichts hilft einfach den IPSec Dienst neustarten.

Also ipsec -delete auf Linux kennt er nicht, unter Windows hilft es nicht, und ipsec neustarten oder beenden hilf auch nicht. Ich kann den Server (192.168.23.254) nicht mehr anpingen.

Du könntest mal 192.168.23.0/30 als left-/rightsubnet nehmen und den beiden Rechner die miteinander kommunizieren sollen, die IPs 192.168.23.253 und 192.168.23.254 geben, falls das möglich ist (hoffentlich hab ich richtig gerechnet, sonst wirds peinlich ).

Hab ich gemacht: Notebook war 192.168.23.253 und alle subnets waren auf 192.168.23.0/30. hat leider nichts geholfen, er hat keinen Tunnel aufgebaut, er hat nicht einmal IP-Sicherheit wird verhandelt angezeigt.

Ist den mein Vorhaben überhaupt möglich? Ich muss doch den Transfer im LAN verschlüsseln können, oder nicht? Wie müsste den so ein Lan aufgebaut sein?

Für Woody gibt es leider noch keinen Backport, aber ich werde vielleicht einen machen wenn ich Zeit finde. Ansonsten nimmst du einfach einen 2.6er Kernel mit IPSec Unterstützung wie mistersixt schon geschrieben hat oder kompillierst dir einen eigenen 2.4.x Kernel mit OpenSWAN Patches. Die Userland Tools lassen sich auch recht einfach mit "make programs && make install" nach /usr/local installieren.

Also bräuchte ich schon Sarge für OpenSWAN ! Oh je habt ihr gute Erfahrungen mit einem dist-upgrade gemacht *g*?

[mistersixt]

Im Prinzip sollte das kein Problem sein, ich habe das schon ein paar Dutzend mal von Woody auf Sarge oder Sid gemacht. Wo jedoch viele Leute auf die Nase fallen, ist die Tatsache, dass der Kernel 2.4.18-bf24 von Debian-Woody ein paar Netzwerkkartenmodule direkt im Kernel einkompiliert hat. Wenn man nun einen neuen Debian-Kernel installiert (2.4.26 oder 2.6.7 momentan), dann funzt das Netz nach dem Upgrade nur dann, wenn man den passenden Netzwerkkartentreiber in /etc/modules einträgt, weil diese Kernel keine Netzwerkkartenmodule mehr direkt einkompiliert haben.

Ich hoffe, das war verständlich !

Gruss, mistersixt.

[gucki]

Neustart ist keine kluge Lösung, schon mal "ipsec -delete" probiert Und wenn gar nichts hilft einfach den IPSec Dienst neustarten.

Also ipsec -delete auf Linux kennt er nicht, unter Windows hilft es nicht, und ipsec neustarten oder beenden hilf auch nicht. Ich kann den Server (192.168.23.254) nicht mehr anpingen.

Du musst auf beiden Seiten den Tunnel beenden. IPSEC-Dienst auf der Linuxkiste beenden und auch auf der Windowskiste mit

Code: Alles auswählen

ipsec -delete

beenden (Auch das ebootis-Tool kennt diese Option. Wenn das nicht hilft über das Programm MMC mit dem "IP Sicherheit"s-Plugin manuell ausschalten.

[gucki]

Es scheint irgendwas mit den subnet Parametern zu tun haben.

Wenn ich auf dem Clienten und auf dem Server die rightsubnet & die leftsubnet auf 192.168.23.0/24 dann bekomme ich bei Windows ein-zwei mal IP-Sicherheit wird verhandelt und dann einen erfolgreichen ping. Danach geht leider gar nichts mehr im ganzen Netzwerk. Ich kann vom ganzen Netzwerk den Server (192.168.23.254) nicht mehr anpingen. Auch wenn ich freeswan stoppe, komme ich nicht auf den Server, es hilf hier nur ein Neustart des Systems.

Wenn ich irgendwo keine right oder leftsubnet angebe kommt der gleiche Fehler wie vorher.

Was dein Tipp betrifft mit dem Openswan, würde ich dies gerne versuchen, gibt es ein ein backport für Woody? Und muss ich Freeswan wieder deinstallieren?
Erstmal Herzlichen Dank für die Anregungen, einen Schritt bin ich nun weiter, .

Du musst eine Punkt-zu-Punkt Verbindung aufbauen. Bei mir klappt das mit folgenden Configs:

Windowskiste:

Code: Alles auswählen

conn firewall1
    left=192.168.171.5
    leftsubnet=192.168.171.5/32
    right=192.168.171.2
    rightsubnet=192.168.171.2/32
    authby=rsasig
    rightca="C=DE, S=xxx, L=xxx, O=xxx, CN=xxx Root Cert CA"
    network=lan
    auto=start
    pfs=yes

Auf der Windowskiste ist es wichtig das das Rootzertifikat angegeben ist. Die richtige Bezeichnung holt man sich am besten über das Programm mmc "IP-Sicherheit"s-Plugin.

Linux-Kiste:

Code: Alles auswählen

# basic configuration
config setup
        # THIS SETTING MUST BE CORRECT or almost nothing will work;
        # %defaultroute is okay for most simple cases.
        interfaces=ipsec0=eth0
        # Debug-logging controls:  "none" for (almost) none, "all" for lots.
        klipsdebug=none
        plutodebug=none
        # Use auto= parameters in conn descriptions to control startup actions.
        # plutoload=%search
        # plutostart=%search
        # Close down old connection when new one using same ID shows up.
        uniqueids=yes
        #
        forwardcontrol=yes
        # disablearrivalcheck=no

# für lokal test
conn lokal
    authby=rsasig
    keyingtries=10
    auth=esp
    leftcert=localhost-cert.pem
    leftrsasigkey=%cert
    left=192.168.171.2
    leftsubnet=192.168.171.2/32
    leftnexthop=%direct
    right=%any
    rightcert=host_windows_cert.pem
    rightrsasigkey=%cert
    pfs=yes
    auto=add

[mc_gyver]

@ gucki: Danke die VPN Verbindung steht. Der Tipp mit dem Subnet (/32) hat funktioniert!
tcpdump -i ipsec0 zeigt regen Traffic an, und auch der Netzwerkscanner zeigt Traffic über ESP an. Warum gehen aber noch UDP und TCP Verbindungen raus?
Kannst du eigentlich Rechner hinter dem Server erreichen? Ich komme nur auf den Server, aber das liegt wohl an NAT.
Danke schön für deine Hilfe.

@mistersixt:
also habe ir das dist-upgrade mal angeschaut, aber er will auch unter anderem xfree86-common und andere Programme die ich gar nicht will als neuinstallieren. Ich brauche überheupt keinen X-Server. Warum will Debian dies neu hinzu installieren?
Und noch eine Frage zum Abschluss kann ich die alten Kernel-Configs von Kernel 2.4.26 auch für Kernel 2.6.x nehmen und mit make oldconfig das wichtigste übernehmen, oder muss ich komplett neu alles eintragen was ich in meinem Kernel haben möchte?

[gucki]

@ gucki: Danke die VPN Verbindung steht. Der Tipp mit dem Subnet (/32) hat funktioniert!
tcpdump -i ipsec0 zeigt regen Traffic an, und auch der Netzwerkscanner zeigt Traffic über ESP an. Warum gehen aber noch UDP und TCP Verbindungen raus?
Kannst du eigentlich Rechner hinter dem Server erreichen? Ich komme nur auf den Server, aber das liegt wohl an NAT.
Danke schön für deine Hilfe.

Mein Windowsrechner als auch die Linuxkiste sind im gleichen Subnetz, somit ist da nur nee Punkt zu Punkt Verbindung sinnvoll (/32).

Hab aber den Zugriff von aussen hab ich mal gemacht:

Windowsrechner:

Code: Alles auswählen

conn roadworrior

	left=192.168.0.7
	right=guckis.dyna.ip
	rightsubnet=192.168.171.0/24
	authby=rsasig
	rightca="C=DE, S=xxx, L=xxx, O=xxx, CN=xxx Root Cert CA"
	network=lan
	auto=start
	pfs=yes

Linux-Kiste:

Code: Alles auswählen

config setup
        # sonst alles gleich wie bei der config für lokal
        interfaces="%defaultroute"

conn roadworrior
    authby=rsasig
    keyingtries=10
    auth=esp
    leftcert=localhost-cert.pem
    leftrsasigkey=%cert
    left=guckis.dyna.ip
    right=%any
    rightsubnet=192.168.0.7/32
    rightfirewall=yes
    rightnexthop=%defaultroute
    rightcert=host_roadworrior_pc1_cert.pem
    rightrsasigkey=%cert
    pfs=yes
    auto=add

192.168.171.0/24 ist mein Netz. 192.168.0.7 ist die lokal IP eines Freundes hinter einem DSL-Router. Der Tunnel wird zwischen meiner Linuxkiste und seinem Rechner aufgebaut. Er kann aber alle Rechner in meinem Netzwerk erreichen.

Gruß Gucki