[Openswan Users]

[Paul Wouters]

On Wed, 13 Jul 2005, Siegfried Fischler wrote:

> Can you point me to the WinXP patch fixing the port issue. I did apply to
> the XP machine in question the registry modification found in the file
> FixSP2VPN.vbs (AssumeUDPEncapsulationContextOnSendRule is set to value "2").
>
> Ok, let's patch XP. I will apply SP2. If this is the wrong thing to do
> please let me know.

The patch is a post SP2 "recommended update" you get using Windows Update
I believe. Perhaps it is part of SP2 and only a seperate update on 2000.
Jacco's pages have the details.

> conn roadwarrior
> 	left=%defaultroute
> 	leftcert=pegasuscert.pem
> 	right=%any
> 	rightsubnet=vhost:%no,%priv
> 	auto=add
> 	pfs=yes
>
> conn roadwarrior-l2tp
> 	leftprotoport=17/1701
> 	rightprotoport=17/1701
> 	rightca=%same
> 	compress=no
> 	pfs=no
> 	also=roadwarrior

Do not use multiple conns with practically the same values, as openswan
cannot distinguish between them in time for phase 1.
Use 17/%any in 1 conn

> After patching the log messages changed dramatically:
> Jul 13 21:00:29 pegasus pluto[11445]: packet from 213.3.166.74:500: ignoring
> Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
> Jul 13 21:00:29 pegasus pluto[11445]: packet from 213.3.166.74:500: ignoring
> Vendor ID payload [FRAGMENTATION]
> Jul 13 21:00:29 pegasus pluto[11445]: packet from 213.3.166.74:500: received
> Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
> Jul 13 21:00:29 pegasus pluto[11445]: packet from 213.3.166.74:500: ignoring
> Vendor ID payload [Vid-Initial-Contact]
> Jul 13 21:00:29 pegasus pluto[11445]: "roadwarrior"[3] 213.3.166.74 #3:
> responding to Main Mode from unknown peer 213.3.166.74
> Jul 13 21:00:29 pegasus pluto[11445]: "roadwarrior"[3] 213.3.166.74 #3:
> transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Jul 13 21:00:29 pegasus pluto[11445]: "roadwarrior"[3] 213.3.166.74 #3:
> NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: i am NATed
> Jul 13 21:00:29 pegasus pluto[11445]: "roadwarrior"[3] 213.3.166.74 #3:
> transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
> Jul 13 21:00:30 pegasus pluto[11445]: "roadwarrior"[3] 213.3.166.74 #3: Main
> mode peer ID is ID_DER_ASN1_DN: 'C=xx, ST=xxx, L=xxx, O=xxx, OU=xx, CN=xxx,
> E=xxx'
> Jul 13 21:00:30 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3:
> deleting connection "roadwarrior" instance with peer 213.3.166.74
> {isakmp=#0/ipsec=#0}
> Jul 13 21:00:30 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3: I am
> sending my cert
> Jul 13 21:00:30 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3:
> transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Jul 13 21:00:30 pegasus pluto[11445]: | NAT-T: new mapping
> 213.3.166.74:500/4500)
> Jul 13 21:00:30 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3: sent
> MR3, ISAKMP SA established
> Jul 13 21:00:30 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3:
> retransmitting in response to duplicate packet; already STATE_MAIN_R3
> Jul 13 21:00:31 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #4: we
> require PFS but Quick I1 SA specifies no GROUP_DESCRIPTION

Yes. The mixup is between the non-l2tp and the l2tp connection. I suggest
you disable the "roadwarrior" conn while testing l2tp.

> Jul 13 21:00:31 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #4:
> failed to build notification for spisize=0

Fixed in 2.4.0dr3 an hour ago (but non fatal for you)

> Now it looks I got on step further, but I am still lost. This configuration
> is really the most painful exercise I ever came accross on Linux...

Be glad you weren't here a few years ago :)

Paul