[Openswan Users] Openswan 2.6.32 / xl2tpd not working with Windows XP
Jai Dhar
jdhar at fps-tech.net
Thu Jan 6 10:55:29 EST 2011
Lastly... I captured some network traffic in the XP working case
(targeting local IP, not router), XP not working and iPad working. The
traffic reveals that all 3 show some sort of ISAKMP handshake going on
at first. Between the iPad and the router, it goes between port 500
and 1 (on the iPad). Between XP and the server uses port 500.
The ESP traffic then flows on the iPad encapsulated in UDP using port
4500 on the server.
For XP, in the working case, the traffic is flowing non-encapsulated,
which I'm guessing is why it's not working since that can't go through
the router. Both the iPad and XP machines are on the same network, so
I would think the same NAT rules should apply. In the XP non-working
case, this is confirmed and I don't see any ESP traffic.
On Thu, Jan 6, 2011 at 7:32 AM, Jai Dhar <jdhar at fps-tech.net> wrote:
> ...some more information... I was able to get it to work by targeting
> the internal IP of the VPN server, as opposed to the external router.
> The internal IP is 192.168.1.200, and the External IP of the router is
> 24.6.221.176. If I set it to 192.186.1.200 it works. I believe I have
> the right ports opened, and as I mentioned it works with iPad (ports
> 1701, 500 and 4500).
>
> Here is the log when it works from XP:
>
>
> Jan 6 07:29:12 viammc pluto[18392]: packet from 192.168.1.201:500:
> ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
> Jan 6 07:29:12 viammc pluto[18392]: packet from 192.168.1.201:500:
> ignoring Vendor ID payload [FRAGMENTATION]
> Jan 6 07:29:12 viammc pluto[18392]: packet from 192.168.1.201:500:
> received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method
> set to=106
> Jan 6 07:29:12 viammc pluto[18392]: packet from 192.168.1.201:500:
> ignoring Vendor ID payload [Vid-Initial-Contact]
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #1: responding to Main Mode from unknown peer 192.168.1.201
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #1: STATE_MAIN_R1: sent MR1, expecting MI2
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no
> NAT detected
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #1: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #1: STATE_MAIN_R2: sent MR2, expecting MI3
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #1: Main mode peer ID is ID_IPV4_ADDR: '192.168.1.201'
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #1: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #1: STATE_MAIN_R3: sent MR3, ISAKMP SA established
> {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
> group=modp2048}
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #1: the peer proposed: 192.168.1.200/32:17/1701 ->
> 192.168.1.201/32:17/0
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #2: responding to Quick Mode proposal {msgid:c513f0af}
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #2: us: 192.168.1.200<192.168.1.200>[+S=C]:17/1701
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #2: them: 192.168.1.201[+S=C]:17/1701
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #2: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #2: STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting
> QI2
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #2: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
> Jan 6 07:29:12 viammc pluto[18392]: "L2TP-PSK-NAT"[1] 192.168.1.201
> #2: STATE_QUICK_R2: IPsec SA established transport mode
> {ESP=>0xcfcae264 <0x8776790e xfrm=3DES_0-HMAC_MD5 NATOA=none NATD=none
> DPD=none}
>
> One thing I notice different from the non-working log is the following line:
>
> netlink_raw_eroute: WARNING: that_client port 0 and that_host port
> 1701 don't match. Using that_client port.
>
> Any ideas?
>
> J
> On Wed, Jan 5, 2011 at 11:41 PM, Jai Dhar <jdhar at fps-tech.net> wrote:
>> I have my setup working with iPad/iPhone, but not XP. Here is the
>> working output from ipsec for the working session:
>>
>> Jan 5 23:17:34 viammc pluto[3598]: packet from 192.168.1.1:500:
>> received Vendor ID payload [RFC 3947] method set to=109
>> Jan 5 23:17:34 viammc pluto[3598]: packet from 192.168.1.1:500:
>> received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set
>> to=110
>> Jan 5 23:17:34 viammc pluto[3598]: packet from 192.168.1.1:500:
>> ignoring unknown Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
>> Jan 5 23:17:34 viammc pluto[3598]: packet from 192.168.1.1:500:
>> ignoring unknown Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
>> Jan 5 23:17:34 viammc pluto[3598]: packet from 192.168.1.1:500:
>> ignoring unknown Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
>> Jan 5 23:17:34 viammc pluto[3598]: packet from 192.168.1.1:500:
>> ignoring unknown Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
>> Jan 5 23:17:34 viammc pluto[3598]: packet from 192.168.1.1:500:
>> ignoring unknown Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
>> Jan 5 23:17:34 viammc pluto[3598]: packet from 192.168.1.1:500:
>> received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108,
>> but already using method 110
>> Jan 5 23:17:34 viammc pluto[3598]: packet from 192.168.1.1:500:
>> received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107,
>> but already using method 110
>> Jan 5 23:17:34 viammc pluto[3598]: packet from 192.168.1.1:500:
>> received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106,
>> but already using method 110
>> Jan 5 23:17:34 viammc pluto[3598]: packet from 192.168.1.1:500:
>> received Vendor ID payload [Dead Peer Detection]
>> Jan 5 23:17:34 viammc pluto[3598]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> responding to Main Mode from unknown peer 192.168.1.1
>> Jan 5 23:17:34 viammc pluto[3598]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
>> Jan 5 23:17:34 viammc pluto[3598]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> STATE_MAIN_R1: sent MR1, expecting MI2
>> Jan 5 23:17:35 viammc pluto[3598]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): both
>> are NATed
>> Jan 5 23:17:35 viammc pluto[3598]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
>> Jan 5 23:17:35 viammc pluto[3598]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> STATE_MAIN_R2: sent MR2, expecting MI3
>> Jan 5 23:17:35 viammc pluto[3598]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> ignoring informational payload, type IPSEC_INITIAL_CONTACT
>> msgid=00000000
>> Jan 5 23:17:35 viammc pluto[3598]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> Main mode peer ID is ID_IPV4_ADDR: '192.168.1.109'
>> Jan 5 23:17:35 viammc pluto[3598]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> switched from "L2TP-PSK-NAT" to "L2TP-PSK-NAT"
>> Jan 5 23:17:35 viammc pluto[3598]: "L2TP-PSK-NAT"[2] 192.168.1.1 #1:
>> deleting connection "L2TP-PSK-NAT" instance with peer 192.168.1.1
>> {isakmp=#0/ipsec=#0}
>> Jan 5 23:17:35 viammc pluto[3598]: "L2TP-PSK-NAT"[2] 192.168.1.1 #1:
>> transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
>> Jan 5 23:17:35 viammc pluto[3598]: "L2TP-PSK-NAT"[2] 192.168.1.1 #1:
>> new NAT mapping for #1, was 192.168.1.1:500, now 192.168.1.1:1024
>> Jan 5 23:17:35 viammc pluto[3598]: "L2TP-PSK-NAT"[2] 192.168.1.1 #1:
>> STATE_MAIN_R3: sent MR3, ISAKMP SA established
>> {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha
>> group=modp1024}
>> Jan 5 23:17:36 viammc pluto[3598]: "L2TP-PSK-NAT"[2] 192.168.1.1 #1:
>> the peer proposed: 24.6.221.176/32:17/1701 -> 192.168.1.109/32:17/0
>> Jan 5 23:17:36 viammc pluto[3598]: "L2TP-PSK-NAT"[2] 192.168.1.1 #2:
>> responding to Quick Mode proposal {msgid:a2d658cd}
>> Jan 5 23:17:36 viammc pluto[3598]: "L2TP-PSK-NAT"[2] 192.168.1.1 #2:
>> us: 192.168.1.200<192.168.1.200>[+S=C]:17/1701
>> Jan 5 23:17:36 viammc pluto[3598]: "L2TP-PSK-NAT"[2] 192.168.1.1 #2:
>> them: 192.168.1.1[192.168.1.109,+S=C]:17/52181===192.168.1.109/32
>> Jan 5 23:17:36 viammc pluto[3598]: "L2TP-PSK-NAT"[2] 192.168.1.1 #2:
>> transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
>> Jan 5 23:17:36 viammc pluto[3598]: "L2TP-PSK-NAT"[2] 192.168.1.1 #2:
>> STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
>> Jan 5 23:17:36 viammc pluto[3598]: "L2TP-PSK-NAT"[2] 192.168.1.1 #2:
>> transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
>> Jan 5 23:17:36 viammc pluto[3598]: "L2TP-PSK-NAT"[2] 192.168.1.1 #2:
>> STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0x01b6135a
>> <0xaebdad31 xfrm=AES_256-HMAC_SHA1 NATOA=none NATD=192.168.1.1:1024
>> DPD=none}
>>
>> ----------
>>
>> Here is the non-working XP client:
>> Jan 5 22:40:05 viammc pluto[31255]: packet from 192.168.1.1:500:
>> ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
>> Jan 5 22:40:05 viammc pluto[31255]: packet from 192.168.1.1:500:
>> ignoring Vendor ID payload [FRAGMENTATION]
>> Jan 5 22:40:05 viammc pluto[31255]: packet from 192.168.1.1:500:
>> received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method
>> set to=106
>> Jan 5 22:40:05 viammc pluto[31255]: packet from 192.168.1.1:500:
>> ignoring Vendor ID payload [Vid-Initial-Contact]
>> Jan 5 22:40:05 viammc pluto[31255]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> responding to Main Mode from unknown peer 192.168.1.1
>> Jan 5 22:40:05 viammc pluto[31255]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
>> Jan 5 22:40:05 viammc pluto[31255]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> STATE_MAIN_R1: sent MR1, expecting MI2
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: both are
>> NATed
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> STATE_MAIN_R2: sent MR2, expecting MI3
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> Main mode peer ID is ID_FQDN: '@vialaptop'
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[1] 192.168.1.1 #1:
>> switched from "L2TP-PSK-NAT" to "L2TP-PSK-NAT"
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[2] 192.168.1.1 #1:
>> deleting connection "L2TP-PSK-NAT" instance with peer 192.168.1.1
>> {isakmp=#0/ipsec=#0}
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[2] 192.168.1.1 #1:
>> transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[2] 192.168.1.1 #1:
>> new NAT mapping for #1, was 192.168.1.1:500, now 192.168.1.1:4500
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[2] 192.168.1.1 #1:
>> STATE_MAIN_R3: sent MR3, ISAKMP SA established
>> {auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
>> group=modp2048}
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[2] 192.168.1.1 #1:
>> peer client type is FQDN
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[2] 192.168.1.1 #1:
>> Applying workaround for MS-818043 NAT-T bug
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[2] 192.168.1.1 #1:
>> IDci was FQDN: \030\006\335\260, using NAT_OA=192.168.1.108/32 0 as
>> IDci
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[2] 192.168.1.1 #1:
>> the peer proposed: 24.6.221.176/32:17/1701 -> 192.168.1.108/32:17/0
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[2] 192.168.1.1 #2:
>> responding to Quick Mode proposal {msgid:6e496c91}
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[2] 192.168.1.1 #2:
>> us: 192.168.1.200<192.168.1.200>[+S=C]:17/1701
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[2] 192.168.1.1 #2:
>> them: 192.168.1.1[@vialaptop,+S=C]:17/1701===192.168.1.108/32
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[2] 192.168.1.1 #2:
>> transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[2] 192.168.1.1 #2:
>> STATE_QUICK_R1: sent QR1, inbound IPsec SA installed, expecting QI2
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[2] 192.168.1.1 #2:
>> netlink_raw_eroute: WARNING: that_client port 0 and that_host port
>> 1701 don't match. Using that_client port.
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[2] 192.168.1.1 #2:
>> transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
>> Jan 5 22:40:06 viammc pluto[31255]: "L2TP-PSK-NAT"[2] 192.168.1.1 #2:
>> STATE_QUICK_R2: IPsec SA established transport mode {ESP=>0x96a05f3a
>> <0x59e7df1b xfrm=3DES_0-HMAC_MD5 NATOA=192.168.1.108
>> NATD=192.168.1.1:4500 DPD=none}
>>
>>
>> In XP, I have set it to IPSEC L2TP and MSCHAP-v2.
>>
>> Lastly, when I run xl2tpd in non-daemon mode with xl2tpd -D, there is
>> no output shown for the non-working XP case. For the iPad, I see the
>> connection established and PPPD started, but nothing happens with XP.
>>
>> This is done on a double-NAT setup, with both the server and client on
>> the same subnet behind the same router for testing.
>>
>> --
>> Jai Dhar
>> FPS-Tech, Santa Clara, CA
>> Web: http://www.fps-tech.net
>> Phone: 408-982-7407
>>
>
>
>
> --
> Jai Dhar
> FPS-Tech, Santa Clara, CA
> Web: http://www.fps-tech.net
> Phone: 408-982-7407
>
--
Jai Dhar
FPS-Tech, Santa Clara, CA
Web: http://www.fps-tech.net
Phone: 408-982-7407
More information about the Users
mailing list