Your message dated Sat, 8 Mar 2014 19:05:21 +0100
with message-id <[email protected]>
and subject line Re: Bug#626169: Reproducible?
has caused the Debian Bug report #626169,
regarding strongswan: ipsec tunnels fail because charon segfaults
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.)
--
626169: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626169
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: strongswan
Version: 4.5.0-1
Severity: important
I have a setup that looks like:
.--------------. .---------------. .-------------------.
| apollon (rw) | | zeus | | hephaistos |
| |======| public server |======| (behind adsl nat) |---
192.168.* LAN
| vip 10.0.0.3 | | 10.0.0.1 | | 192.168.0.42 |
'--------------' '---------------' '-------------------'
apollon is a roadwarior setup, its setup is:
---------8<------------
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
nat_traversal=yes
strictcrlpolicy=no
plutostart=no
# Add connections here.
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
conn home
left=%defaultroute
leftsourceip=%config
leftcert=apollon.madism.org.pem
leftfirewall=yes
right=88.190.14.41
rightsubnet=10.0.0.0/8,192.168.0.0/24
rightcert=zeus.madism.org.pem
auto=start
--------->8------------
zeus is a public server, namely zeus.madism.org with the configuration that
follows:
----------8<----------
# ipsec.conf - strongSwan IPsec configuration file
# basic configuration
config setup
strictcrlpolicy=no
plutostart=no
virtual_private=%v4:10.0.0.0/8
# Add connections here.
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
left=88.190.14.41
leftcert=zeus.madism.org.pem
leftsubnet=10.0.0.0/8,192.168.0.0/24
leftfirewall=yes
lefthostaccess=yes
conn apollon
right=%any
rightcert=apollon.madism.org.pem
rightsourceip=10.0.0.3
auto=add
conn hephaistos
right=82.243.245.108
rightcert=hephaistos.madism.org.pem
rightsourceip=192.168.0.42
rightsubnet=192.168.0.0/24
auto=add
-------------->8-------------
The configuration of hephaistos isn't relevant, though what is interesting is
that the ipsec tunnel between hephaistos and zeus works fine. Unlike the road
warrior that uses virtual ips, the IP (.42) of hephaistos is its real one on
the LAN. Not sure if that matters.
The point is, the ipsec tunnel between apollon and zeus fails after a short
period of time (around a few minutes usually) and it looks like it's charon
that segfaults, since I have a few lines like:
May 9 09:42:05 apollon charon: 07[DMN] thread 7 received 11
In the logs. When that happens, my ipsec status shows:
Security Associations:
home[1]: ESTABLISHED 3 minutes ago, 192.168.2.123[C=FR, ST=France,
L=La Garenne Colombes, CN=apollon.madism.org,
E=apollon.madism.org]...88.190.14.41[C=FR, ST=France, L=La Garenne Colombes,
CN=zeus.madism.org, E=zeus.madism.org]
instead of:
Security Associations:
home[1]: ESTABLISHED 4 seconds ago, 192.168.2.123[C=FR, ST=France,
L=La Garenne Colombes, CN=apollon.madism.org,
E=apollon.madism.org]...88.190.14.41[C=FR, ST=France, L=La Garenne Colombes,
CN=zeus.madism.org, E=zeus.madism.org]
home{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: c4ddc259_i ce5ea7d1_o
home{1}: 10.0.0.3/32 === 10.0.0.0/8 192.168.0.0/24
I've no clue on why this happens, and ipsec up home doesn't solve the problem,
nor ipsec down home; ipsec up home does. Only ipsec restart does, and
then I end up with the iptables redefined lots of time (e.g. right now
my iptables -L looks like that, everything is duplicated:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 192.168.0.0/24 10.0.0.3 policy match
dir in pol ipsec reqid 1 proto esp
ACCEPT all -- 10.0.0.0/8 10.0.0.3 policy match
dir in pol ipsec reqid 1 proto esp
ACCEPT all -- 192.168.0.0/24 10.0.0.3 policy match
dir in pol ipsec reqid 2 proto esp
ACCEPT all -- 10.0.0.0/8 10.0.0.3 policy match
dir in pol ipsec reqid 2 proto esp
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 192.168.0.0/24 10.0.0.3 policy match
dir in pol ipsec reqid 1 proto esp
ACCEPT all -- 10.0.0.3 192.168.0.0/24 policy match
dir out pol ipsec reqid 1 proto esp
ACCEPT all -- 10.0.0.0/8 10.0.0.3 policy match
dir in pol ipsec reqid 1 proto esp
ACCEPT all -- 10.0.0.3 10.0.0.0/8 policy match
dir out pol ipsec reqid 1 proto esp
ACCEPT all -- 192.168.0.0/24 10.0.0.3 policy match
dir in pol ipsec reqid 2 proto esp
ACCEPT all -- 10.0.0.3 192.168.0.0/24 policy match
dir out pol ipsec reqid 2 proto esp
ACCEPT all -- 10.0.0.0/8 10.0.0.3 policy match
dir in pol ipsec reqid 2 proto esp
ACCEPT all -- 10.0.0.3 10.0.0.0/8 policy match
dir out pol ipsec reqid 2 proto esp
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 10.0.0.3 192.168.0.0/24 policy match
dir out pol ipsec reqid 1 proto esp
ACCEPT all -- 10.0.0.3 10.0.0.0/8 policy match
dir out pol ipsec reqid 1 proto esp
ACCEPT all -- 10.0.0.3 192.168.0.0/24 policy match
dir out pol ipsec reqid 2 proto esp
ACCEPT all -- 10.0.0.3 10.0.0.0/8 policy match
dir out pol ipsec reqid 2 proto esp
and also the ip rules are duplicated for the table 220:
$ ip rule
0: from all lookup local
200: from all lookup ipsec-override
220: from all lookup ipsec
220: from all lookup ipsec
32766: from all lookup main
32767: from all lookup default
I've been able to end up with way larger repetitions than that…)
All in all, the ipsec tunnel fails and I've no clue why, logs are
uninformative, but for the 'received 11' event that sounds like a
SIGSEGV but I'm not even sure it's that…
--- End Message ---
--- Begin Message ---
On Thu, Jun 27, 2013 at 01:30:14PM +0200, Yves-Alexis Perez wrote:
> Hi,
>
> does this still happen in more recent versions of the package?
>
I'll take that as a 'no'.
--
Yves-Alexis Perez
signature.asc
Description: Digital signature
--- End Message ---
