strongSwan

I have a simmilar problem in tunnel mode with certificates (IPv4).

auto=start works, auto=add following a "ipsec up myconn" works, but auto=route does not.

The Novell bug you are referencing is not public.

Georg Müller wrote:

The Novell bug you are referencing is not public.

Yes, sorry. I don't have the permission to change this.
Anyway... there is nothing interesting / not already mentioned here.

Martin Willi wrote:

I'm unable to reproduce this with strongSwan 4.3.3 and a Linux kernel 2.6.30. Any combination of IPv4/6, transport/tunnel and PSK authentication works fine here with auto=route (at least with IKEv2).

Which strongSwan/kernel versions are you using?

x86_64 kernel 2.6.27.25 (opensuse 11.1) with strongswan 4.3.3 <=> i586 kernel 2.6.27.25 (opensuse 11.1 xen) with strongswan 4.2.8

I'll retry with strongswan 4.3.3 vs. 4.3.3 with the 2.6.27 and 2.6.30 kernels.

state changed from "CREATED" to "CONNECTING" but it tries to send
an unused certificate to the peer ignoring authby=secret.

This is rather strange. Are there any other connections defined using these credentials?

No, there were just certificates bellow of /etc/ipsec.d/, but the connections were commented out.

My client is also openSUSE 11.1/strongswan 4.2.8, my server is 4.2.4.

Exchanging the client worked for me (4.2.4 on the other side). So it looks like a problem related to openSUSE.

I will try openSUSE with same kernel but latest strongswan leaving the server as-is (ubuntu 8.10 server).

EDIT:
I tried strongswan 4.3.3 - same problem
Difference here: state switched to ESTABLISHED, but no tunnel packets are transferred (tried to ping)

The last 3 entries of "setkey -D -P" show " Policy:[Invalid ipsec protocol]" when auto=route:

172.20.2.124[any] 192.168.0.0/24[any] any
Policy:[Invalid ipsec protocol]
created: Aug 6 18:04:36 2009 lastused: Aug 6 18:04:41 2009
lifetime: 0(s) validtime: 0(s)
spid=3129 seq=11 pid=30407
refcnt=3

with ubuntu/strongswan 4.2.4 the same setup looks like this:

172.20.2.125[any] 192.168.0.0/24[any] any
out ipsec
esp/tunnel/172.20.2.125-11.22.33.44/unique:1
created: Aug 6 18:27:11 2009 lastused: Aug 6 18:27:28 2009
lifetime: 0(s) validtime: 0(s)
spid=945 seq=11 pid=13393
refcnt=3

I did a bit more investigation about the setkey invalid policy issue:

"setkey -D -P -v" with auto=route shows

...
sadb_x_policy{ type=2 dir=3 id=5a2 priority=2760 } { len=48 proto=0 mode=2 level=3 reqid=1
...

while with auto=route it shows

...
sadb_x_policy{ type=2 dir=3 id=52a priority=1760 } { len=48 proto=50 mode=2 level=3 reqid=1
...

As you can see it only differs in proto value. I can confirm this on ubuntu (9.04) too, must have done something different yesterday..

As you can see it only differs in proto value.

Ah, thanks for this tip. Yes we actually do not set a protocol value, as (theoretical) we can't predict it. If we have multiple proposals, one with AH, one with ESP, we wouldn't know which one the peer selects.

However, as we support ESP only in charon, we can set the protocol to ESP. Please test commit:dd4c14f3, here it works with and without this change...

this fixes the setkey output, but my connection still does not work.

I don't know if this is related to the issue of Marius, so maybe this is a different issue...

I have a client setup with rightsourceip=%config to get an IP from a server-side pool (192.168.1.0/24) and auto=route.

The server suggests an IP address (192.168.1.1) and it is added to the interface, but "ip r list table 220" shows "src 172.20.2.124", "setkey -D -P" does not contain 192.168.1.1 at all, only 172.20.2.124 (local IP):

172.20.2.124[any] 192.168.0.0/24[any] any
out prio high + 1073739144 ipsec
esp/tunnel/172.20.2.124-77.20.253.33/unique:1
created: Aug 7 17:18:46 2009 lastused: Aug 7 17:18:50 2009
lifetime: 0(s) validtime: 0(s)
spid=4201 seq=13 pid=26209
refcnt=2

With auto=start the entries in setkey -D -P contain the right IP:

192.168.1.1[any] 192.168.0.0/24[any] any
out prio high + 1073740144 ipsec
esp/tunnel/172.20.2.124-77.20.253.33/unique:1
created: Aug 7 17:24:00 2009 lastused:
lifetime: 0(s) validtime: 0(s)
spid=4441 seq=13 pid=26596
refcnt=2

The configuration of auto=route causes the following message:
traffic selectors 192.168.0.253/32[udp/1025] 192.168.0.0/24 === 172.20.2.124/32[udp/53889] 172.20.2.124/32 inacceptable

Martin Willi wrote:

I'm unable to reproduce this with strongSwan 4.3.3 and a Linux kernel 2.6.30. Any combination of IPv4/6, transport/tunnel and PSK authentication works fine here with auto=route (at least with IKEv2).

Yes.
I've written a very simple test-suite allowing me to adopt the IPs and install
it somewhere else easy... Until now I've tested on openSUSE-Factory (11.2 ml5),
that is kernel 2.6.31-rc4-1-default x86_64 and strongswan-4.3.3.

The following combinations work fine (ping⁶ is transfered with ESP incl.
trigger in transport mode):

test01_ike1_rsa_tunnel_ipv4_start  test21_ike1_psk_tunnel_ipv4_start
  test02_ike1_rsa_tunnel_ipv4_route  test22_ike1_psk_tunnel_ipv4_route
  test03_ike1_rsa_transp_ipv4_start  test23_ike1_psk_transp_ipv4_start
  test04_ike1_rsa_transp_ipv4_route  test24_ike1_psk_transp_ipv4_route
  test05_ike1_rsa_tunnel_ipv6_start  test25_ike1_psk_tunnel_ipv6_start
  test06_ike1_rsa_tunnel_ipv6_route  test26_ike1_psk_tunnel_ipv6_route
  test07_ike1_rsa_transp_ipv6_start  test27_ike1_psk_transp_ipv6_start
  test08_ike1_rsa_transp_ipv6_route  test28_ike1_psk_transp_ipv6_route
  test11_ike2_rsa_tunnel_ipv4_start  test31_ike2_psk_tunnel_ipv4_start
  test12_ike2_rsa_tunnel_ipv4_route  test32_ike2_psk_tunnel_ipv4_route
  test13_ike2_rsa_transp_ipv4_start  test33_ike2_psk_transp_ipv4_start
  test14_ike2_rsa_transp_ipv4_route  test34_ike2_psk_transp_ipv4_route
  test15_ike2_rsa_tunnel_ipv6_start  test35_ike2_psk_tunnel_ipv6_start
  test16_ike2_rsa_tunnel_ipv6_route  test36_ike2_psk_tunnel_ipv6_route
  test17_ike2_rsa_transp_ipv6_start  test37_ike2_psk_transp_ipv6_start
  test18_ike2_rsa_transp_ipv6_route  test38_ike2_psk_transp_ipv6_route

I'm going to repeat the tests on openSUSE-11.1 with strongswan-4.3.3
now and then with strongswan-4.2.8 (4.2.17) and later also on s390x.

I've retested above cases using strongswan-4.3.4 (with increased netlink response buffer
patch from git) and kernel 2.6.32.8 (SLES-11-SP1 Beta5) -- all worked fine for me.