[Openswan dev] [Openswan Users] Configuration for both pure ipsec and l2tp/ipsec clients

[Paul Wouters]

On Wed, 16 Jun 2010, hayate wrote:

> Subject: Re: [Openswan Users] Configuration for both pure ipsec and l2tp/ipsec
>       clients
>

> Jun 16 00:22:10 localhost pluto[15009]: "E71"[56] 117.136.8.17 #184:
> switched from "E71" to "E71"

Is this 2.6.26 or newer? This weird "switch" suggests it is not.

> Jun 16 00:22:10 localhost pluto[15009]: "E71" #182: deleting state
> (STATE_MODE_CFG_R1)
> Jun 16 00:22:10 localhost pluto[15009]: "E71"[57] 117.136.8.17 #184:
> transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
> Jun 16 00:22:10 localhost pluto[15009]: "E71"[57] 117.136.8.17 #184:
> new NAT mapping for #184, was 117.136.8.17:10337, now
> 117.136.8.17:10651
> Jun 16 00:22:10 localhost pluto[15009]: "E71"[57] 117.136.8.17 #184:
> STATE_MAIN_R3: sent MR3, ISAKMP SA established
> {auth=OAKLEY_PRESHARED_KEY cipher=aes_256 prf=oakley_sha
> group=modp1536}
> Jun 16 00:22:11 localhost pluto[15009]: "E71"[57] 117.136.8.17 #184:
> modecfg_inR0(STF_OK)
> Jun 16 00:22:11 localhost pluto[15009]: "E71"[57] 117.136.8.17 #184:
> transition from state STATE_MODE_CFG_R0 to state STATE_MODE_CFG_R1
> Jun 16 00:22:11 localhost pluto[15009]: "E71"[57] 117.136.8.17 #184:
> STATE_MODE_CFG_R1: ModeCfg Set sent, expecting Ack
> Jun 16 00:22:15 localhost pluto[15009]: "E71"[57] 117.136.8.17 #184:
> ignoring informational payload, type IPSEC_REPLAY_STATUS
> msgid=00000000
> Jun 16 00:22:15 localhost pluto[15009]: "E71"[57] 117.136.8.17 #184:
> the peer proposed: 0.0.0.0/0:0/0 -> 192.168.7.24/32:0/0
> Jun 16 00:22:15 localhost pluto[15009]: "E71"[57] 117.136.8.17 #185:
> ENCAPSULATION_MODE_UDP_TUNNEL must only be used with old IETF drafts
> Jun 16 00:22:15 localhost pluto[15009]: "E71"[57] 117.136.8.17 #185:
> no Phase1 state for Quick mode notification
> Jun 16 00:22:25 localhost pluto[15009]: "E71"[57] 117.136.8.17 #184:
> ignoring informational payload, type IPSEC_REPLAY_STATUS
> msgid=00000000

Seems alike a lot of failed negotiations, where I think the other end
is keeping quiet, and possibly logging about the problem.

This one is odd:

> Jun 16 00:22:15 localhost pluto[15009]: "E71"[57] 117.136.8.17 #185:
> ENCAPSULATION_MODE_UDP_TUNNEL must only be used with old IETF drafts
> Jun 16 00:22:15 localhost pluto[15009]: "E71"[57] 117.136.8.17 #185:

apart from a bad logging (bad enum variables that I will fix) this
is actually trying to say the remove device used the RFC number
for encapsulation within udp, but used the draft number during
negotiation? I'd look into a firmware upgrade.

You *might* be able to hack this code snippit in spdb_v1_struct.c:

       case ENCAPSULATION_MODE_UDP_TUNNEL_DRAFTS:
                                 if (st->hidden_variables.st_nat_traversal & NAT_T_WITH_ENCAPSULATION_RFC_VALUES) {
                                         loglog(RC_LOG_SERIOUS,
                                                 "%s must only be used with old IETF drafts",
                                                 enum_name(&enc_mode_names, val));
                                         return FALSE;
                                 }

and remove the return FALSE statement. But if it breaks, you get to keep both pieces.

Paul