[Openswan Users] Incorrect xfrm policy with both-NAT client connection

[Kevin Locke]

[Apologies in advance if this message is posted twice.  I got tired
of waiting for moderated approval so I joined the ML and resent.]

Hello All,

I am attempting to use Openswan as a VPN client to an L2TP/IPSec VPN
served from a Windows SBS 2003 server where both the client and server
are behind NATs (ick) and am confused at (what I percieve to be) the
incorrect xfrm policy that is configured when the connection is
created.

Setup
On the Linux client I am running Debian with the Openswan package
(version 1:2.6.23+dfsg+1 compiled with ALLOW_MICROSOFT_BAD_PROPOSAL).
The server is Windows SBS 2003 with the most recent updates as of this
date.  The network looks like this:

    [192.x.x.x]  [64.x.x.x]      [216.x.x.x]  [10.x.x.x]
<Client>----<NAT Box>----<Internet>----<NAT Box>----<Server>

I have attached the ipsec.conf as well as a log of the messages that
are printed during auto --up.

Symptoms
After bringing the connection up, the following entries are added to
the xfrm policy:
src 192.x.x.x/32 dst 10.x.x.x/32 proto udp sport 1701 
	dir out priority 2080 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 16385 mode transport
src 10.x.x.x/32 dst 192.x.x.x/32 proto udp dport 1701 
	dir in priority 2080 
	tmpl src 0.0.0.0 dst 0.0.0.0
		proto esp reqid 16385 mode transport

However, since these entries are using the private IP of the server,
all traffic sent to the server (using the public address, since I do
not yet have a route to the private address AFAIK) is sent outside of
the tunnel.

If I run the following commands to add the policy for the public
address, everything works great:
# ip xfrm policy add dir out src 192.x.x.x/32 dst 216.x.x.x/32 proto udp sport 1701 priority 2080 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp reqid 16385 mode transport
# ip xfrm policy add dir in src 216.x.x.x/32 dst 192.x.x.x/32 proto udp dport 1701 priority 2080 tmpl src 0.0.0.0 dst 0.0.0.0 proto esp reqid 16385 mode transport

So my question is:  Is there something I am misunderstanding or
misconfiguring?  Is this a bug, is it due to some unexpected
interaction with the NATs and/or ALLOW_MICROSOFT_BAD_PROPOSAL?  Is
there any way I can configure Openswan so that I don't have to tweak
the xfrm policy every time I bring up the tunnel, or, if need be, a
way that I can configure it to be done automatically?

If there is any more information that you require, please don't
hesitate to ask.

Thank you for any suggestions and for your time in considering this
problem.

-- 
Cheers,      |  kevin at kevinlocke.name   | JIM:  kevinoid at jabber.org
Kevin        |  http://kevinlocke.name  | IRC: kevinoid on freenode
-------------- next part --------------
# /etc/ipsec.conf - Openswan IPsec configuration file

version	2.0

conn connname
	authby=rsasig
	pfs=no
	rekey=yes
	keyingtries=3
	forceencaps=yes
	type=transport
	left=%defaultroute
	leftrsasigkey=%cert
	leftcert=/etc/ipsec.d/certs/client.pem
	leftprotoport=17/1701
	right=server.domain.com
	rightcert=/etc/ipsec.d/certs/server.pem
	rightrsasigkey=%cert
	rightca=%same
	rightprotoport=17/1701
	auto=add
-------------- next part --------------
104 "connname" #1: STATE_MAIN_I1: initiate
003 "connname" #1: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
003 "connname" #1: ignoring Vendor ID payload [FRAGMENTATION]
003 "connname" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106 
106 "connname" #1: STATE_MAIN_I2: sent MI2, expecting MR2
003 "connname" #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: both are NATed
108 "connname" #1: STATE_MAIN_I3: sent MI3, expecting MR3
004 "connname" #1: STATE_MAIN_I4: ISAKMP SA established {auth=OAKLEY_RSA_SIG cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp1024}
117 "connname" #2: STATE_QUICK_I1: initiate
003 "connname" #2: ignoring informational payload, type IPSEC_RESPONDER_LIFETIME msgid=a199506c
003 "connname" #2: our client subnet returned doesn't match my proposal - us:192.x.x.x/32 vs them:64.x.x.x/32
003 "connname" #2: Allowing questionable proposal anyway [ALLOW_MICROSOFT_BAD_PROPOSAL]
000 "connname" #2: peer client type is FQDN
003 "connname" #2: peer client subnet returned doesn't match my proposal - us:216.x.x.x/32 vs them:64.x.x.x/32
003 "connname" #2: Allowing questionable proposal anyway [ALLOW_MICROSOFT_BAD_PROPOSAL]
003 "connname" #2: IDcr was FQDN: server.domain.local\203, using NAT_OA=10.x.x.x/32 as IDcr
004 "connname" #2: STATE_QUICK_I2: sent QI2, IPsec SA established transport mode {ESP/NAT=>0xc0873ccb <0xd6a64c44 xfrm=3DES_0-HMAC_SHA1 NATOA=10.x.x.x NATD=216.x.x.x:4500 DPD=none}