Package: openswan
Version: 1:2.4.12+dfsg-1.3+lenny1
Severity: important

Setting up a "road warrior" configuration with pre shared keys.  Laptop IP
address is 192.168.4.12 (NATted, obviously, and variable by DHCP according
to the host network).  Ipsec gateway address is 213.170.149.180.

man ipsec.secrets states that %any can be used to match any IP (host or
peer) but this does not seem to work at all, at least for pre shared keys
(I haven't got a certificate secured connection yet to test that with).

Test 1: Connection fails to match local address using %any:

# cat /etc/ipsec.secrets
213.170.149.180 %any: PSK "secretsecret"
# ipsec auto --rereadsecrets
# ipsec auto --down PSK-CLIENT
# ipsec auto --up PSK-CLIENT
104 "PSK-CLIENT" #8: STATE_MAIN_I1: initiate
003 "PSK-CLIENT" #8: ignoring unknown Vendor ID payload 
[4f455a7e4261425d725c705f]
003 "PSK-CLIENT" #8: received Vendor ID payload [Dead Peer Detection]
003 "PSK-CLIENT" #8: received Vendor ID payload [RFC 3947] method set to=109
003 "PSK-CLIENT" #8: Can't authenticate: no preshared key found for 
`192.168.4.12' and `213.170.149.180'.  Attribute OAKLEY_AUTHENTICATION_METHOD
003 "PSK-CLIENT" #8: no acceptable Oakley Transform
214 "PSK-CLIENT" #8: STATE_MAIN_I1: NO_PROPOSAL_CHOSEN

Test 2: Connection also fails to match peer address using %any:

# cat /etc/ipsec.secrets
%any 192.168.4.12: PSK "secretsecret"
# ipsec auto --rereadsecrets
# ipsec auto --down PSK-CLIENT
# ipsec auto --up PSK-CLIENT
104 "PSK-CLIENT" #8: STATE_MAIN_I1: initiate
003 "PSK-CLIENT" #8: ignoring unknown Vendor ID payload 
[4f455a7e4261425d725c705f]
003 "PSK-CLIENT" #8: received Vendor ID payload [Dead Peer Detection]
003 "PSK-CLIENT" #8: received Vendor ID payload [RFC 3947] method set to=109
003 "PSK-CLIENT" #8: Can't authenticate: no preshared key found for 
`192.168.4.12' and `213.170.149.180'.  Attribute OAKLEY_AUTHENTICATION_METHOD
003 "PSK-CLIENT" #8: no acceptable Oakley Transform
214 "PSK-CLIENT" #8: STATE_MAIN_I1: NO_PROPOSAL_CHOSEN

Test 3: Connection only works if both local and peer addresses are specifically 
given:

# cat /etc/ipsec.secrets
213.170.149.180 192.168.4.12: PSK "secretsecret"
# ipsec auto --rereadsecrets
# ipsec auto --down PSK-CLIENT
# ipsec auto --up PSK-CLIENT
104 "PSK-CLIENT" #11: STATE_MAIN_I1: initiate
003 "PSK-CLIENT" #11: ignoring unknown Vendor ID payload 
[4f455a7e4261425d725c705f]
003 "PSK-CLIENT" #11: received Vendor ID payload [Dead Peer Detection]
003 "PSK-CLIENT" #11: received Vendor ID payload [RFC 3947] method set to=109
106 "PSK-CLIENT" #11: STATE_MAIN_I2: sent MI2, expecting MR2
003 "PSK-CLIENT" #11: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): i 
am NATed
108 "PSK-CLIENT" #11: STATE_MAIN_I3: sent MI3, expecting MR3
004 "PSK-CLIENT" #11: STATE_MAIN_I4: ISAKMP SA established 
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_md5 
group=modp1536}
117 "PSK-CLIENT" #12: STATE_QUICK_I1: initiate

Most of the ipsec howtos suggest that one should start by working with
a pre-shared key before adding the complexity of certificate management
so this is a bit of an awkward problem as one cannot predict the local
address on a road warrior setup.

The problem is fixed in current unstable (openswan 1:2.6.20+dfsg-4.1) but
this will be a cause of hair loss for Lenny users for some time to come.
Upstream changelog for 2.6.18 refers to a bug fix:
#228: Problems with %any matching in ipsec.secrets? [David McCullough]

Is there any way this problem could be fixed in Lenny openswan 2.4.x,
please, perhaps using the patch from Xcelerance BTS or a backport of
the 2.6.18 fix ?  http://bugs.xelerance.com/view.php?id=228

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (800, 'stable'), (500, 'oldstable'), (3, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to