|
|
Besucher 746317
Ansichten 535
Online 0 |
|
|
VPV-linux-client an DFL200
| |
| Thema |
Verfasser |
Letzte Antwort |
| VPV-linux-client an DFL200 |
forgot_it ( ---.30.43.99) |
24 Sep 2008 10:07 | Hallo,
nach einem freundlichen Hinweis von Herrn Spenneberg klappt jetzt meine Anmeldung im Forum ;-)
Sein erster Lösungsschritt ist am Post angefügt - reicht meinem kleinen Hirn aber noch nicht zum Enderfolg.
---------
Ich habe einen neuen D-Link DFL-200. Das Teil funktioniert soweit (außer dass ich DHCP mit festen IPs für feste MAC vermisse). Mit einem Windows-Client klappt VPN mit PSK auch. Mit einem debian bekomme ich es nicht hin.
Meine /etc/ipsec.conf (habe schon viele Varianten ausprobiert):
---snipp
version 2.0 # conforms to second version of ipsec.conf specification
config setup
nat_traversal=yes
nhelpers=0
include /etc/ipsec.d/examples/no_oe.conf
conn dfl200
left=%defaultroute
right=a.b.c.5 # a.b.c ist das öffentliche Netz und 5 die IP der DFL-200
authby=secret
rightid=dfl200
auto=add
pfs=yes
leftprotoport=17/1701
rightprotoport=17/1701
---snapp
die /etc/ipsec.secrets
---snipp
: PSK "Das_ist_Geheim"
---snapp
Der Start:
----snipp
ipsec auto --up dfl200
104 "dfl200" #1: STATE_MAIN_I1: initiate
003 "dfl200" #1: received Vendor ID payload [Dead Peer Detection]
003 "dfl200" #1: ignoring Vendor ID payload [draft-stenberg-ipsec-nat-traversal-01]
003 "dfl200" #1: ignoring Vendor ID payload [draft-stenberg-ipsec-nat-traversal-02]
003 "dfl200" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
003 "dfl200" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] method set to=107
003 "dfl200" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 107
003 "dfl200" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] method set to=108
106 "dfl200" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "dfl200" #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected
108 "dfl200" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "dfl200" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
117 "dfl200" #2: STATE_QUICK_I1: initiate
003 "dfl200" #2: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME
004 "dfl200" #2: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x78b8b1dd <0xf07efcd5 xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}
----snapp
Dass nicht genatted wird ist schon mal falsch (denke ich). Von der DFL-200 müsste eine IP aus 192.168.40.220-192.168.40.229 erhalten werden.
Auf dem DFL-200 Log steht: (nicht wundern: zum Test sind beide Geräte im gleichen öffentlichen Netz a.b.c.)
----snipp
[2008-07-11 09:00:22] <6>EFW: IPSEC: prio=1 SA ESP[e7f6b96d] alg [3des-cbc/24]+hmac[hmac-sha1-96] bundle [16,0] pri 0 opts src=ipv4(udp:1701,[0..3]=a.b.c.99) dst=ipv4(udp:1701,[0..3]=a.b.c.5)
[2008-07-11 09:00:22] <6>EFW: IPSEC: prio=1 SA ESP[243b4bc3] alg [3des-cbc/24]+hmac[hmac-sha1-96] bundle [16,0] pri 0 opts src=ipv4(udp:1701,[0..3]=a.b.c.5) dst=ipv4(udp:1701,[0..3]=a.b.c.99)
[2008-07-11 09:00:22] <6>EFW: IPSEC: prio=1 Phase-2 [responder] done bundle 16 with 2 SA's by rule 2:`ipsec ipv4(any:0,[0..3]=a.b.c.5)<->ipv4_subnet(any:0,[0..7]=0.0.0.0/0)'
[2008-07-11 09:00:21] <4>EFW: IPSEC: prio=3 IKE Phase-2; No key-length proposed for variable key-length cipher aes-cbc
[2008-07-11 09:00:21] <4>EFW: IPSEC: prio=3 IKE Phase-2; No key-length proposed for variable key-length cipher aes-cbc
[2008-07-11 09:00:21] <6>EFW: IPSEC: prio=1 Phase-1 [responder] between ipv4(udp:500,[0..3]=a.b.c.5) and ipv4(any:0,[0..3]=a.b.c.99) done.
[2008-07-11 09:00:05] <5>EFW: CONN: rule=IPsecBeforeRules conn=close connipproto=UDP connrecvif=WAN connsrcip=a.b.c.99 connsrcport=500 conndestif=core conndestip=a.b.c.5 conndestport=500 origsent=2492 termsent=0
[2008-07-11 09:00:04] <5>EFW: CONN: rule=IPsecBeforeRules conn=open connipproto=UDP connrecvif=WAN connsrcip=a.b.c.99 connsrcport=500 conndestif=core conndestip=a.b.c.5 conndestport=500
-----snapp
Wahrscheinlich ist es nur noch eine Kleinigkeit, die mich aber Tage kostet und google führ mich auch nicht so recht zum Ziel.
Können Sie mir helfen?
--------
Hier der Hinweis von Herrn Spenneberg:
...
Ich denke, dass es sich nicht um ein reines IPsec-VPN handelt, sondern
um ein L2TP over IPsec. So haben Sie zumindest alles konfiguriert. Dann
benötigen Sie unter Linux noch ein L2TP-Daemon.
...
Daraufhin habe ich xl2tpd installiert und nachdem ich den Kernel mit Unterstützung für pppol2tp neu übersetzte startete das Teil auch.
Jul 14 11:38:02 amadeb03 xl2tpd[5497]: setsockopt recvref: Protocol not available
Jul 14 11:38:02 amadeb03 xl2tpd[5497]: Using l2tp kernel support.
Jul 14 11:38:02 amadeb03 xl2tpd[5498]: xl2tpd version xl2tpd-1.2.0 started on amadeb03 PID:5498
Jul 14 11:38:02 amadeb03 xl2tpd[5498]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
Jul 14 11:38:02 amadeb03 xl2tpd[5498]: Forked by Scott Balmos and David Stipp, (C) 2001
Jul 14 11:38:02 amadeb03 xl2tpd[5498]: Inherited by Jeff McAdams, (C) 2002
Jul 14 11:38:02 amadeb03 xl2tpd[5498]: Forked again by Xelerance (www.xelerance.com) (C) 2006
Jul 14 11:38:02 amadeb03 xl2tpd[5498]: Listening on IP address 0.0.0.0, port 1701
meine xl2tpd.conf:
---snipp
[global]
port = 1701
[lac dfl200]
lns = 141.30.43.5
require chap = yes
refuse pap = yes
require authentication = yes
; Name should be the same as the username in the PPP authentication!
name = dfl200
ppp debug = yes
pppoptfile = /etc/ppp/options-client.xl2tpd
length bit = yes
-----snapp
Und die l2tp-secrets
141.30.43.5 * Das_ist_Geheim
dfl200 * Das_ist_Geheim
Dann der Aufruf:
ipsec auto --up dfl200 && echo "c dfl200" > /var/run/l2tp-control
Es kommt zu keiner Verbidung. ppp0 wird nicht angelegt. Der Versuch, das debuglevel von xl2tpd zu erhöhen brachte keine zusätzlichen Eintragungen in den log-Dateien.
Es ist mir ein Rätsel. In der Verzweiflung versuchte ich auch erst xl2tpd zu starten und dann den ipsec-Dienst (den --up -Befehl natürlich immer erst danach und zwischendruch brav --down usw.)
Hat jemand einen Tipp, an welcher Stelle ich mit Blindheit geschlagen bin?
Viele Grüße
forgot_it
|
| ||
| RE: VPV-linux-client an DFL200 | Ralf ( ---.dip.t-dialin.net) | 12 Aug 2008 12:38 |
Verschickt der l2tpd denn Pakete? Was sagt tcpdump?
Gruß,
Ralf
| | RE: RE: VPV-linux-client an DFL200 | forgot_it ( ---.30.43.99) | 8 Sep 2008 12:47 |
Hallo,
ich komme jetzt leider erst wieder zum Testen...
Im tcpdump finde ich folgendes:
14:34:32.375272 IP a.b.c.5.isakmp > my03.local.isakmp: isakmp: phase 2/others ? inf[E]
14:34:32.375420 IP my03.local.isakmp > a.b.c.5.isakmp: isakmp: phase 2/others ? inf[E]
Da wird also was ausgetauscht.
my03 ist der lokale Rechner und a.b.c.5 ist die IP des DFL200.
Im Protokoll des DFL200 steht auch eine aktive UDP-Verbindung zu WAN:a.b.c.99:500 von core:a.b.c.5:500
(99 ist IP von my03).
Viele Grüße
Andreas | | RE: RE: RE: VPV-linux-client an DFL200 | Ralf ( ---.dip.t-dialin.net) | 24 Sep 2008 10:07 |
Das sieht so aus, als ob L2TP keine Pakete verschickt. Dass müssten IPsec-Pakete sein (ESP oder UDPencap) und nicht UDP Port 500.
Also ein Problem bei dem L2TP.
Gruß,
Ralf
|
[ Zurück ] Um ein neues Thema hinzu zu fügen müssen sie eingeloggt sein.
|
|
|
|
Welche Distribution verwenden Sie?
| |
|
|
|
17 Oct 2008: