PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : IPSec Wlan VPN



luckyduck
06.01.04, 00:00
Hallo,
nachdem ich nun die meisten Probleme z.T. selber und den größten Teil mit Hilfe von Google und dem Forum hier lösen konnte hänge ich nun fest. Ich habe in meinem Router eine Wlankarte mit prism2 Chipsatz. Der Router fungiert dank Hostap als Accesspoint. Die WEP Verschlüsselung habe ich beim einrichten des VPNs abgeschaltet. Ein Paketfilter ist ebenfalls "nicht an" und alle Policy's stehen hier auf ACCEPT da ich zunächst sicher sein wollte das das VPN "steht" bevor ich da herangehe. Das Wlan ansich funktioniert wunderbar, d.h. ich kann im ganzen Netz Rechner anpingen und bspw. im Internet surfen. Auf dem Router sowie auf den Clients läuft Gentoo. Der Netzwerkaufbau sieht in etwa so aus:

luckyduck-home.png (http://the-luckyduck.de/luckyduck-home.png)

Mein Plan war es jeglichen Traffic der über das Wlan übertragen wird zu verschlüsseln.


hier die ipsec.conf 's:


router (192.168.200.1):
#############################
version 2

config setup
interfaces="ipsec0=wlan0"
klipsdebug=none
plutodebug=none
uniqueids=yes

conn wavelan
# general options
type=tunnel
keyexchange=ike
keylife=900s
ikelifetime=1200s
keyingtries=5
pfs=yes
rekeymargin=150s
rekeyfuzz=25%
auto=add
# local options
left=192.168.200.1
leftsubnet=0.0.0.0/0 leftid="/C=DE/ST=NRW/L=Schlangen/O=luckyduck.tux/OU=NOC/CN=kerberos/emailAddress=lucky@the-luckyduck.de"
leftrsasigkey=%cert
leftcert=kerberos.pem

# remote options
right=192.168.200.135
rightsubnet=192.168.200.135/32 rightid="/C=DE/ST=NRW/L=Schlangen/O=luckyduck.tux/OU=NOC/CN=nepomuk/emailAddress=lucky@the-luckyduck.de"
rightrsasigkey=%cert
rightcert=nepomuk.pem

# disable OE
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
#############################



1. roadwarrior (192.168.200.135)
#############################
version 2

config setup
interfaces="ipsec0=wlan0"
klipsdebug=none
plutodebug=none

conn wavelan
# generell options
auto=add
type=tunnel
keyexchange=ike
keylife=900s
ikelifetime=1200s
keyingtries=5
pfs=yes
rekeymargin=150s
rekeyfuzz=25%

# local options
left=192.168.200.135 leftid="/C=DE/ST=NRW/L=Schlangen/O=luckyduck.tux/OU=NOC/CN=nepomuk/email
Address=lucky@the-luckyduck.de"
leftrsasigkey=%cert
leftcert=nepomuk.pem

# remote options
right=192.168.200.1
rightsubnet=0.0.0.0/0 rightid="/C=DE/ST=NRW/L=Schlangen/O=luckyduck.tux/OU=NOC/CN=kerberos/ema
ilAddress=lucky@the-luckyduck.de"
rightrsasigkey=%cert
rightcert=kerberos.pem

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
#############################


Wenn ich nun per "ipsec auto --up wavelan" auf dem Client eine Verbindung initiiere wird diese auch erfolgreich aufgebaut:

104 "wavelan" #1: STATE_MAIN_I1: initiate
106 "wavelan" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "wavelan" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "wavelan" #1: STATE_MAIN_I4: ISAKMP SA established
112 "wavelan" #2: STATE_QUICK_I1: initiate
004 "wavelan" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xd1be63b6 <0x821257f5}

Versuche ich nun einen Rechner hinter dem Router anzupingen, entweder im Subnet 10.0.0.0/8, 192.168.0.0/24 oder im Internet kommt bei einem "tcpdump -n -i wlan0" auf dem router nur folgendes zutage:

