Probleme mit DHCP over IPsec am Openswan Server

Hi.

Ich bin dabei ein Roadwarrior Setup zur Einwahl mobiler Clients in unser Netzwerk zu implementieren.
Mein Hauptproblem ist die Vergabe von IP Addressen an die Clients. Inklusive DNS Server DNS Suffix und entsprechende Routen.
Da die ganze Aktion mit einer Windows Einwahlclient - L2TP over IPSec Lösung mit IPPool-Dienst nicht so super geklappt hat habe ich mich auf anraten von aqui (siehe hier: Windows 2008 L2TP Server mit Openswan IPSec VPN benutzen) für einen systemunabhängigen Software Client entschieden.

Ich habe Shrewsoft VPN benutzt (gerade probiere ich noch mit der NCP Secure Entry Client Testversion um etwas Redundanz in die Tests zu bekommen).

Die Netzwerkkonfiguration:
- Der Openswan Server ist direkt am Internet und hat eine feste IP
- Openswan 2.6.21, OpenSUSE 10.3 Kernel 2.6.22.19-0.2, KLIPS als Stack
- Der Client befindet sich hinter einem Router, der eine andere Internetverbindung nutzt; NAT, dynamisch IP

Wie man am Log unten sehen kann, wird die Verbindung gestartet und Phase 1 abgeschlossen.
Dann tritt folgender Fehler auf:

cannot respond to IPsec SA request because no connection is known for 0.0.0.0/0===xxx.xxx.xxx.xxx[C=DE, ST=Brandenburg, L=Potsdam, O=Krellmann, OU=Servers, CN=vpngate, E=root@vpngate.potsdam.krellmann.net,+S=C]:17/67...xxx.xxx.xxx.xxx[C=DE, O=krellmann, OU=roadwarrior, CN=potsdam.krellmann.net, E=adminmail@maildom.de,+S=C]:17/68===192.168.20.20/32

Der Shrew Soft Client gibt dann aus: "no DHCP response from gateway"
Der NCP Client: "ERROR - 4037: IKE(phase2): Waiting for message2, retry timeout" (Das Openswan Log unten ist auch während der Nutzung vom NCP Client entstanden, ist aber identisch mit dem vom ShrewSoft Client)

Die Konfigurationen der beiden Clients sind so, dass sie DHCP over IPSec nutzen sollen. Es ist keine Addresse voreingestellt.
Wenn ich die verschiedenen Dokus im Internet richtig verstanden habe, dann soll erst kurzzeitig eine IPSec Verbindung hergestellt werden um via DHCP eine Addresse zu beziehen. Danach wird erst die eigentliche Verbindung aufgebaut... Die Verbindung "roadwarrior" im Log ist aber schon die "Hauptverbindung". Für DHCP müsste "roadwarrior-dhcp" verwendet werden. Vorher taucht diese im Log auch nicht auf...

Meine ipsec.conf:

config setup
	interfaces=%defaultroute
	klipsdebug=none
	nat_traversal=yes
	nhelpers=0
	plutodebug=none
	protostack=klips
	uniqueids=yes
	virtual_private=%v4:10.0.1.0/24,%v4:10.0.2.0/24,%v4:!192.168.10.0/24,%v4:!192.168.178.0/24
 
conn %default
	type=tunnel
	authby=rsasig
	pfs=no
	rekey=no
	keylife=1h
	ikelifetime=3h
	keyingtries=3
	left=%defaultroute
	leftrsasigkey=%cert
	rightca=%same
	rightrsasigkey=%cert

conn roadwarrior
	leftcert=g1.krellmann.net.pem
	leftsubnet=192.168.10.0/24
	right=%any
	rightcert=roadwarrior.potsdam.krellmann.net.pem
	rightsubnet=vhost:%no,%priv
	auto=add
 
conn roadwarrior-dhcp
	keylife=20s
	rekeymargin=10s
	left=%defaultroute
	leftcert=g1.krellmann.net.pem
	leftprotoport=udp/bootps
	#this allows DHCP discovery broadcast:
	leftsubnet=0.0.0.0/0
	right=%any
	rightcert=roadwarrior.potsdam.krellmann.net.pem
	rightprotoport=udp/bootpc
	auto=add

(Die Einstellungen zur DHCP Vebindung sind aus dem Openswan Readme zusammengestellt)

Schreibe ich die "conn roadwarrior-dhcp" vor die "conn roadwarrior" benutzt Openswan diese (steht dann im Log). Trotz der Tatsache, dass für die "conn roadwarrior" eigentlich noch kein gültiges rightsubnet vorhanden ist. Die interne IP 192.168.20.20 die der Testlaptop hat ist ja nicht in virtual_private eingetragen...
Scheinbar erkennt Openswan nicht, welche Verbindung zu nutzen ist und nimmt die Erste.
Oder interpretiere ich das falsch und es hat einen anderen Grund?

