我已经使用在CentOS上运行的OpenSwan 2.6.38成功安装了基于IPsec VPN（PSK）的L2TP。
连接可以从Windows 8完美工作。
但从iPhone 4（ios 5.1）或Android 4.1的全部不起作用 – 失败，错误“VPN服务器不响应/超时”。
ipsec.conf文件：
config setup protostack=klips nat_traversal=yes virtual_private=%v4:0.0.0.0/0,%v4:!1.0.0.0/24 oe=off interfaces=%defaultroute uniqueids=yes conn %default keyingtries=1 compress=no disablearrivalcheck=no authby=secret conn L2TP-WIN_N leftprotoport=17/1701 rightprotoport=17/1701 also=L2TP-PSK conn L2TP leftprotoport=17/0 rightprotoport=17/1701 also=L2TP-PSK conn L2TP-MAC leftprotoport=17/1701 rightprotoport=17/%any also=L2TP-PSK conn L2TP-PSK auto=add pfs=no rekey=no ikev2=never dpddelay=10 dpdtimeout=90 dpdaction=clear ikelifetime=8h keylife=1h type=transport left=EXTERNAL_SERV_IP right=%any rightsubnet=vhost:%priv conn passthrough-for-non-l2tp type=passthrough left=EXTERNAL_SERV_IP leftnexthop=%defaultroute right=%any auto=route 日志：
Dec 31 11:36:53 uapeer pluto[20894]: packet from 31.42.69.*:500: received Vendor ID payload [RFC 3947] method set to=115 Dec 31 11:36:53 uapeer pluto[20894]: packet from 31.42.69.*:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] meth=114, but already using method 115 Dec 31 11:36:53 uapeer pluto[20894]: packet from 31.42.69.*:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-08] meth=113, but already using method 115 Dec 31 11:36:53 uapeer pluto[20894]: packet from 31.42.69.*:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-07] meth=112, but already using method 115 Dec 31 11:36:53 uapeer pluto[20894]: packet from 31.42.69.*:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-06] meth=111, but already using method 115 Dec 31 11:36:53 uapeer pluto[20894]: packet from 31.42.69.*:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-05] meth=110, but already using method 115 Dec 31 11:36:53 uapeer pluto[20894]: packet from 31.42.69.*:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-04] meth=109, but already using method 115 Dec 31 11:36:53 uapeer pluto[20894]: packet from 31.42.69.*:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 115 Dec 31 11:36:53 uapeer pluto[20894]: packet from 31.42.69.*:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 115 Dec 31 11:36:53 uapeer pluto[20894]: packet from 31.42.69.*:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 115 Dec 31 11:36:53 uapeer pluto[20894]: packet from 31.42.69.*:500: received Vendor ID payload [Dead Peer Detection] Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: responding to Main Mode from unknown peer 31.42.69.* Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1 Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: STATE_MAIN_R1: sent MR1, expecting MI2 Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): peer is NATed Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2 Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: STATE_MAIN_R2: sent MR2, expecting MI3 Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: ignoring informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000 Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: Main mode peer ID is ID_IPV4_ADDR: '192.168.0.202' Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[4] 31.42.69.* #5: switched from "L2TP-WIN_N" to "L2TP-WIN_N" Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[5] 31.42.69.* #5: deleting connection "L2TP-WIN_N" instance with peer 31.42.69.* {isakmp=#0/ipsec=#0} Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[5] 31.42.69.* #5: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3 Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[5] 31.42.69.* #5: new NAT mapping for #5, was 31.42.69.*:500, now 31.42.69.*:4500 Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[5] 31.42.69.* #5: STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha group=modp1024} Dec 31 11:36:53 uapeer pluto[20894]: "L2TP-WIN_N"[5] 31.42.69.* #5: Dead Peer Detection (RFC 3706): enabled Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-WIN_N"[5] 31.42.69.* #5: the peer proposed: 178.63.149.*/32:17/1701 -> 192.168.0.202/32:17/1701 Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-WIN_N"[5] 31.42.69.* #5: NAT-Traversal: received 2 NAT-OA. using first, ignoring others Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-MAC"[2] 31.42.69.* #6: responding to Quick Mode proposal {msgid:3ed534a0} Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-MAC"[2] 31.42.69.* #6: us: 178.63.149.*<178.63.149.*>:17/1701 Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-MAC"[2] 31.42.69.* #6: them: 31.42.69.*[192.168.0.202]:17/57118===192.168.0.202/32 Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-MAC"[2] 31.42.69.* #6: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1 Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-MAC"[2] 31.42.69.* #6: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2 Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-MAC"[2] 31.42.69.* #6: Dead Peer Detection (RFC 3706): enabled Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-MAC"[2] 31.42.69.* #6: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2 Dec 31 11:36:54 uapeer pluto[20894]: "L2TP-MAC"[2] 31.42.69.* #6: STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0x03d13d42 <0xae30f2d7 xfrm=AES_256-HMAC_SHA1 NATOA=192.168.0.202 NATD=31.42.69.*:4500 DPD=enabled} Dec 31 11:37:15 uapeer pluto[20894]: ERROR: asynchronous network error report on eth0 (sport=4500) for message to 31.42.69.* port 4500, complainant 31.42.69.*: Connection refused [errno 111, origin ICMP type 3 code 3 (not authenticated)]
我不提供iptables规则，因为赢8客户端工作正常。
我找不到适用于Android和iPhone的任何解决scheme。
我有一个类似的问题。 有一个线索在configuration文件中：
# Using the magic port of "0" means "any one single port". This is # a work around required for Apple OSX clients that use a randomly # high port, but propose "0" instead of their port. If this does # not work, use 17/%any instead. rightprotoport=17/0 #rightprotoport=17/%any
我发现rightprotoport设置只适用于iPhone客户端设置为17/0。 设置17 /％任何不适合我。