23:05:15.320925 192.168.200.135 > 192.168.200.1: ESP(spi=0xd1be63b6,seq=0x1)
23:05:16.331945 192.168.200.135 > 192.168.200.1: ESP(spi=0xd1be63b6,seq=0x2)
23:05:17.332173 192.168.200.135 > 192.168.200.1: ESP(spi=0xd1be63b6,seq=0x3)

Es werden scheinbar alle Pakete verworfen die an wlan0 bzw ipsec0 ankommen oder besser sie werden nicht zugestellt. Ein simples "route" auf dem router liefert folgende Ausgabe:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0
192.168.200.0 * 255.255.255.0 U 0 0 0 wlan0
192.168.200.0 * 255.255.255.0 U 0 0 0 ipsec0
ripe-ncc-net.ri * 255.0.0.0 U 0 0 0 ippp0
10.0.0.0 * 255.0.0.0 U 0 0 0 eth1
loopback localhost 255.0.0.0 UG 0 0 0 lo
default 193.158.139.113 0.0.0.0 UG 0 0 0 ippp0


Ein "ipsec eroute" auf dem Client folgende:

0 192.168.200.135/32:0 -> 0.0.0.0/0:0 => tun0x1002@192.168.200.1:0

Auf dem router kommt keine Ausgabe nach einem "ipsec eroute". Wenn mir hier jemand helfen könnte wäre das echt Klasse.

luckyduck
06.01.04, 05:23
hier vielleicht nochmal eine ergaenzung:

versuche ich von einem rechner aus einem subnet das hinter dem router liegt zu pingen erscheint folgendes bei einem tcpdump:


Bsp: von 10.0.0.2 nach 192.168.200.135:
--------------------------------------
05:15:22.280101 10.0.0.2 > 192.168.200.135: icmp: echo request
05:15:22.282864 192.168.200.135 > 192.168.200.1: ESP(spi=0x31365118,seq=0x18)


ein paket von 10.0.0.2 geht an 10.0.0.10, das ist die ip von dem ethernetdevice im serversubnet. muesste das paket dann von wlan0 am router (192.168.200.1) nicht direkt schon verschluesselt an wlan0 am client (192.168.200.135) weitergeleitet werden ? ich nehme mal an das ganze ist eher ein verstaendniss problem meinerseits, nur leider konnte ich bis jetzt den fehler noch nicht entdecken. "VPN mit Linux" von Ralf. S. habe ich mir bereits bestellt, das kommt aber leider erst in einigen Tagen bei mir an.

luckyduck
06.01.04, 09:20
so, nun habe ich mal klipsdebug auf "all" gesetzt. das alles gehoert zu einem ping paket welches von 192.168.200.135 an 10.0.0.2 gehen soll. Google hat mir auch hier nicht wirklich geholfen :/

Jan 6 08:19:19 kerberos kernel: klips_debug:ipsec_rcv: <<< Info -- skb->dev=wlan0 dev=wlan0
Jan 6 08:19:19 kerberos kernel: klips_debug:ipsec_rcv: assigning packet ownership to virtual device ipsec0 from physical device wlan0.
Jan 6 08:19:19 kerberos kernel: klips_debug: IP: ihl:20 ver:4 tos:0 tlen:136 id:53895 frag_off:0 ttl:64 proto:50 chk:38370 saddr:192.168.200.135 daddr:192.168.200.1
Jan 6 08:19:19 kerberos kernel: klips_debug:ipsec_rcv_decap_once: decap (50) from 192.168.200.135 -> 192.168.200.1
Jan 6 08:19:19 kerberos kernel: klips_debug:ipsec_sa_getbyid: linked entry in ipsec_sa table for hash=192 of SA:esp0x3c72f20c@192.168.200.1 requested.
Jan 6 08:19:19 kerberos kernel: klips_debug:ipsec_sa_getbyid: no entries in ipsec_sa table for hash=192 of SA:esp0x3c72f20c@192.168.200.1.
Jan 6 08:19:19 kerberos kernel: klips_debug:ipsec_rcv: no ipsec_sa for SA:esp0x3c72f20c@192.168.200.1: incoming packet with no SA dropped
Jan 6 08:19:19 kerberos kernel: klips_debug:ipsec_rcv: decap_once failed: -7

