[Openswan Users] PSK, %any and NAT-T

[Jacco de Leeuw]

I noticed an interesting behaviour of Openswan 2.3.x with a PSK
that is used by one or more roadwarriors.

ipsec.conf:
    left=123.123.123.123
    right=%any

ipsec.secrets:
    123.123.123.123 %any: PSK "keysharedbyallusers"

This results in the following (slightly edited for brevity):

Jul 17 11:01:51 duron pluto[4931]: Starting Pluto (Openswan Version 2.3.1 
X.509-1.5.4 PLUTO_SENDS_VENDORID PLUTO_USES_KEYRR; Vendor ID OEExalF{_o`m)
Jul 17 11:01:51 duron pluto[4931]: Setting port floating to off
Jul 17 11:01:51 duron pluto[4931]: port floating activate 0/1
Jul 17 11:01:51 duron pluto[4931]:   including NAT-Traversal patch (Version 
0.6c) [disabled]
Jul 17 11:01:51 duron pluto[4931]: Using Linux 2.6 IPsec interface code
Jul 17 11:02:08 duron pluto[4931]: packet from 234.234.234.234:500: ignoring 
Vendor ID payload [FRAGMENTATION]
Jul 17 11:02:08 duron pluto[4931]: packet from 234.234.234.234:500: received 
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but port 
floating is off
Jul 17 11:02:08 duron pluto[4931]: "L2TP-PSK"[1] 234.234.234.234 #1: 
responding to Main Mode from unknown peer 234.234.234.234
Jul 17 11:02:08 duron pluto[4931]: "L2TP-PSK"[1] 234.234.234.234 #1: Can't 
authenticate: no preshared key found for `123.123.123.123' and `%any'. 
Attribute OAKLEY_AUTHENTICATION_METHOD

So the PSK as specified in ipsec.secrets is ignored. This is not what one
would expect. When I add the following to ipsec.conf:

    nat_traversal=yes

...everything works fine:

Jul 17 11:02:29 duron pluto[5136]: packet from 234.234.234.234:500: ignoring 
Vendor ID payload [FRAGMENTATION]
Jul 17 11:02:29 duron pluto[5136]: packet from 234.234.234.234:500: received 
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
Jul 17 11:02:29 duron pluto[5136]: "L2TP-PSK"[1] 234.234.234.234 #1: 
responding to Main Mode from unknown peer 234.234.234.234
Jul 17 11:02:29 duron pluto[5136]: "L2TP-PSK"[1] 234.234.234.234 #1: 
transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Jul 17 11:02:30 duron pluto[5136]: "L2TP-PSK"[1] 234.234.234.234 #1: 
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected
Jul 17 11:02:30 duron pluto[5136]: "L2TP-PSK"[1] 234.234.234.234 #1: 
transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Jul 17 11:02:30 duron pluto[5136]: "L2TP-PSK"[1] 234.234.234.234 #1: ignoring 
informational payload, type IPSEC_INITIAL_CONTACT
Jul 17 11:02:30 duron pluto[5136]: "L2TP-PSK"[1] 234.234.234.234 #1: Main mode 
peer ID is ID_IPV4_ADDR: '234.234.234.234'
Jul 17 11:02:30 duron pluto[5136]: "L2TP-PSK"[1] 234.234.234.234 #1: 
transition from state STATE_MAIN_R2 to state STATE_MAIN_R3
Jul 17 11:02:30 duron pluto[5136]: "L2TP-PSK"[1] 234.234.234.234 #1: sent MR3, 
ISAKMP SA established

If you don't (want to) use NAT-T, you can remove %any from ipsec.secrets
and then it will work:

    123.123.123.123 : PSK "keysharedbyallusers"

Is there a particular reason why NAT-T influences the working of PSKs?
In both cases there is no NAT so the ID of the client is an IP address,
not a FQDN or something.

Jacco
-- 
Jacco de Leeuw                         mailto:jacco2 at dds.nl
Zaandam, The Netherlands           http://www.jacco2.dds.nl