Greets,
Martin.

Das Log: (entfernt; zu lang und nicht mehr aktuell)

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 117213

Url: https://administrator.de/contentid/117213

Ausgedruckt am: 22.11.2024 um 21:11 Uhr

3 Kommentare

Neuester Kommentar

Da der IPsec Client (Shrew) hinter einem Router ist hast du dort bedacht ein Port Forwarding von
UDP 500 (IKE)
UDP 4500 (NAT-T)
ESP (IP Protokoll Nummer 50)

auf die lokale IP des Client PCs einzurichten ???
Das ist zwingend notwendig bei IPsec Clients mit ESP !
Aus diesem Grunde sollte man dem Client auch eine statische IP intern geben damit die Port Weiterleitungsregel durch die Dynamik von DHCP nicht ausgehebelt wird.

Jupp, das hab ich beachtet.... Ist genau so konfiguriert wie du sagst.

Noch etwas zur Openswan Konfiguration:
Stimmt es das der Paremeter \"rightsubnetwithin\" zur Zuordnung von den variablen Subnets zur Verbindung Obsolete ist und man stattdessen \"rightsubnet:vhost:%no,%priv\" nimmt? Überall im Netz wird der alte Parameter angegeben.?

Hier ist noch die Ausgabe von \"ipsec auto --status\": (entfernt; nicht mehr aktuell)

Da kann man sehr gut sehen, dass eigentlich für \"roadwarrior\" nur die Subnetze aus \"virtual_private\" zulässig sein sollen und für \"roadwarrior-dhcp\" alle Addressen, aber nur von Quellport 68 UDP...
Deshalb verwirrt es mich so das er immer die Verbindung nutzt, die zuerst gefunden wird (also die weiter oben in der ipsec.conf).

Greets,
Martin.

Hi.

Du hattest recht... es lag doch am NAT. Ich hab die Einstellungen zwar gemacht und die Ports auf die richtige IP geleitet, scheinbar hat der Router es aber nicht richtig übernommen (ich hatte einen alten Eumex angeschlossen). Nachdem ich den ihn rausgeschmissen hab und meinen Laptop zum testen nun direkt über das Modem wählen lasse läuft es.

Allerdings hab ich es bis jetzt noch nicht geschafft, dass die DHCP Pakete vom Server beim IPSec Client ankommen. Irgendwas klappt da mit dem Routing nicht...
Ein DHCP Relay nehm ich nicht, ich kann meinen Windows DHCP Server sowieso nicht so einstellen das er die Clients zuordnen könnte. Also hab ich in dem Linux Router noch einen eingerichtet, der nur das ipsec0 Interface abhört (Momentan noch per Hand im debug Modus gestartet). Ist ein selbst kompilierter ISC DHCPd 4.1.0.
Ich habe dort ein Subnet 0.0.0.0 angelegt, darin ein Pool 10.0.1.1 - 10.0.1.253 und ordne diesem die Clients per class zu (Match auf Hardwaretyp). Das klappt alles... Der DHCP Request kommt an und der Server gibt auf ipsec0 auch ein DHCPOFFER raus. Allerdings schon an die IP die der Client erst bekommen soll (10.0.1.1). Der Client empfängt dies aber nicht.

Liegt es vielleicht daran, dass das DHCP Paket schon an die endgültige IP geschickt wird? (Openswan also nicht weiß, zu welchem Tunnel es gehört...)
Andererseits habe ich festgestellt, dass nachdem die SA aufgebaut wurde in pluto eine ganze weile nicht passiert. Der NCP Client schickt währenddessen munter DHCP_DISCOVER Pakete. Erst wenn im Client ein Timeout auftritt macht pluto weiter, es versucht dann einen Quick Mode herzustellen und etwas zu übertragen. Dies schlägt natürlich fehl... Ich bin mir aber nicht sicher, ob es sich dabei um die DHCPOFFER handelt.