cane
06.01.04, 10:55
Welche Freeswan Version nutzt Du?

Einige pres wie freeswan-2.00pre3 sind broken...

mfg
cane

cane
06.01.04, 11:04
Ach so, warum probierst Du das ganze nicht erstmal mit PSKs - also Passwörtern.
Ist viel einfacher...

luckyduck
06.01.04, 12:17
da hatte ich genau das gleiche, ich benutze 2.04 sowohl auf dem router als auch auf dem client.

cane
06.01.04, 12:26
Dann machs nochmal neu mit PSKs und am besten ohne die manuelle Parameterangaben für IKE - nur das nötigste...

cane

luckyduck
06.01.04, 13:31
hat sich nichts getan:

aufbauen kann ich die verbindung ebenfalls, das dauert so nur etwas laenger als mit zertifikaten:

ipsec auto --up wavelan ~
104 "wavelan" #1: STATE_MAIN_I1: initiate
106 "wavelan" #1: STATE_MAIN_I2: sent MI2, expecting MR2
108 "wavelan" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "wavelan" #1: STATE_MAIN_I4: ISAKMP SA established
112 "wavelan" #2: STATE_QUICK_I1: initiate
004 "wavelan" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0xe7c99f13 <0x782d5e66}



# router ipsec.conf:
version 2

config setup
interfaces="ipsec0=wlan0"
klipsdebug=all
plutodebug=all
uniqueids=yes

conn wavelan
# general options
auto=add

# local options
left=192.168.200.1
leftid=@kerberos
leftsubnet=0.0.0.0.0/8
leftrsasigkey=0sAQO...
# remote options
right=192.168.200.135
rightid=@wlan135
rightsubnet=192.168.200.135/32
rightrsasigkey=0sAQPg...
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



# client ipsec.conf

version 2

config setup
interfaces="ipsec0=wlan0"
klipsdebug=none
plutodebug=none

conn wavelan
# generell options
auto=add

# local options
left=192.168.200.135
leftsubnet=192.168.200.135/32
leftid=@wlan135
leftrsasigkey=0sAQPg...
# remote options
right=192.168.200.1
rightid=@kerberos
rightsubnet=10.0.0.0/8
rightrsasigkey=0sAQOmacm...
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


die key's habe ich mal rausgeschnitten, ansonsten hat sich an der ausgabe nichts geaendert:

# ping von wlan135 (192.168.200.135) nach brain (10.0.0.2):
% ping 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.

--- 10.0.0.2 ping statistics ---
17 packets transmitted, 0 received, 100% packet loss, time 16017ms


# tcpdump -i wlan0 (auf dem router)
tcpdump: listening on wlan0
13:26:47.290831 wlan135 > kerberos: ESP(spi=0xe7c99f11,seq=0x2f)
13:26:48.302143 wlan135 > kerberos: ESP(spi=0xe7c99f11,seq=0x30)
13:26:49.302292 wlan135 > kerberos: ESP(spi=0xe7c99f11,seq=0x31)
13:26:50.302618 wlan135 > kerberos: ESP(spi=0xe7c99f11,seq=0x32)


da ist alles beim alten geblieben, auch klipsdebug sieht sehr stark nach der alten ausgabe aus (in den logs auf dem router):

Jan 6 13:27:51 kerberos kernel: klips_debug:ipsec_rcv: <<< Info -- skb->dev=wlan0 dev=wlan0
Jan 6 13:27:51 kerberos kernel: klips_debug:ipsec_rcv: assigning packet ownership to virtual device ipsec0 from physical device wlan0.
Jan 6 13:27:51 kerberos kernel: klips_debug: IP: ihl:20 ver:4 tos:0 tlen:136 id:60488 frag_off:0 ttl:64 proto:50 chk:31777 saddr:192.168.200.135 daddr:192.168.200.1
Jan 6 13:27:51 kerberos kernel: klips_debug:ipsec_rcv_decap_once: decap (50) from 192.168.200.135 -> 192.168.200.1
Jan 6 13:27:51 kerberos kernel: klips_debug:ipsec_sa_getbyid: linked entry in ipsec_sa table for hash=188 of SA:esp0xe7c99f11@192.168.200.1 requested.
Jan 6 13:27:51 kerberos kernel: klips_debug:ipsec_sa_getbyid: no entries in ipsec_sa table for hash=188 of SA:esp0xe7c99f11@192.168.200.1.
Jan 6 13:27:51 kerberos kernel: klips_debug:ipsec_rcv: no ipsec_sa for SA:esp0xe7c99f11@192.168.200.1: incoming packet with no SA dropped
Jan 6 13:27:51 kerberos kernel: klips_debug:ipsec_rcv: decap_once failed: -7



