[Openswan Users] ip xfrm confusion

[Patrick Naubert]

Rescued from the Spam bucket.  Please remember to subscribe to the mailing list before posting to it.

Date: December 27, 2014 at 9:29:59 AM GMT-5
From: klas <oslist at k.flum.net>
To: users at lists.openswan.org
Subject: ip xfrm confusion


I'm trying to connect my linux/openswan client to a server through
ipsec/l2tp using netkey.

The client with IP 192.168.0.145 is connected to the gateway
192.168.0.10 and the server IP is 1.1.1.1.

192.168.0.145 <-> 192.168.0.10/2.2.2.2 <-> 1.1.1.1.

ipsec connection seems ok.

However, xl2tpd fails to get any connection over ipsec.

If I set lns to 10.200.101.15, the ipsec transport is ignored and
tcpdump udp port 1701 will see the packages.

If I use 1.1.1.1 instead, I see no packages with tcp dump, but I still
don't get any contact with the server.

I've had this working in the past with 10.200.101.15 as lns.
I suppose the problems is how ip xfrm is set up. But I must admit
that I don't really understand what ip xfrm state/policy tells me nor
how to add other routes.


ipsec.conf:
config setup
       nat_traversal=yes
       virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12,%v4:25.0.0.0/8
       oe=off
       protostack=netkey

conn my-vpn
       authby=secret
       pfs=no
       rekey=yes
       keyingtries=3
       type=transport
       left=192.168.0.145
       leftnexthop=192.168.0.10
       leftprotoport=17/1701
       right=1.1.1.1
       rightid=@VPN01.serverplace.local
       rightprotoport=17/1701
       auto=add


A few warning here.
002 "my-vpn" #1: initiating Main Mode
104 "my-vpn" #1: STATE_MAIN_I1: initiate
003 "my-vpn" #1: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY
00000004] 
003 "my-vpn" #1: ignoring Vendor ID payload [FRAGMENTATION]
003 "my-vpn" #1: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02_n] method set to=106 
002 "my-vpn" #1: enabling possible NAT-traversal with method
draft-ietf-ipsec-nat-t-ike-05 
002 "my-vpn" #1: transition from state STATE_MAIN_I1 to state
STATE_MAIN_I2 
106 "my-vpn" #1: STATE_MAIN_I2: sent MI2, expecting MR2 
003 "my-vpn" #1: NAT-Traversal: Result using
draft-ietf-ipsec-nat-t-ike-02/03: both are NATed 
002 "my-vpn" #1: transition from state STATE_MAIN_I2 to state
STATE_MAIN_I3 
108 "my-vpn" #1: STATE_MAIN_I3: sent MI3, expecting MR3 
002 "my-vpn" #1: Main mode peer ID is ID_FQDN:
'@VPN01.serverplace.local' 
002 "my-vpn" #1: transition from state STATE_MAIN_I3 to state
STATE_MAIN_I4 
004 "my-vpn" #1: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024} 
002 "my-vpn" #2: initiating Quick Mode
PSK+ENCRYPT+UP+IKEv2ALLOW+SAREFTRACK {using isakmp#1 msgid:3bb07674
proposal=defaults pfsgroup=no-pfs} 
117 "my-vpn" #2: STATE_QUICK_I1: initiate
002 "my-vpn" #2: IKE message has the Commit Flag set but Pluto doesn't
implement this feature; ignoring flag 
003 "my-vpn" #2: ignoring informational payload, type
IPSEC_RESPONDER_LIFETIME msgid=3bb07674 
003 "my-vpn" #2: our client subnet returned doesn't match my proposal -
us:192.168.0.145/32 vs them:2.2.2.2/32 
003 "my-vpn" #2: Allowing questionable proposal anyway
[ALLOW_MICROSOFT_BAD_PROPOSAL] 
000 "my-vpn" #2: peer client type is FQDN 003 "my-vpn" #2: peer client
subnet returned doesn't match my proposal - us:1.1.1.1/32 vs
them:2.2.2.2/32 
003 "my-vpn" #2: Allowing questionable proposal anyway
[ALLOW_MICROSOFT_BAD_PROPOSAL] 003 "my-vpn" #2: IDcr was FQDN:
VPN01.serverplace.local\203, using NAT_OA=10.200.101.15/32 as IDcr 
002 "my-vpn" #2: netlink_raw_eroute: WARNING: that_client port 0 and
that_host port 1701 don't match. Using that_client port. 
002 "my-vpn" #2: transition from state STATE_QUICK_I1 to state
STATE_QUICK_I2 
004 "my-vpn" #2: STATE_QUICK_I2: sent QI2, IPsec SA established
transport mode {ESP=>0xabababab <0xbcbcbcbc xfrm=3DES_0-HMAC_SHA1
NATOA=10.200.101.15 NATD=1.1.1.1:4500 DPD=none}



ip xfrm state
src 1.1.1.1 dst 192.168.0.145
       proto esp spi 0xb2b7c283 reqid 16385 mode transport
       replay-window 32 
       auth-trunc hmac(sha1) 0x35... 96
       enc cbc(des3_ede) 0x20...
       encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
       sel src 10.200.101.15/32 dst 192.168.0.145/32 proto udp dport
1701 src 192.168.0.145 dst 1.1.1.1
       proto esp spi 0xccc4890a reqid 16385 mode transport
       replay-window 32 
       auth-trunc hmac(sha1) 0x71... 96
       enc cbc(des3_ede) 0xc4...
       encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
       sel src 192.168.0.145/32 dst 10.200.101.15/32 proto udp sport
       1701

ip xfrm policy
src 192.168.0.145/32 dst 1.1.1.1/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.200.101.15/32 dst 192.168.0.145/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
src ::/0 dst ::/0 
       socket out priority 0 
src ::/0 dst ::/0 
       socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
       socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
       socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
       socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
       socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
       socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
       socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
       socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
       socket in priority 0



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openswan.org/pipermail/users/attachments/20141227/6f18bcf4/attachment.html>