
Ich habe den Morgen damit verbracht, ein L2TP/IPsec-VPN mit Openswan und xl2tpd auf einem Debian Squeeze-Server für die Verwendung durch eine Mischung aus iOS- und Mac-Clients zu konfigurieren. Ich versuche, es mit vorinstallierten Schlüsseln einzurichten, um die Dinge einfach zu halten.
Das iPhone stellt eine Verbindung her und beginnt mit der Einrichtung des VPN, bleibt dann aber hängen und schlägt auf halbem Weg fehl. Ich kann das Problem nicht herausfinden, nachdem ich viele Parameter verändert und alles doppelt überprüft habe.
Hier ist die letzte Protokollnachricht, /var/log/auth.log
bevor es hängen blieb:
pluto[30733]: "L2TP-PSK"[5] 166.147.96.226 #5: STATE_QUICK_R2: IPsec SA established tunnel mode {ESP=>0x0659cf9f <0xc3c2f68c xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=166.147.96.226:10682 DPD=enabled}
Etwa 30 Sekunden später gibt das iPhone auf und Folgendes wird angezeigt auth.log
:
pluto[30733]: ERROR: asynchronous network error report on br1 (sport=4500) for message to 166.147.96.226 port 10682, complainant 166.147.96.226: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
Was bedeutet das? Kann der Server den Client nicht kontaktieren oder kann der Client keine weitere Verbindung aufbauen und gibt diesen Fehler an die IPsec-Verbindung weiter, die er aufbauen könnte?
Leider teste ich dies mit dem iPhone im Mobilfunknetz von AT&T, da ich mich innerhalb des WLAN-Netzwerks befinde, in dem ich das VPN einrichten möchte. Blockiert AT&T VPN-Verkehr?
Ich weiß, dass die IPsec-Authentifizierung funktioniert, weil /etc/ipsec.secrets
die Verbindung viel schneller fehlschlägt, wenn ich die Zeile ändere oder entferne, und ich diese Protokollzeilen nicht sehe.
Ich glaube, die Firewall lässt die UDP-Ports 500 und 4500 sowie das ESP-Protokoll zu, denn wenn ich diese blockiere, bricht die Verbindung wieder viel schneller ab.
/etc/ipsec.conf
Anschlussbereich:
conn L2TP-PSK
authby=secret
pfs=no
rekey=no
keyingtries=3
dpddelay=30
dpdtimeout=120
dpdaction=clear
compress=yes
left=%defaultroute
leftprotoport=udp/1701
right=%any
rightprotoport=udp/0
auto=add
/etc/ipsec.secrets
VPN-SERVER-PUBLIC-IP %any: PSK "mysecretishere"
/etc/xl2tpd/xl2tpd.conf
[global] ; Global parameters:
access control = no
rand source = dev
[lns default] ; Our fallthrough LNS definition
ip range = 192.168.1.120-192.168.1.127
local ip = 192.168.1.119
require chap = yes
refuse pap = no
require authentication = yes
name = LinuxVPNserver
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tp
length bit = yes
/etc/ppp/options.l2tp
ipcp-accept-local
ipcp-accept-remote
ms-dns 192.168.1.1
noccp
auth
crtscts
idle 1800
mtu 1410
mru 1410
nodefaultroute
debug
lock
proxyarp
connect-delay 5000
plugin pppol2tp.so
require-mschap-v2
Antwort1
AT&T scheintBlockieren eingehender UDP-Pakete(lässt sie nicht durch das NAT), daher wird es sehr schwierig sein, L2TP/IPsec einzurichten. Ich glaube, Sie müssen auf PPTP zurückgreifen.
Antwort2
Dieser Fehler ist Ihr Hinweis.
ERROR: asynchronous network error report on br1 (sport=4500) for message to 166.147.96.226 port 10682, complainant 166.147.96.226: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)
Ich habe das schon einmal gesehen und jedes Mal liegt es daran, dass entweder der Host-Server oder das Netzwerk/die Firewall des Remote-Clients die IPSec-Pakete blockiert. Wenn es sich um eine benutzergesteuerte Firewall oder einen Router handelt, ist dies eine einfache Lösung (IPSEC aktivieren), aber wenn Sie es nicht selbst steuern können, haben Sie Pech gehabt und müssen ein anderes Protokoll verwenden. Manche sagen, man solle left=17/%any ändern, aber das hat bei mir nie funktioniert (in seltenen Fällen ist die Client-Seite vielleicht schlau und versucht, einen anderen Port zu verwenden, der möglicherweise nicht blockiert ist).