bei google bin ich auch schon auf die broken versionen gestoßen mit den klips_debug meldungen. habe auch mal eine mail an die users-liste geschrieben, mal schauen was da zurueck kommt. ich pers. finde es aber schoener das ganze mit zertifikaten zu verwalten, es kommen ja im endeffekt noch clients hinzu. nur erstmal soll das ganze auf einem laufen. :)

cane
06.01.04, 14:56
Woher soll Freeswan überhaupt wissen wie es authentifizieren soll?
Du hast gar keinen authby=secret bzw. authby=rsasig Eintrag in den confs...

Ich zeige Dir mal meine funktionierende (Win2k -> SuperFreeswan):

config setup #Start Parameter
interfaces="ipsec0=eth1" #IPSEC läuft über eth1
klipsdebug=none #KLIPS debuggt nicht
plutodebug=none #PLUTO debuggt nicht
plutoload=%search #PLUTO öffnet alle Tunnel
plutostart=%search #PLUTO öffnet alle Tunnel
uniqueids=yes #jede IP muß eine eigene ID haben

conn %default #Default Parameter für alle Verbindungen
keyingtries=0 #Anzahl der Verbindungsversuche unendlich
authby=secret #Authentifizierungsmethode Kennwort
compress=no #Kompression deaktiviert
type=tunnel #IPSEC Modus Tunnel

conn roadwarrior
left=192.168.1.1 #die IP des VPN Gateways die als Standart-Gateway auf den VPN-Clients eingetragen ist
leftsubnet=10.10.10.10/24 #Das Subnetz hinter dem CPN-Gateway
pfs=yes #Aktiviere Perfect Forward Secrecy
right=%any #Die Win2000 Clients können beliebige IPs haben
auto=add #Verbindung wird geladen - nicht gestartet

Das isses schon.
Die block Einträge brauchst du natürlich - ich aber nicht...

cane
06.01.04, 15:07
Probier mal:

config setup #Start Parameter
interfaces="ipsec0=wlan0" #IPSEC läuft über wlan0
klipsdebug=none #KLIPS debuggt nicht
plutodebug=none #PLUTO debuggt nicht
plutoload=%search #PLUTO öffnet alle Tunnel
plutostart=%search #PLUTO öffnet alle Tunnel
uniqueids=yes #jede IP muß eine eigene ID haben

conn %default #Default Parameter für alle Verbindungen
keyingtries=0 #Anzahl der Verbindungsversuche unendlich
authby=secret #Authentifizierungsmethode Kennwort
compress=no #Kompression deaktiviert
type=tunnel #IPSEC Modus Tunnel

conn roadwarrior
left=192.168.200.135 #die IP des VPN Gateways die als Standart-Gateway auf den VPN-Clients eingetragen ist
leftsubnet=192.168.200.0/24 #Das Subnetz hinter dem CPN-Gateway
pfs=yes #Aktiviere Perfect Forward Secrecy
right=%any #Die Win2000 Clients können beliebige IPs haben
auto=add #Verbindung wird geladen - nicht gestartet
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

In die ipsec.secrets muß:

192.168.200.135 : PSK "Passwort"ZEILENUMBRUCH

Den Zeilenumbruch (Enter) nicht vergessen!


Auf dem 1. Client genau die selbe ipsec.conf und ipsec.secrets anlegen.
Dann testen.

Viel Glück

PS: Wenns nicht klappt nicht verzweifeln - hab auch ewig gebraucht ;)

Ich gucke gleich nochmal ins Buch wenns nicht klappt :)

mfg
cane

