Openswan L2TP/IPsec VPN für iPhone schlägt während der Verbindung fehl

Openswan L2TP/IPsec VPN für iPhone schlägt während der Verbindung fehl

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.logbevor 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.secretsdie 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.confAnschlussbereich:

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).

verwandte Informationen