|
|
Besucher 1260505
Ansichten 3555
Online 0 |
|
|
OpenSWAN Roadwarrior - Mac OS X Server VPN (IPsec/L2TP)
| |
| Thema |
Verfasser |
Letzte Antwort |
| OpenSWAN Roadwarrior - Mac OS X Server VPN (IPsec/L2TP) |
Oli4 ( ---.dip0.t-ipconnect.de) |
7 Feb 2010 17:02 | Hi
Ich versuche grade mit OpenSWAN eine Verbindung zu einem ge-nat-eten
Mac OS X Server (built-in VPN) mit IPsec/L2TP herzustellen.
(bin vollkommener OpenSWAN-Newbie)
Die IPSec Verbindung scheint auch zu klappen. Nur dringen dann leider
anscheinend keine Daten durch.
Meine Konfigurationsdateien:
---------------------------------------------------------------------
# /etc/ipsec/ipsec.conf - Openswan IPsec configuration file
# RCSID $Id: ipsec.conf.in,v 1.15.2.6 2006/10/19 03:49:46 paul Exp $
# basic configuration
config setup
nat_traversal=yes
nhelpers=0
conn L2TP-PSK-CLIENT
authby=secret
pfs=no
rekey=yes
keyingtries=3
type=transport
#
left=%defaultroute
leftprotoport=17/1701
#
right=GATEWAY_EXTERNAL_IP
rightid=192.168.0.2 #INTERNAL_IP des Gateways (wird dieses weggelassen, wird die IPsec.Verbindung nicht aufgebaut)
rightsubnet=192.168.0.0/24 # (wird dieses weggelassen, wird die IPsec.Verbindung nicht aufgebaut)
rightnexthop=%defaultroute
#
rightprotoport=17/1701
#
auto=add
include /etc/ipsec/ipsec.d/examples/no_oe.conf
---------------------------------------------------------------------
# /etc/xl2tpd/xl2tpd.conf
; Connect as a client to a server at 192.168.0.2
[lac L2TPserver]
lns = 192.168.0.2
require chap = yes
refuse pap = yes
require authentication = yes
; Name should be the same as the username in the PPP authentication!
name = username
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client
length bit = yes
---------------------------------------------------------------------
Starte ich die Verbindung mit
$ ipsec auto --up L2TP-PSK-CLIENT
kommt als output:
104 "L2TP-PSK-CLIENT" #3: STATE_MAIN_I1: initiate
003 "L2TP-PSK-CLIENT" #3: received Vendor ID payload [RFC 3947] method set to=109
003 "L2TP-PSK-CLIENT" #3: received Vendor ID payload [Dead Peer Detection]
106 "L2TP-PSK-CLIENT" #3: STATE_MAIN_I2: sent MI2, expecting MR2
003 "L2TP-PSK-CLIENT" #3: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed
108 "L2TP-PSK-CLIENT" #3: STATE_MAIN_I3: sent MI3, expecting MR3
004 "L2TP-PSK-CLIENT" #3: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
117 "L2TP-PSK-CLIENT" #4: STATE_QUICK_I1: initiate
003 "L2TP-PSK-CLIENT" #4: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME
004 "L2TP-PSK-CLIENT" #4: STATE_QUICK_I2: sent QI2, IPsec SA established {ESP=>0x0583db86 <0x35964c85 xfrm=AES_0-HMAC_SHA1 NATD=GATEWAY_EXTERNAL_IP:4500 DPD=none}
"ip route" ergibt:
192.168.178.0/24 dev wlan0 proto kernel scope link src 192.168.178.20 metric 2008
192.168.0.0/24 dev wlan0 scope link
127.0.0.0/8 via 127.0.0.1 dev lo
default via 192.168.178.1 dev wlan0 metric 2008
Hingegen wenn ich die L2TP-Verbindung mit
'echo "c L2TPserver" > /var/run/xl2tpd/l2tp-control' starte, kommt:
Jan 18 15:21:39 oli4snotebook xl2tpd[4861]: Connecting to host 192.168.0.2, port 1701
Jan 18 15:21:44 oli4snotebook xl2tpd[4861]: Maximum retries exceeded for tunnel 24079. Closing.
auch ein ping in das 192.168.0.0/24 Netz klappt nicht.
Hat jemand eine Idee? Wie müsste das Netz denn erreichbar sein, nach IPsec-Verbindungsaufbau?
Übersehe ich etwas?
Ist eine Roadwarrior-Client-Verbindung vielleicht besser mit racoon
oder noch anders zu realisieren?
Wie würde die Konfiguration dann aussehen?
Danke für eure Antworten
Gruß
Oli4 |
| ||
| RE: OpenSWAN Roadwarrior - Mac OS X Server VPN (IPsec/L2TP) | Ralf ( ---.6.125.2) | 21 Jan 2010 13:45 |
Hallo,
ein Ping funktioniert nicht, da die IPsec-Verbindung nur UDP-Pakete von und an den Port 1701 durchlässt.
Die IPsec-Verbindung wird aber aufgebaut. Das lässt den Schluss zu, dass entweder hier trotzdem noch ein Fehler vorliegt oder L2TP nicht richtig konfiguriert ist. Versuche doch mal mit tcpdump den Verkehr mitzuschneiden, wenn die IPsec-Verbindung aufgebaut wurde und Du versuchst den L2TP-Daemon zu starten. Mal sehen, was für Pakete versandt werden.
Gruß,
Ralf | | RE: RE: OpenSWAN Roadwarrior - Mac OS X Server VPN (IPsec/L2... | Oli4 ( ---.customers.d1-online.com) | 1 Feb 2010 00:53 |
Hi
Danke schon mal für die Antwort.
Bin mittlerweile etwas weiter gekommen. racoon scheint besser zu funktionieren. Dann klappt auch die (x)l2tp-Anmeldung.
Es scheint auch soweit bis zur L2TP-Anmeldung alles zu funktionieren (Anmeldung wird vom Server akzeptiert, IP-Adresse verteilt, ppp0 wird aufgebaut)
Leider scheinen dann aber keine Daten durch den ppp0-Tunnel zu gelangen.
Hier die Konfigurationsdateien (91.x.x.x ist die Externe IP des VPN-Servers, 192.168.20.3 ist die interne IP des Clients):
# /etc/racoon/racoon.conf
log debug2;
path pre_shared_key "/etc/racoon/psk.txt";
listen {
isakmp 192.168.20.3 [500];
}
remote 91.x.x.x {
exchange_mode main;
lifetime time 24 hour;
script "/etc/racoon/scripts/phase1-up.sh" phase1_up;
script "/etc/racoon/scripts/phase1-down.sh" phase1_down;
proposal {
encryption_algorithm 3des;
hash_algorithm sha1;
authentication_method pre_shared_key;
dh_group 2;
}
}
sainfo anonymous {
encryption_algorithm aes;
authentication_algorithm hmac_sha1;
pfs_group 2;
compression_algorithm deflate;
lifetime time 1 hour;
}
-----------------------------------------------------------
# /etc/racoon/scripts/phase1-up.sh
echo "
spdadd 192.168.20.3[any] 91.x.x.x[any] any
-P out ipsec esp/transport//require;
spdadd 91.x.x.x[any] 192.168.20.3[any] any
-P in ipsec esp/transport//require;
spdadd 91.x.x.x[any] 192.168.20.3[any] any
-P fwd ipsec esp/transport//require;
" | setkey -c
-----------------------------------------------------------
# /etc/xl2tpd/xl2tpd.conf
[lac L2TPserver]
lns = 91.x.x.x
require chap = yes
refuse pap = yes
require authentication = yes
; Name should be the same as the username in the PPP authentication!
name = username
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client
length bit = yes
-----------------------------------------------------------
# /etc/ppp/options.l2tpd.client
ipcp-accept-local
ipcp-accept-remote
refuse-eap
noccp
noauth
crtscts
idle 1800
mtu 1410
mru 1410
nodefaultroute
debug
lock
connect-delay 5000
-----------------------------------------------------------
Wie gesagt: racoon-VPN-Verbindung wird erfolgreich aufgebaut, CHAP-Authentifizierung ist erfolgreich, ppp0 wird aufgebaut, die IP (in diesem Fall: 192.168.1.138) wird vom Server vergeben
folgende IP/Routing-Einstellungen:
# ip addr
22: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1410 qdisc pfifo_fast state UNKNOWN qlen 3
link/ppp
inet 192.168.1.138 peer 91.x.x.x/32 scope global ppp0
# ip route
91.x.x.x dev ppp0 proto kernel scope link src 192.168.1.138
192.168.20.0/24 dev bnep0 proto kernel scope link src 192.168.20.3 metric 10
192.168.1.0/24 dev ppp0 scope link
default via 192.168.20.1 dev bnep0 metric 10
-----------------------------------------------------------
Und schließlich folgendes per tcpdump:
# tcpdump -n -i ppp0
...
01:36:15.780806 IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138 > 91.x.x.x: ip-proto-17}}}}}}}}}}
01:36:15.780895 IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138 > 91.x.x.x: ip-proto-17}}}}}}}}}}}
01:36:15.780982 IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138.1701 > 91.x.x.x.1701: l2tp:[L](11/19854) {IP 192.168.1.138 > 91.x.x.x: ip-proto-17}}}}
...
Solche Blöcke erscheinen immer und immer wieder.
Dabei scheinen dich die Anfragen immer weiter zu verschachteln bis es bei 11 "}" angekommen ist, dann fängt es wieder bei 4 an. Dabei unterscheiden sich der Block "l2tp:[L](11/19854)" bei jeder Anfrage, manchmal ist es auch (7/16384).
Gleichzeitig ist xl2tp bei 40-50% CPU-Auslastung. (Vermute aufgrund der vielen Anfragen)
# tcpdump -n -i bnep0
01:40:33.120876 IP 91.x.x.x > 192.168.20.3: ESP(spi=0x0af47c84,seq=0x5a), length 68
01:41:32.651607 IP 91.x.x.x > 192.168.20.3: ESP(spi=0x0af47c84,seq=0x5b), length 68
Auch hier unterscheidet sich die Länge je nach Anfrage, manchmal sind es 84 byte, manchmal 100 byte.
Firewall ist aus am client.
am Server sind 500, 1701, 1723 und (wahrscheinlich irrelevant) 4500 offen. (Verbindung mit Windows-Client und Mac-Client geht auch ohne Probleme)
Hoffe damit kann man was anfangen.
Irgeneine Idee
Gruß Olivier | | RE: RE: RE: OpenSWAN Roadwarrior - Mac OS X Server VPN (IPse... | Ralf ( ---.dip.t-dialin.net) | 2 Feb 2010 16:01 |
Deine IP-Adressen passen nicht zur Policy.
Du setzt folgende Policies:
> spdadd 192.168.20.3[any] 91.x.x.x[any] any
> -P out ipsec esp/transport//require;
> spdadd 91.x.x.x[any] 192.168.20.3[any] any
> -P in ipsec esp/transport//require;
> spdadd 91.x.x.x[any] 192.168.20.3[any] any
> -P fwd ipsec esp/transport//require;
Damit darf 91.x.x.x und 192.168.20.3 kommunizieren.
In Wirklichkeit nutzt Dein Tunnel aber laut tcpdump:
> 01:36:15.780806 IP 192.168.1.138.1701 > 91.x.x.x.1701:
91.x.x.x und 192.168.1.138.
Diese Pakete werden in Deinem Tunnel nicht erlaubt und verworfen.
Gruß,
Ralf
| | RE: RE: RE: RE: OpenSWAN Roadwarrior - Mac OS X Server VPN (... | Oli4 ( ---.hsi2.kabelbw.de) | 6 Feb 2010 20:41 |
Verstehe.
Ich habe die Policies jetzt erweitert durch:
echo "
spdadd 192.168.20.3[1701] 91.x.x.x[1701] udp
-P out ipsec esp/transport//require;
spdadd 91.x.x.x[1701] 192.168.20.3[1701] udp
-P in ipsec esp/transport//require;
spdadd 91.x.x.x[1701] 192.168.20.3[1701] udp
-P fwd ipsec esp/transport//require;
spdadd 192.168.1.138[any] 91.x.x.x[any] any
-P out ipsec esp/transport//require;
spdadd 91.x.x.x[any] 192.168.1.138[any] any
-P in ipsec esp/transport//require;
spdadd 91.x.x.x[any] 192.168.1.138[any] any
-P fwd ipsec esp/transport//require;
" | setkey -c
Nun liefert tcpdump -i ppp0 keinen Output mehr. (Das scheint schon mal gut zu sein :-))
versucht man einen ping 192.168.1.1 in das VPN-Netzwerk
liefert:
tcpdump -i ppp0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
19:28:06.825736 IP 192.168.1.138 > 192.168.1.1: ICMP echo request, id 41845, seq 137, length 64
19:28:07.833735 IP 192.168.1.138 > 192.168.1.1: ICMP echo request, id 41845, seq 138, length 64
...
19:28:37.065730 IP 192.168.1.138 > 192.168.1.1: ICMP echo request, id 41845, seq 167, length 64
19:28:38.073719 IP 192.168.1.138 > 192.168.1.1: ICMP echo request, id 41845, seq 168, length 64
19:28:39.081734 IP 192.168.1.138 > 192.168.1.1: ICMP echo request, id 41845, seq 169, length 64
tcpdump: pcap_loop: critical revent in poll on packet socket fd 3: 0x0008
34 packets captured
34 packets received by filter
0 packets dropped by kernel
Das Ping-Signal wird aber nicht an bnep0 weiter gegeben:
tcpdump -i bnep0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on bnep0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:28:37.721799 IP 91.x.x.x > 192.168.20.3: ESP(spi=0x0cf896a0,seq=0xef), length 68
Nach ca. 30 sekunden wird das interface ppp0 beendet.
# /var/log/messages
...
Feb 6 19:09:18 oli4snotebook xl2tpd[29807]: Maximum retries exceeded for tunnel 48862. Closing.
Feb 6 19:10:13 oli4snotebook xl2tpd[29807]: Terminating pppd: sending TERM signal to pid 30021
Feb 6 19:10:13 oli4snotebook pppd[30021]: Terminating on signal 15
Feb 6 19:10:13 oli4snotebook pppd[30021]: Modem hangup
Feb 6 19:10:13 oli4snotebook pppd[30021]: Connect time 1.9 minutes.
Feb 6 19:10:13 oli4snotebook pppd[30021]: Sent 107872782 bytes, received 0 bytes.
Feb 6 19:10:13 oli4snotebook kernel: device ppp0 left promiscuous mode
Feb 6 19:10:13 oli4snotebook pppd[30021]: Script /etc/ppp/ip-down started (pid 30045)
Feb 6 19:10:13 oli4snotebook pppd[30021]: Connection terminated.
Feb 6 19:10:14 oli4snotebook pppd[30021]: Script /etc/ppp/ip-down finished (pid 30045), status = 0x0
Feb 6 19:10:14 oli4snotebook pppd[30021]: Exit.
Feb 6 19:10:14 oli4snotebook xl2tpd[29807]: pppd 30021 successfully terminated
Feb 6 19:10:14 oli4snotebook xl2tpd[29807]: Connection 17 closed to 91.x.x.x, port 1701 (Timeout)
Feb 6 19:10:18 oli4snotebook xl2tpd[29807]: get_call: can't find call 8874 in tunnel 48862
Feb 6 19:10:18 oli4snotebook xl2tpd[29807]: Unable to deliver closing message for tunnel 48862. Destroying anyway.
Feb 6 19:11:18 oli4snotebook xl2tpd[29807]: get_call: can't find call 8874 in tunnel 48862
Verstehe ich vielleicht an der Therorie noch nicht alles?
Der Tunnel müsste doch zwischen 192.168.20.3 (bnep0) und 9.x.x.x aufgebaut werden.
Und die Anfragen die an ppp0 geschickt werden, müssten doch
dann verschlüsselt über bnep0 gehen.
Oder nicht?
Als Routing-Option setze ich manuell
ip route add 192.168.1.0/24 dev ppp0. Ist das womöglich falsch?
Habe ich vielleicht noch was vergessen?
Gruß
Olivier | | RE: RE: RE: RE: RE: OpenSWAN Roadwarrior - Mac OS X Server V... | Ralf ( ---.46.63.221) | 7 Feb 2010 17:02 |
Grundsätzlich hast Du es verstanden. Aber ich denke, Deine Abhilfe ist an der falschen Stelle erfolgt. Ich habe hier zu wenig Informationen und im Moment auch zu wenig Zeit um mich tief reinzudenken, aber ich denke, dass es hilfreicher wäre, den L2TP dazu zu bringen, die richtigen IP-Adressen zu verwenden, anstatt den Tunnel dazu zu bringen, die falschen IP-Adressen zu transportieren. Immerhin gibt es ja wahrscheinlich dasselbe Problem auch auf der Gegenseite, oder?
Gruß,
Ralf |
[ Zurück ] Um ein neues Thema hinzu zu fügen müssen sie eingeloggt sein.
|
|
|
|
Welche Distribution verwenden Sie?
| |
|
|
|
17 Oct 2008: