[Openswan Users] tunnel or transport?

[Marco Berizzi]

Hello everybody.
There is a pretty old interoperability
issue between *swan and racoon when
IPcomp is implemented.
I have two Openswan 2.3.1 boxes with an
ESP+IPcomp tunnel running on linux 2.6
setkey -DP output is the following:

10.1.1.0/24[any] 10.1.2.0/24[any] any
 in prio high + 1073739480 ipsec
 ipcomp/tunnel/172.16.1.226-172.16.1.247/use#16386
 esp/transport//unique#16385
 created: Jul  4 11:15:37 2005  lastused: Jul  4 11:18:53 2005
 lifetime: 0(s) validtime: 0(s)
 spid=56 seq=8 pid=5518
 refcnt=1
10.1.2.0/24[any] 10.1.1.0/24[any] any
 out prio high + 1073739480 ipsec
 ipcomp/tunnel/172.16.1.247-172.16.1.226/use#16386
 esp/transport//unique#16385
 created: Jul  4 11:45:52 2005  lastused:
 lifetime: 0(s) validtime: 0(s)
 spid=49 seq=7 pid=5518
 refcnt=1
10.1.1.0/24[any] 10.1.2.0/24[any] any
 fwd prio high + 1073739480 ipsec
 ipcomp/tunnel/172.16.1.226-172.16.1.247/use#16386
 esp/transport//unique#16385
 created: Jul  4 11:15:37 2005  lastused:
 lifetime: 0(s) validtime: 0(s)
 spid=66 seq=6 pid=5518
 refcnt=1

Openswan has established ESP in transport
mode and IPcomp in tunnel mode. The issue
is introduced when one IPsec peer is racoon
with the following configuration:

spdadd 10.1.2.0/24 10.1.1.0/24 any -P out ipsec
    ipcomp/tunnel/172.16.1.247-172.16.1.226/use
    esp/transport//require;

spdadd 10.1.1.0/24 10.1.2.0/24 any -P in ipsec
    ipcomp/tunnel/172.16.1.226-172.16.1.247/use
    esp/transport//require;

Tunnels arent's established because at
Phase 2 openswan propose tunnel and racoon
propose transport.
Here is the racoon's log:

INFO: respond new phase 2 negotiation: 172.16.1.247[0]<=>172.16.1.226[0]
ERROR: encmode mismatched: my:Transport peer:Tunnel
ERROR: not matched
ERROR: no suitable policy found.
ERROR: failed to pre-process packet.

Here is Pluto's log:

: | started looking for secret for 172.16.1.226->172.16.1.247 of kind
PPK_PSK
: | actually looking for secret for 172.16.1.226->172.16.1.247 of kind
PPK_PSK
: | 1: compared PSK 172.16.1.247 to 172.16.1.226 / 172.16.1.247 -> 2
: | 2: compared PSK 172.16.1.226 to 172.16.1.226 / 172.16.1.247 -> 6
: | best_match 0>6 best=0x80fc430 (line=25)
: | concluding with best_match=6 best=0x80fc430 (lineno=25)
: | complete state transition with STF_OK
: "piacenza" #1: transition from state STATE_MAIN_I2 to state
STATE_MAIN_I3
: | sending reply packet to 172.16.1.247:500 (from port=500)
: | sending 68 bytes for STATE_MAIN_I2 through eth0:500 to
172.16.1.247:500:
: | inserting event EVENT_RETRANSMIT, timeout in 10 seconds for #1
: | modecfg pull: noquirk policy:push not-client
: | phase 1 is done, looking for phase 1 to unpend
: | next event EVENT_RETRANSMIT in 10 seconds for #1
: |
: | *received 68 bytes from 172.16.1.247:500 on eth0 (port=500)
: | ICOOKIE:  cb ca 61 b0  c8 29 31 6d
: | RCOOKIE:  53 07 dd e2  f5 b5 b5 b8
: | peer:  ac 10 01 f7
: | state hash entry 7
: | peer and cookies match on #1, provided msgid 00000000 vs 00000000
: | state object #1 found, in STATE_MAIN_I3
: | processing connection piacenza
: "piacenza" #1: Main mode peer ID is ID_IPV4_ADDR: '172.16.1.247'
: | complete state transition with STF_OK
: "piacenza" #1: transition from state STATE_MAIN_I3 to state
STATE_MAIN_I4
: | inserting event EVENT_SA_REPLACE, timeout in 2952 seconds for #1
: "piacenza" #1: ISAKMP SA established
: | modecfg pull: noquirk policy:push not-client
: | phase 1 is done, looking for phase 1 to unpend
: | unqueuing pending Quick Mode with 172.16.1.247 "piacenza"
: | duplicating state object #1
: | creating state object #2 at 0x80fe080
: | processing connection piacenza
: | ICOOKIE:  cb ca 61 b0  c8 29 31 6d
: | RCOOKIE:  53 07 dd e2  f5 b5 b5 b8
: | peer:  ac 10 01 f7
: | state hash entry 7
: | inserting event EVENT_SO_DISCARD, timeout in 0 seconds for #2
: "piacenza" #2: initiating Quick Mode
PSK+ENCRYPT+COMPRESS+TUNNEL+PFS+UP {using isakmp#1}
: | 0: w->pcw_dead: 0 w->pcw_work: 0 cnt: 1
: | asking helper 0 to do build_kenonce op on seq: 2
: | inserting event EVENT_CRYPTO_FAILED, timeout in 300 seconds for #2
: | next event EVENT_PENDING_PHASE2 in 119 seconds
: |
: | *received 84 bytes from 172.16.1.247:500 on eth0 (port=500)
: | ICOOKIE:  cb ca 61 b0  c8 29 31 6d
: | RCOOKIE:  53 07 dd e2  f5 b5 b5 b8
: | peer:  ac 10 01 f7
: | state hash entry 7
: | peer and cookies match on #2, provided msgid 00000000 vs
88c13638/00000000
: | peer and cookies match on #1, provided msgid 00000000 vs
00000000/00000000
: | p15 state object #1 found, in STATE_MAIN_I4
: | processing connection piacenza
: "piacenza" #1: ignoring informational payload, type
IPSEC_INITIAL_CONTACT
: "piacenza" #1: received and ignored informational message
: | complete state transition with STF_IGNORE
: | next event EVENT_PENDING_PHASE2 in 119 seconds
: ! helper -1 doing build_kenonce op id: 2
: | processing connection piacenza
: | empty esp_info, returning empty
: | sending 404 bytes for quick_outI1 through eth0:500 to
172.16.1.247:500:
: | inserting event EVENT_RETRANSMIT, timeout in 10 seconds for #2
: | next event EVENT_RETRANSMIT in 10 seconds for #2
: |
: | *received 68 bytes from 172.16.1.247:500 on eth0 (port=500)
: | ICOOKIE:  cb ca 61 b0  c8 29 31 6d
: | RCOOKIE:  53 07 dd e2  f5 b5 b5 b8
: | peer:  ac 10 01 f7
: | state hash entry 7
: | peer and cookies match on #2, provided msgid 00000000 vs
88c13638/00000000
: | peer and cookies match on #1, provided msgid 00000000 vs
00000000/00000000
: | p15 state object #1 found, in STATE_MAIN_I4
: | processing connection piacenza
: "piacenza" #1: ignoring informational payload, type NO_PROPOSAL_CHOSEN
: "piacenza" #1: received and ignored informational message
: | complete state transition with STF_IGNORE
: | next event EVENT_RETRANSMIT in 10 seconds for #2

My question is: why openswan is proposing
tunnel at quick mode while ESP is transport
mode?

TIA