##EDIT##
Achte auch drauf dass die ipsec.conf richtig eingerückt ist!
Alles außer dem fettmarkierten muß einen Tab nach Links!

luckyduck
06.01.04, 15:07
authby=rsasig

hatte ich schonmal drin, ist default wert:

authby how the two security gateways should authenticate each
other; acceptable values are secret for shared secrets,
rsasig for RSA digital signatures (the default),
secret|rsasig for either, and never if negotiation is
never to be attempted or accepted (useful for shunt-only
conns). Digital signatures are superior in every way to
shared secrets.


die config teste ich gleich mal, warum ich kein shared-auth machen moechte:

Can I have many road warriors using shared secret authentication?

Yes, but avoid it if possible.

You can have multiple Road Warriors using shared secret authentication only if they all use the same secret. You must also set:

uniqueids=no

in the connection definition.

Why it's less secure:

* If you have many users, it becomes almost certain the secret will leak
* The secret becomes quite valuable to an attacker
* All users authenticate the same way, so the gateway cannot tell them apart for logging or access control purposes
* Changing the secret is difficult. You have to securely notify all users.
* If you find out the secret has been compromised, you can change it, but then what? None of your users can connect without the new secret. How will you notify them all, quickly and securely, without using the VPN?

cane
06.01.04, 15:14
Das ist mir schon klar dass es unsicherer ist - es ist ja auch nur zum Testen.
Wenn die shared secret Connection steht kannst Du immer noch weiterprobieren und hast wenigstens ne Grundlage.

Auch für den Fall das der server irgendwann den Löffel abgibt ist eine shared secret conection schneller wieder am Laufen...

cane

cane
06.01.04, 15:36
You can have multiple Road Warriors using shared secret authentication only if they all use the same secret. You must also set: uniqueids=no

Ist bei mir wie Du in meiner .config siehst auf yes gesetzt trotzdem können zwei Clients gleichzeitig über den VPN Router ins "sichere LAN" :confused::confused:

Womit hast Du eigentlich Deine Grafik vom Netz erstellt?
Ich habe mir extra Visual Studio NET 2003 Enterprise Architect mit Visio besorgt aber es läuft nicht weils irgend ein prerelease ist :ugly:

So ein kleines Progrämmle würd mir zum überbrücken reichen...

mfg
cane

luckyduck
06.01.04, 15:43
das habe ich mit dia gemacht:

http://www.lysator.liu.se/~alla/dia/


die config will er nicht fressen, kann es sein das die fuer version 1.x ist ? ich probiere es nachher mal mit der 1.99 version. die ist in den gentoo-sources eingearbeitet. ich hatte die 2.04er genommen da ich dachte dann gleich zu beginn auf dem aktuellen stand zusein. er kennt z.b. plutoload und plutostart nicht. wenn ich leftsubnet=192.168.200.0/24 angebe bekommt der client die verbindung nichtmal aufgebaut, ich spiele schon seit 5 tagen mit tausend verschiedenen kombinationen rum. naja, ich probiers mal mit einer frueheren version, spaeter. trotzdem soweit schonmal danke. morgen muesste dann "VPN mit Linux" auch ankommen, *hoff*. =)

cane
06.01.04, 16:25
VPN mit linux hab ich pünklich vor den Weihnachtsferien im November bekommen - hatte aber auch vorbestellt...
Sehr gutes Buch...

Wegen der config - ich vergaß dass ich Superfreeswn nutze und Du ne 2er Freeswan:ugly:

cu
cane

luckyduck
06.01.04, 16:35
superfreeswan waere auch mal eine idee, ich schau mir den mal an bevor ich mit den . da ist ja der x509 patch gleich drin glaube ich.

cane
07.01.04, 08:31
Richtig und außerdem noch viele andere:


- X.509 Digital Certificates
- RFC 2409 Port Selectors
- ALG 0.8.1 (All ciphers/hashes enabled as modules, inc 1DES)
- Notify/Delete SA
- NAT Traversal
- Dead Peer Detection (DPD IETF Draft)


Mehr Infos unter

http://www.freeswan.ca/code/super-freeswan/

mfg
cane