[Openswan Users] Road Warrior Ignored / makes Pluto crash
Craig O'Toole
nospam2craig at remex.com.au
Mon Jul 12 15:41:22 CEST 2004
Hi Paul, and everyone at the list,
Thanks for the assistance and sorry for the delay in my response.
I found out several things.
1) Yes I had mixed versions, which was related to the seg-faults in that
the pluto version did have a nasty bug and was not a real problem
otherwise, I have discovered that in the newer versions, the kernel modules
and pluto do not need to match exactly.
2) I was confused with the place to look for the error logs, I should have
been looking at /var/log/security not /var/log/messages for the pluto
debugging.
3) the error turned out to be quite simple, it always is in hindsight. I
will explain for anyone using Netgear FVS318 routers to terminate Road
Warrior connections (changing IP) with the config below. More to the point,
it was the ipsec.secrets file that has changed functionality somwhere along
the line. Look at the end of the current ipsec.secrets to see a working
config.
Question) I now have a new issue, previously I was able to use the
@something.com ID in the ipsec.secrets to identify road warriors all using
the same PSK. for example:
a.a.a.a 0.0.0.0 : PSK "blah blah blah blah blah 1234"
@template.remex.com.au @remote.remex.com.au : PSK "blah blah blah blah blah
1234"
@template.remex.com.au @another_remote.remex.com.au : PSK "blah blah blah
blah blah 1234"
@template.remex.com.au @warrior.remex.com.au : PSK "blah blah blah blah
blah 1234"
used to work fine, now pluto complains saying it can't find a PSK match for
@template.remex.com.au and %any. It used to use the first line correctly to
resolve this case.
Has this functionality been dropped ? Can pluto use the second ID with an
%any by default by looking at the first line above (with the IP addresses)
?
I believe this is where my problems begin and it is why I posted the
original issue.
Thanks in advance
Craig O'Toole
My now working config where obviously (or not):
a.a.a.a is the outside interface address of the linux machine
b.b.b.b is the gateway address
c.c.c.c is the LAN on the linux side of the tunnel
d.d.d.d is the LAN on the Netgear side.
____ipsec.conf____
version 2.0 # conforms to second version of ipsec.conf specification
# basic configuration
config setup
#interfaces=%defaultroute
interfaces="ipsec0=eth0"
uniqueids=no
# Debug-logging controls: "none" for (almost) none, "all" for
lots.
#klipsdebug=all
#plutodebug=all
#dumpdir=/tmp/ipsec
# plutowait=yes
myid=@template.remex.com.au
nat_traversal=no
conn %default
keyingtries=0
disablearrivalcheck=no
conn clear
auto=ignore
conn clear-or-private
auto=ignore
conn private-or-clear
auto=ignore
conn private
auto=ignore
conn block
auto=ignore
conn packetdefault
auto=ignore
# Add connections here.
conn test
type=tunnel
left=a.a.a.a
leftnexthop=b.b.b.b
leftsubnet=c.c.c.c/24
leftid=@template.remex.com.au
right=%any
rightsubnet=d.d.d.d/24
rightid=@remote.remex.com.au
authby=secret
esp=3des-sha1-96
compress=yes
pfs=yes
auto=add
____ipsec.conf____
____ipsec.secrets____
@template.remex.com.au %any : PSK "blah blah blah blah blah 1234"
____ipsec.secrets____
Above is the only line required to connect the Netgear.
Note the @template instead of the ip address of host name. I noticed this
has changed between earlier versions of v2 configs and the current
implementation.
On the Netgear side of things, the following is configured:
Connection Name: remex
Local IPSec Identifier: remote.remex.com.au
Remote IPSec Identifier: template.remex.com.au
Tunnel can be accessed from: a subnet of local address
Local LAN start IP Address: d.d.d.d
Local LAN IP Subnetmask: 255.255.255.0
Tunnel can access: a subnet of remote address
Remote LAN start IP Address: c.c.c.c
Remote LAN IP Subnetmask: 255.255.255.0
Remote WAN IP or FQDN: a.a.a.a
Secure Association: Main Mode
Perfect Forward Secrecy: Enabled
Encryption Protocol: 3DES
PreShared Key: blah blah blah blah blah 1234
Key Life: 3600
IKE Life Time: 28800
NETBIOS Enable
|-----------+--------------------------------------------------|
| To: | Craig O'Toole/Remex/AU |
|-----------+--------------------------------------------------|
| cc: | users at lists.openswan.org |
|-----------+--------------------------------------------------|
| Subject:| Re: [Openswan Users] Road Warrior Ignored / |
| | makes Pluto crash |
|-----------+--------------------------------------------------|
On Wed, 2 Jun 2004, Craig O'Toole wrote:
> I am using a Netgear FVS318 to terminate to freeswan/openswan (I have
tried
> both). When the ipsec.conf settings explicitly define the right ip
address,
> everything works really well. If the right address is set to %any then
the
> result is it consistantly gets a segmentation fault at connection or it
> gets through to connect and happens at re-keying.
Can you try this with the latest Openswan (2.1.2) and if it still
segfaults,
define dumpdir=/tmp and run a gdb trace on the core in /tmp? Could you also
provide an 'ipsec barf' before it crashes?
> Jun 2 11:26:20 template ipsec_setup: Restarting FreeS/WAN IPsec 2.05...
You should be using (if using freeswa at all) version 2.06, since this
fixes
some known snprintf changes that were made to 2.4.25. I am not sure if
these
cause problems for your 2.4.22-1.2188.nptl.
> Linux FreeS/WAN 2.1.1 (klips)
This is different from above. Are you sure you're running from one and the
same version, and you don't have mixed up binaries from different versions?
Paul
---------------------------------------------
Please note: We have moved office and we have new telephone numbers
Our new address is:
Level 2, 14 Rodborough Road, Frenchs Forest, NSW 2086
---------------------------------------------
Craig O'Toole
Remex Consulting
Tel +61 (0)2 9454 7400
Fax +61 (0)2 9454 7499
mailto:cotoole at remex.com.au
http://www.remex.com.au
---------------------------------------------
Information contained in this email is intended for the addressees only.
More information about the Users
mailing list