[Openswan Users]

Siegfried Fischler siegfried.fischler2 at bluewin.ch
Thu Jul 14 19:45:22 CEST 2005 

Paul,

I can now connect to the openswan server sitting behind a dsl doing nat-t
when using a WinXP client dialing via a modem into the internet and
establishing a session to the server. here is my openswan configuration:

config setup
	interfaces=%defaultroute
	nat_traversal=yes
	virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v!4:19
2.168.0.0/24

# Add connections here
conn %default
	keyingtries=1
	compress=yes
	disablearrivalcheck=no
	authby=rsasig
	leftrsasigkey=%cert
	rightrsasigkey=%cert

conn roadwarrior-net
	leftsubnet=192.168.1.0/24
	also=roadwarrior

conn roadwarrior-all
	leftsubnet=0.0.0.0
	also=roadwarrior

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

conn roadwarrior-l2tp-oldwin
	leftprotoport=17/0
	rightprotoport=17/1701
	rightca=%same
	compress=no
	pfs=no
	also=roadwarrior

conn block
	auto=ignore

conn private
	auto=ignore

conn private-or-clear
	auto=ignore

conn clear-or-private
	auto=ignore

conn clear
	auto=ignore

conn packetdefault
	auto=ignore

and now the log showing in the first part the WinXP client session when
dialing-up into the internet and in the second using a client as well behind
a dsl device and during the second session, the client shows the error
message 678

