[Openswan Users]

[Paul Wouters]

On Thu, 15 Dec 2005, aram price wrote:

> I've been banging on this for a few days now with no luck.
> the machine is a freshly built FC4 machine with the following RPMs
> installed from openswan.org:
> 	openswan-2.4.4-1
> 	l2tpd-0.69-13

l2tpd is now a Fedora Extras package. It has appeared in "development", but
I'm waiting for teh branches to appear so I can request builds for FC-3 and
FC-4 as well. You can grab the .src.rpm from "development" and just built
that. It should be easy and painless.

> 	STATE_MAIN_R1: sent MR1, expecting MI2

>        client (osx 10.4.3)
>      [d.e.f.135]

Are you using certificates on OSX? How did you configure those for X.509?

> 		certs/
> 			me.foo.com.p12
> 			me.foo.com.pem
> 			vpnserver.foo.com.p12
> 			vpnserver.foo.com.pem

You do not need the "me" certificates there.

> 		private/
> 			me.foo.com.key
> 			vpnserver.foo.com.key

and the "me" private key should not be on the server.

> ip range = 10.10.1.161-10.10.1.169
> local ip = 10.10.1.140

> # client	server	secret			IP addresses
> me		*	mysecret		*

Add:
*	me	mysecret	*

Though for the last * I would use a real network/mask notation,
eg 10.10.1.160/27

> Linux Openswan U2.4.4/K2.6.14-1.1644_FC4 (netkey)

You might want to upgrade to 2.4.5dr3

> Two or more interfaces found, checking IP forwarding            [FAILED]

You must enable forwarding in /etc/sysctl.conf

>        virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16

You must exlucde your 10.10.1.0/24 range by adding %v4:!10.10.1.0/24

>        interfaces="ipsec0=eth0"
> # Add connections here
> conn %default
>        keyingtries=1
>        compress=yes
>        pfs=no
>        disablearrivalcheck=no
>        left=a.b.c.4
>        leftsubnet=10.10.1.0/24

You need to remove the subnet. l2tp will get an IP address in the subnet,
and the IPsec SA does not cover the subnet at all. It is a host-host connection.

>        leftprotoport=17/1701
>        right=%any
>        rightsubnet=vhost:%no,%priv
>        rightprotoport=17/%any

> conn l2tp-a-psk
>        authby=secret
>        auto=add
> conn l2tp-b-cert
>        authby=rsasig
>        leftcert=vpnserver.foo.com.pem
>        leftrsasigkey=%cert
>        rightcert=%any
>        rightrsasigkey=%cert
>        auto=add

Using a mix of PSK and RSA will not work right now. auto=ignore one of them
until this issue is addressed.

> + cat /proc/sys/net/ipv4/ip_forward
> 0

Here you see again ip forwardin is off. It should be on

> Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target     prot opt in     out     source               destination
>    0     0 RH-Firewall-1-INPUT  all  --  *      *       0.0.0.0/0
> 0.0.0.0/0
> Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
> pkts bytes target     prot opt in     out     source               destination
>    0     0 ACCEPT     esp  --  *      *       0.0.0.0/0            0.0.0.0/0
>    0     0 ACCEPT     esp  --  *      *       0.0.0.0/0            0.0.0.0/0
> 3143  321K RH-Firewall-1-INPUT  all  --  *      *       0.0.0.0/0
> 0.0.0.0/0
> Chain OUTPUT (policy ACCEPT 2412 packets, 347K bytes)

[more firewall rules]

Please temporarilly disable teh firewall rules for testing purposes.

> '/etc/ipsec.d/private/vpnserver.foo.com.key' (1692 bytes)
> Dec 15 15:34:55 vpnserver pluto[20795]: packet from d.e.f.135:500: received
> Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set to=110
> Dec 15 15:34:55 vpnserver pluto[20795]: "l2tp-a-psk"[1] d.e.f.135 #1:
> responding to Main Mode from unknown peer d.e.f.135
> Dec 15 15:34:55 vpnserver pluto[20795]: "l2tp-a-psk"[1] d.e.f.135 #1:
> transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Dec 15 15:34:55 vpnserver pluto[20795]: "l2tp-a-psk"[1] d.e.f.135 #1:
> STATE_MAIN_R1: sent MR1, expecting MI2
> Dec 15 15:34:58 vpnserver pluto[20795]: packet from d.e.f.135:500: received
> Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set to=110
> Dec 15 15:34:58 vpnserver pluto[20795]: "l2tp-a-psk"[1] d.e.f.135 #2:
> responding to Main Mode from unknown peer d.e.f.135
> Dec 15 15:34:58 vpnserver pluto[20795]: "l2tp-a-psk"[1] d.e.f.135 #2:
> transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Dec 15 15:34:58 vpnserver pluto[20795]: "l2tp-a-psk"[1] d.e.f.135 #2:
> STATE_MAIN_R1: sent MR1, expecting MI2
> Dec 15 15:35:01 vpnserver pluto[20795]: packet from d.e.f.135:500: received
> Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set to=110
> Dec 15 15:35:01 vpnserver pluto[20795]: "l2tp-a-psk"[1] d.e.f.135 #3:
> responding to Main Mode from unknown peer d.e.f.135
> Dec 15 15:35:01 vpnserver pluto[20795]: "l2tp-a-psk"[1] d.e.f.135 #3:
> transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Dec 15 15:35:01 vpnserver pluto[20795]: "l2tp-a-psk"[1] d.e.f.135 #3:
> STATE_MAIN_R1: sent MR1, expecting MI2
> Dec 15 15:35:04 vpnserver pluto[20795]: packet from d.e.f.135:500: received
> Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set to=110
> Dec 15 15:35:04 vpnserver pluto[20795]: "l2tp-a-psk"[1] d.e.f.135 #4:
> responding to Main Mode from unknown peer d.e.f.135
> Dec 15 15:35:04 vpnserver pluto[20795]: "l2tp-a-psk"[1] d.e.f.135 #4:
> transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
> Dec 15 15:35:04 vpnserver pluto[20795]: "l2tp-a-psk"[1] d.e.f.135 #4:
> STATE_MAIN_R1: sent MR1, expecting MI2

I do ot understand this loop. But try comenting out the PSK connections
when trying certificates.

Perhaps the OAKLEY.LOG on the windows side has more information.

Paul