我已使用在 CentOS 上运行的 OpenSwan 2.6.38 成功安装了 L2TP over IPsec VPN（PSK）。
在 Windows 8 中 Connect 确实可以完美运行。
但在 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 规则，因为 Win 8 客户端工作正常。
我找不到任何针对 Android 和 iPhone 的解决方案。
答案1
我遇到了类似的问题。配置文件中有一条线索：
# 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
我发现，只有设置为 17/0 时，rightprotoport 设置才适用于 iPhone 客户端。设置 17/%any 对我来说不起作用。