===== PART 1 ====
Jul 14 16:30:26 pegasus pluto[4123]: packet from 62.202.193.231:500:
ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
Jul 14 16:30:26 pegasus pluto[4123]: packet from 62.202.193.231:500:
ignoring Vendor ID payload [FRAGMENTATION]
Jul 14 16:30:26 pegasus pluto[4123]: packet from 62.202.193.231:500:
received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set
to=106
Jul 14 16:30:26 pegasus pluto[4123]: packet from 62.202.193.231:500:
ignoring Vendor ID payload [Vid-Initial-Contact]
Jul 14 16:30:26 pegasus pluto[4123]: "roadwarrior-l2tp"[9] 62.202.193.231
#9: responding to Main Mode from unknown peer 62.202.193.231
Jul 14 16:30:26 pegasus pluto[4123]: "roadwarrior-l2tp"[9] 62.202.193.231
#9: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Jul 14 16:30:27 pegasus pluto[4123]: "roadwarrior-l2tp"[9] 62.202.193.231
#9: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: i am NATed
Jul 14 16:30:27 pegasus pluto[4123]: "roadwarrior-l2tp"[9] 62.202.193.231
#9: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Jul 14 16:30:28 pegasus pluto[4123]: "roadwarrior-l2tp"[9] 62.202.193.231
#9: Main mode peer ID is ID_DER_ASN1_DN: 'C=xx, ST=xxx, L=xxx, O=xxx, OU=xx,
CN=xxx, E=xxx'
Jul 14 16:30:28 pegasus pluto[4123]: "roadwarrior-l2tp"[10] 62.202.193.231
#9: deleting connection "roadwarrior-l2tp" instance with peer 62.202.193.231
{isakmp=#0/ipsec=#0}
Jul 14 16:30:28 pegasus pluto[4123]: "roadwarrior-l2tp"[10] 62.202.193.231
#9: I am sending my cert
Jul 14 16:30:28 pegasus pluto[4123]: "roadwarrior-l2tp"[10] 62.202.193.231
#9: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Jul 14 16:30:28 pegasus pluto[4123]: | NAT-T: new mapping
62.202.193.231:500/4500)
Jul 14 16:30:28 pegasus pluto[4123]: "roadwarrior-l2tp"[10] 62.202.193.231
#9: sent MR3, ISAKMP SA established
Jul 14 16:30:28 pegasus pluto[4123]: "roadwarrior-l2tp"[10] 62.202.193.231
#9: retransmitting in response to duplicate packet; already STATE_MAIN_R3
Jul 14 16:30:28 pegasus pluto[4123]: "roadwarrior-l2tp"[10] 62.202.193.231
#10: responding to Quick Mode {msgid:487f7730}
Jul 14 16:30:28 pegasus pluto[4123]: "roadwarrior-l2tp"[10] 62.202.193.231
#10: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Jul 14 16:30:29 pegasus pluto[4123]: "roadwarrior-l2tp"[10] 62.202.193.231
#10: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Jul 14 16:30:29 pegasus pluto[4123]: "roadwarrior-l2tp"[10] 62.202.193.231
#10: IPsec SA established {ESP=>0xe104f9b6 <0x4bbeeff4 xfrm=3DES_0-HMAC_MD5
NATD=62.202.193.231}
Jul 14 16:31:37 pegasus pluto[4123]: "roadwarrior-l2tp"[10] 62.202.193.231
#9: received Delete SA(0xe104f9b6) payload: deleting IPSEC State #10
Jul 14 16:31:37 pegasus pluto[4123]: "roadwarrior-l2tp"[10] 62.202.193.231
#9: received and ignored informational message
Jul 14 16:31:37 pegasus pluto[4123]: "roadwarrior-l2tp"[10] 62.202.193.231
#9: received Delete SA payload: deleting ISAKMP State #9
Jul 14 16:31:37 pegasus pluto[4123]: "roadwarrior-l2tp"[10] 62.202.193.231:
deleting connection "roadwarrior-l2tp" instance with peer 62.202.193.231
{isakmp=#0/ipsec=#0}
Jul 14 16:31:37 pegasus pluto[4123]: packet from 62.202.193.231:4500:
received and ignored informational message
===== PART 2 ====
Jul 14 16:50:39 pegasus pluto[4123]: packet from 81.178.179.13:500: ignoring
Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
Jul 14 16:50:39 pegasus pluto[4123]: packet from 81.178.179.13:500: ignoring
Vendor ID payload [FRAGMENTATION]
Jul 14 16:50:39 pegasus pluto[4123]: packet from 81.178.179.13:500: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
Jul 14 16:50:39 pegasus pluto[4123]: packet from 81.178.179.13:500: ignoring
Vendor ID payload [Vid-Initial-Contact]
Jul 14 16:50:39 pegasus pluto[4123]: "roadwarrior-l2tp"[11] 81.178.179.13
#11: responding to Main Mode from unknown peer 81.178.179.13
Jul 14 16:50:39 pegasus pluto[4123]: "roadwarrior-l2tp"[11] 81.178.179.13
#11: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Jul 14 16:50:39 pegasus pluto[4123]: "roadwarrior-l2tp"[11] 81.178.179.13
#11: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: both are
NATed
Jul 14 16:50:39 pegasus pluto[4123]: "roadwarrior-l2tp"[11] 81.178.179.13
#11: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Jul 14 16:50:39 pegasus pluto[4123]: "roadwarrior-l2tp"[11] 81.178.179.13
#11: Main mode peer ID is ID_DER_ASN1_DN: 'C=xx, ST=xxx, L=xxx, O=xxx,
OU=xx, CN=xxx, E=xxx'
Jul 14 16:50:39 pegasus pluto[4123]: "roadwarrior-l2tp"[12] 81.178.179.13
#11: deleting connection "roadwarrior-l2tp" instance with peer 81.178.179.13
{isakmp=#0/ipsec=#0}
Jul 14 16:50:39 pegasus pluto[4123]: "roadwarrior-l2tp"[12] 81.178.179.13
#11: I am sending my cert
Jul 14 16:50:39 pegasus pluto[4123]: "roadwarrior-l2tp"[12] 81.178.179.13
#11: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Jul 14 16:50:39 pegasus pluto[4123]: | NAT-T: new mapping
81.178.179.13:500/1166)
Jul 14 16:50:39 pegasus pluto[4123]: "roadwarrior-l2tp"[12] 81.178.179.13
#11: sent MR3, ISAKMP SA established
Jul 14 16:50:39 pegasus pluto[4123]: "roadwarrior-l2tp"[12] 81.178.179.13
#12: responding to Quick Mode {msgid:2251f8c3}
Jul 14 16:50:39 pegasus pluto[4123]: "roadwarrior-l2tp"[12] 81.178.179.13
#12: transition from state STATE_QUICK_R0 to state STATE_QUICK_R1
Jul 14 16:50:40 pegasus pluto[4123]: "roadwarrior-l2tp"[12] 81.178.179.13
#12: transition from state STATE_QUICK_R1 to state STATE_QUICK_R2
Jul 14 16:50:40 pegasus pluto[4123]: "roadwarrior-l2tp"[12] 81.178.179.13
#12: IPsec SA established {ESP=>0x63a0884b <0x4bbeeff5 xfrm=3DES_0-HMAC_MD5
NATD=81.178.179.13}
Jul 14 16:51:15 pegasus pluto[4123]: "roadwarrior-l2tp"[12] 81.178.179.13
#11: received Delete SA(0x63a0884b) payload: deleting IPSEC State #12
Jul 14 16:51:15 pegasus pluto[4123]: "roadwarrior-l2tp"[12] 81.178.179.13
#11: received and ignored informational message
Jul 14 16:51:15 pegasus pluto[4123]: "roadwarrior-l2tp"[12] 81.178.179.13
#11: received Delete SA payload: deleting ISAKMP State #11
Jul 14 16:51:15 pegasus pluto[4123]: "roadwarrior-l2tp"[12] 81.178.179.13:
deleting connection "roadwarrior-l2tp" instance with peer 81.178.179.13
{isakmp=#0/ipsec=#0}
Jul 14 16:51:15 pegasus pluto[4123]: packet from 81.178.179.13:1166:
received and ignored informational message

Note that in Part 1 of the log, pluto says that port 500 is mapped to 4500
(which is what i expected) and in the second the port 500 is mapped to port
1166??? I used the microsoft port query tool to check if port 4500 is
already in use but the tool confirmed that this port was available!
Jul 14 16:30:28 pegasus pluto[4123]: | NAT-T: new mapping
62.202.193.231:500/4500)
Jul 14 16:50:39 pegasus pluto[4123]: | NAT-T: new mapping
81.178.179.13:500/1166)

