Your message dated Thu, 6 Jan 2011 23:32:17 +0100
with message-id <[email protected]>
and subject line Bug#524184: fixed in openswan 1:2.6.20+dfsg-1
has caused the Debian Bug report #524184,
regarding openswan: %any does not work in ipsec.secrets
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
524184: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524184
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Source: openswan
Source-Version: 1:2.6.20+dfsg-1
As you filed this bug report against Debian Lenny please use the version from
Debian Lenny Backports (1:2.6.28+dfsg-5~bpo50+1) available from the Backports
repository (please see http://backports.debian.org/Instructions/ for adding a
line to sources.list and http://backports.debian.org/Mirrors/ for a list of
mirrors).
Kind regards
Harald Jenny
--- End Message ---
