L2TP sobre VPN IPSec (OpenSwan, CentOS 6) incapaz de se conectar via iPhone (iOS 5.1) e Android (JellyBean)

Question

Instalei com sucesso o L2TP através de VPN IPsec (PSK) usando o OpenSwan 2.6.38 em execução no CentOS.

Conecte-se DOES WORK perfeitamente ao Windows 8.

Mas não funciona AT ALL do iPhone 4 (ios 5.1) ou Android 4.1 - falha com erros "servidor VPN não responde / esgotado".

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

log:

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

Eu não forneço as regras do iptables porque o trabalho do cliente do Win 8 é bom.

Não consegui encontrar QUALQUER solução para Android e iPhone.

    

Answer 1

Eu tive um problema semelhante. Existe uma pista no arquivo de configuração:

    # 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

Descobri que a configuração rightprotoport funciona para clientes do iPhone somente se configurada para 17/0. A configuração 17 /% qualquer não funcionou para mim.