During both sessions I did not restart the ipsec nor l2tp service, thus both
were running. I tested twice the WinXP client behind the dsl device and I
got twice the same strange port mapping (i.e. NAT-T: new mapping
81.178.179.13:500/1166)

Can you figure out the problem?

Thanks!!!!

Sigi
-----Original Message-----
From: users-bounces at openswan.org [mailto:users-bounces at openswan.org]On
Behalf Of Siegfried Fischler
Sent: Mittwoch, 13. Juli 2005 21:29
To: Paul Wouters
Cc: users at openswan.org
Subject: RE: Re: [Openswan Users]


All right Paul,

You give me hope we the fact that you managed to configure openswan
properly!

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.

I used this time the configuration Jacco recommended:
config setup
	interfaces=%defaultroute
	nat_traversal=yes
	virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16

conn %default
	keyingtries=1
	compress=yes
	disablearrivalcheck=no
	authby=rsasig
	leftrsasigkey=%cert
	rightrsasigkey=%cert

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

conn roadwarrior-l2tp-oldwin
	leftprotoport=17/0
	rightprotoport=17/1701
	rightca=%same
	compress=no
	pfs=no
	also=roadwarrior

conn block
	auto=ignore

conn private
	auto=ignore

conn private-or-clear
	auto=ignore

conn clear-or-private
	auto=ignore

conn clear
	auto=ignore