Hier noch mal einige Zeilen aus dem Log:
<code type=\"plain\">Jun 11 17:58:37: "roadwarrior-dhcp"[1] 88.130.180.160 #4: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0x0c4f3293 <0x8317c961 xfrm=AES_128-HMAC_MD5 NATOA=none NATD=none DPD=none}
Jun 11 17:58:37: | modecfg pull: noquirk policy:push not-client
Jun 11 17:58:37: | phase 1 is done, looking for phase 2 to unpend
Jun 11 17:58:37: | * processed 0 messages from cryptographic helpers
Jun 11 17:58:37: | next event EVENT_NAT_T_KEEPALIVE in 19 seconds
Jun 11 17:58:37: | next event EVENT_NAT_T_KEEPALIVE in 19 seconds
Jun 11 17:58:56: |
Jun 11 17:58:56: | next event EVENT_NAT_T_KEEPALIVE in 0 seconds
Jun 11 17:58:56: | *time to handle event
Jun 11 17:58:56: | handling event EVENT_NAT_T_KEEPALIVE
Jun 11 17:58:56: | event after this is EVENT_SA_REPLACE in 26 seconds
Jun 11 17:58:56: | processing connection roadwarrior-dhcp[1] 88.130.180.160
Jun 11 17:58:56: | processing connection roadwarrior[1] 88.130.180.160
Jun 11 17:58:56: | processing connection trusetal.krellmann.net
Jun 11 17:58:56: | processing connection trusetal.krellmann.net
Jun 11 17:58:56: | next event EVENT_SA_REPLACE in 26 seconds for #4
Jun 11 17:59:22: |
Jun 11 17:59:22: | next event EVENT_SA_REPLACE in 0 seconds for #4
Jun 11 17:59:22: | *time to handle event
Jun 11 17:59:22: | handling event EVENT_SA_REPLACE
Jun 11 17:59:22: | event after this is EVENT_SHUNT_SCAN in 33 seconds
Jun 11 17:59:22: | processing connection roadwarrior-dhcp[1] 88.130.180.160
Jun 11 17:59:22: | duplicating state object #3
Jun 11 17:59:22: | creating state object #5 at 0x8159ce0
Jun 11 17:59:22: | processing connection roadwarrior-dhcp[1] 88.130.180.160
Jun 11 17:59:22: | ICOOKIE: bd 8f 7f f4 07 15 8e 06
Jun 11 17:59:22: | RCOOKIE: fe a6 00 c4 b3 d8 02 81
Jun 11 17:59:22: | state hash entry 13
Jun 11 17:59:22: | inserting state object #5 on chain 13
Jun 11 17:59:22: | inserting event EVENT_SO_DISCARD, timeout in 0 seconds for #5
Jun 11 17:59:22: "roadwarrior-dhcp"[1] 88.130.180.160 #5: initiating Quick Mode RSASIG+ENCRYPT+TUNNEL+DONTREKEY+IKEv2ALLOW to replace #4 {using isakmp#3 msgid:f576aefd proposal=defaults pfsgroup=no-pfs}
Jun 11 17:59:22: | 2: w->pcw_dead: 0 w->pcw_work: 0 cnt: 5
Jun 11 17:59:22: | asking helper 2 to do build_nonce op on seq: 7 (len=2668, pcw_work=1)
Jun 11 17:59:22: | crypto helper write of request: cnt=2668<wlen=2668.
Jun 11 17:59:22: | inserting event EVENT_CRYPTO_FAILED, timeout in 300 seconds for #5
Jun 11 17:59:22: | state: 4 requesting event none to be deleted by /usr/src/openswan-2.6.21/programs/pluto/timer.c:570
Jun 11 17:59:22: | inserting event EVENT_SA_EXPIRE, timeout in 15 seconds for #4
Jun 11 17:59:22: | next event EVENT_SA_EXPIRE in 15 seconds for #4
Jun 11 17:59:22: ! helper 2 read 2664+4/2668 bytesfd: 10
Jun 11 17:59:22: ! helper 2 doing build_nonce op id: 7
Jun 11 17:59:22: ! Generated nonce:
Jun 11 17:59:22: ! ea 4c a0 54 6b 00 5a cf 11 e6 7b 0f 94 a1 7c af
Jun 11 17:59:22: |
Jun 11 17:59:22: | helper 2 has finished work (cnt now 1)
Jun 11 17:59:22: | helper 2 replies to id: q#7
Jun 11 17:59:22: | calling callback function 0x8071e61
Jun 11 17:59:22: | processing connection roadwarrior-dhcp[1] 88.130.180.160
Jun 11 17:59:22: | empty esp_info, returning defaults
Jun 11 17:59:22: | generate SPI: 83 17 c9 62
Jun 11 17:59:22: | HASH(1) computed:
Jun 11 17:59:22: | 37 46 4b 68 8c 02 70 22 2d 15 66 92 35 01 73 5b
Jun 11 17:59:22: | last Phase 1 IV: 70 a5 aa d1 d9 da 2c e8 c8 14 d7 f1 41 14 f6 51
Jun 11 17:59:22: | current Phase 1 IV: 70 a5 aa d1 d9 da 2c e8 c8 14 d7 f1 41 14 f6 51
Jun 11 17:59:22: | computed Phase 2 IV:
Jun 11 17:59:22: | 27 58 a9 fc 59 92 71 cf ac f7 6d bc 9c 89 98 83
Jun 11 17:59:22: | encrypting:
Jun 11 17:59:22: | 01 00 00 14 37 46 4b 68 8c 02 70 22 2d 15 66 92
Jun 11 17:59:22: | 35 01 73 5b 0a 00 00 80 00 00 00 01 00 00 00 01
Jun 11 17:59:22: | 00 00 00 74 00 03 04 04 83 17 c9 62 03 00 00 1c
Jun 11 17:59:22: | 00 0c 00 00 80 04 00 01 80 01 00 01 80 02 00 3c
Jun 11 17:59:22: | 80 05 00 02 80 06 00 80 03 00 00 1c 01 0c 00 00
Jun 11 17:59:22: | 80 04 00 01 80 01 00 01 80 02 00 3c 80 05 00 01
Jun 11 17:59:22: | 80 06 00 80 03 00 00 18 02 03 00 00 80 04 00 01
Jun 11 17:59:22: | 80 01 00 01 80 02 00 3c 80 05 00 02 00 00 00 18
Jun 11 17:59:22: | 03 03 00 00 80 04 00 01 80 01 00 01 80 02 00 3c
Jun 11 17:59:22: | 80 05 00 01 05 00 00 14 ea 4c a0 54 6b 00 5a cf
Jun 11 17:59:22: | 11 e6 7b 0f 94 a1 7c af 05 00 00 10 04 11 00 43
Jun 11 17:59:22: | 00 00 00 00 00 00 00 00 00 00 00 0c 01 11 00 44
Jun 11 17:59:22: | 58 82 b4 a0
Jun 11 17:59:22: | IV:
Jun 11 17:59:22: | 27 58 a9 fc 59 92 71 cf ac f7 6d bc 9c 89 98 83
Jun 11 17:59:22: | unpadded size is: 196
Jun 11 17:59:22: | encrypting 208 using OAKLEY_AES_CBC
Jun 11 17:59:22: | next IV: 3d 59 c8 56 45 76 ac 83 ad ab 8e 4d 20 32 6e 36
Jun 11 17:59:22: | sending 236 bytes for quick_outI1 through eth0:500 to 88.130.180.160:500 (using #5)
Jun 11 17:59:22: | inserting event EVENT_RETRANSMIT, timeout in 10 seconds for #5
Jun 11 17:59:22: | * processed 1 messages from cryptographic helpers
Jun 11 17:59:22: | next event EVENT_RETRANSMIT in 10 seconds for #5
Jun 11 17:59:22: | next event EVENT_RETRANSMIT in 10 seconds for #5
Jun 11 17:59:32: |
Jun 11 17:59:32: | next event EVENT_RETRANSMIT in 0 seconds for #5
Jun 11 17:59:32: | *time to handle event
Jun 11 17:59:32: | handling event EVENT_RETRANSMIT
Jun 11 17:59:32: | event after this is EVENT_SA_EXPIRE in 5 seconds
Jun 11 17:59:32: | processing connection roadwarrior-dhcp[1] 88.130.180.160
Jun 11 17:59:32: | handling event EVENT_RETRANSMIT for <invalid> "roadwarrior-dhcp" #5
Jun 11 17:59:32: | sending 236 bytes for EVENT_RETRANSMIT through eth0:500 to 88.130.180.160:500 (using #5)
Jun 11 17:59:32: | inserting event EVENT_RETRANSMIT, timeout in 20 seconds for #5
Jun 11 17:59:32: | next event EVENT_SA_EXPIRE in 5 seconds for #4
Jun 11 17:59:37: |
Jun 11 17:59:37: | next event EVENT_SA_EXPIRE in 0 seconds for #4
Jun 11 17:59:37: | *time to handle event
Jun 11 17:59:37: | handling event EVENT_SA_EXPIRE
Jun 11 17:59:37: | event after this is EVENT_RETRANSMIT in 15 seconds
Jun 11 17:59:37: | processing connection roadwarrior-dhcp[1] 88.130.180.160
Jun 11 17:59:37: "roadwarrior-dhcp"[1] 88.130.180.160 #4: IPsec SA expired (--dontrekey)

Greets
Martin.

Frage Linux Linux Netzwerk

Mehr von martin2002

Ist ein LVM Volume während einer Konvertierung weiterhin beschreibbar?martin2002 - 4 Kommentare

Default Gateway über VLAN Schnittstellemartin2002 - 7 Kommentare

DFS Freigabe verschwindet sporadischmartin2002 - 8 Kommentare

Windows 2008 L2TP Server mit Openswan IPSec VPN benutzenmartin2002 - 4 Kommentare

Heiß diskutiert