conn packetdefault
	auto=ignore

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
Jul 13 21:00:31 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #4:
sending encrypted notification NO_PROPOSAL_CHOSEN to 213.3.166.74:4500
Jul 13 21:00:31 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #4:
failed to build notification for spisize=0
Jul 13 21:00:32 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3:
Quick Mode I1 message is unacceptable because it uses a previously used
Message ID 0xd48058a0 (perhaps this is a duplicated packet)
Jul 13 21:00:32 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3:
sending encrypted notification INVALID_MESSAGE_ID to 213.3.166.74:4500
Jul 13 21:00:32 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3:
failed to build notification for spisize=0
Jul 13 21:00:34 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3:
Quick Mode I1 message is unacceptable because it uses a previously used
Message ID 0xd48058a0 (perhaps this is a duplicated packet)
Jul 13 21:00:34 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3:
sending encrypted notification INVALID_MESSAGE_ID to 213.3.166.74:4500
Jul 13 21:00:34 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3:
failed to build notification for spisize=0
Jul 13 21:00:38 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3:
Quick Mode I1 message is unacceptable because it uses a previously used
Message ID 0xd48058a0 (perhaps this is a duplicated packet)
Jul 13 21:00:38 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3:
sending encrypted notification INVALID_MESSAGE_ID to 213.3.166.74:4500
Jul 13 21:00:38 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3:
failed to build notification for spisize=0
Jul 13 21:00:46 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3:
Quick Mode I1 message is unacceptable because it uses a previously used
Message ID 0xd48058a0 (perhaps this is a duplicated packet)
Jul 13 21:00:46 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3:
sending encrypted notification INVALID_MESSAGE_ID to 213.3.166.74:4500
Jul 13 21:00:46 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3:
failed to build notification for spisize=0
Jul 13 21:00:51 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74 #3:
received Delete SA payload: deleting ISAKMP State #3
Jul 13 21:00:51 pegasus pluto[11445]: "roadwarrior"[4] 213.3.166.74:
deleting connection "roadwarrior" instance with peer 213.3.166.74
{isakmp=#0/ipsec=#0}
Jul 13 21:00:51 pegasus pluto[11445]: packet from 213.3.166.74:4500:
received and ignored informational message

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...

Cheers,

Sigi
-----Original Message-----
From: users-bounces at openswan.org [mailto:users-bounces at openswan.org]On
Behalf Of Paul Wouters
Sent: Mittwoch, 13. Juli 2005 16:54
To: Siegfried Fischler
Cc: users at openswan.org
Subject: RE: Re: [Openswan Users]


On Wed, 13 Jul 2005, Siegfried Fischler wrote:

> I was aware that 17/0 L2TP port request is "the old fashion" way, but I
> don't wanted to work on too many "issues" at the same time. I believe that

Unfortunately, you can't just ignore one problem and tackle your other
problem.

> the log message "cannot respond to IPsec SA request because no connection
is
> known for <any dynamic IP adr of internet router>/32===<static IP adr of
> openswan server>[certificate related blahblah]:17/0...<any dynamic IP adr
> for roadwarrior>[certificate related blahblah]:17/1701" is the key to
solve
> this issue. I realised that many other user's do have the same problem...

Yes, unfortunately, that error means about as much as "something, somewhere
has
been misconfigured somehow".

> I tested your proposal without luck. The very same log message keeps on
> coming up. Note that "17/%any" did not work at all with the openswan 2.3.1
> installed on the test server,

How did it not work? Did it accept it? Openswan 2.3.1 should accept the
syntax,
and you should leave it in, and not change it for 17/0.

> log just shows that pluto is using "roadwarrior-l2tp" connection settings.
> Please find below all the log messages for the trial ipsec/l2tp session
> attempt:

Is it the only conn you have added?

> # Down below is the unsuccessful connection attempt from a dial-up WinXP
> roadwarrior, recorded until WinXP shows "error 792".
> # Note that
> # 62.202.193.205 is the dynamic WinXP client IP address
> # 81.62.18.37 is the dynamic DSL router IP address, which connects the
> openswan server to the internet
> # 192.210.210.2 is the static openswan server IP address

Your openswan server is behind NAT??
Did you apply the registry hack for making Windows XP SP2 and higher accept
connections to VPN servers behind NAT? You might not need it now, since
you are using an unpatched Windows XP client (hence the 17/0 problem) but
as soon as you upgrade the XP machine, you will need it.

> Jul 13 11:50:08 pegasus pluto[14038]: "roadwarrior-l2tp"[2] 62.202.193.205
> #1: cannot respond to IPsec SA request because no connection is known for
> 81.62.18.37/32===195.210.210.2[C=xx, ST=xxx, L=xxx, O=xxx, OU=xx, CN=xxx,
> E=xxx]:17/0...62.202.193.205[C=xx, ST=xxx, L=xxx, O=xxx, OU=xx, CN=xxx,
> E=xxx]:17/1701

Did you have rightsubnet=vhost:%priv.%no? (If you get an error about
transport
mode and subnet not being allowed, remove 'type=transport' from the
connection.

> # This show the successful session with the same WinXP client now attached
> within the 195.210.210.0 network. Again, the client
> # get from a DHCP server it IP address, which is in this case
> 195.210.210.11.

So when there is no NAT. See above.

> Paul, can you confirm that anybody already did openswan run with dial-up
> client??

I have not run with a dial-up client. I have run with XP machines behind NAT
using L2TP. I have not personally put openswan servers behind NAT.

> Can you enlighten me and give me a hint what the log shows after
> the message "cannot respond to IPsec SA request because no connection is
> known for 81.62.18.37/32===195.210.210.2[C=xx, ST=xxx, L=xxx, O=xxx,
OU=xx,
> CN=xxx, E=xxx]:17/0...62.202.193.205[C=xx, ST=xxx, L=xxx, O=xxx, OU=xx,
> CN=xxx, E=xxx]:17/1701"?

Ignore what comes after that. It is just errors in response to errors (that
do need to be addressed but are not your problem)

Paul
_______________________________________________
Users mailing list
Users at openswan.org
http://lists.openswan.org/mailman/listinfo/users

_______________________________________________
Users mailing list
Users at openswan.org
http://lists.openswan.org/mailman/listinfo/users

More information about the Users mailing list