[Openswan Users] multiple EVENT_SA_REPLACE
omar.armas at gmail.com
Wed Jan 12 19:30:41 EST 2011
Hi, I´m using Openswan in a Debian 5 box(distribution package).
My problem is that when I do an ipsec auto --status, for a tunnel with 3
days of life, I get literally thousands of messages like this:
"000 #5957: "to-33" 189.X.X.145:62374 STATE_QUICK_R2 (IPsec SA
established); EVENT_SA_REPLACE in 1465s
000 #5957: "to-33" 189.X.X.145
esp.9dfd919f at 189.X.X.145esp.67479afd@201.Y.Y.Ytun.0 at 189.X.X.145tun.0@201.Y.Y.Y
beeing EVENT_SA_REPLACE value different for every line.
It gives me no problem, but I plan to add about 100 tunnels and having this
behavor worries me.
As far as I know, I should have a single SA per tunnel, shoudn´t I?
my ipsec.conf has:
And the other side is a Sonicwall with 28800s for ike and phase2 too.
And in auth.log I see this(repeated dozens of times) every 10 or 20 seconds:
"Jan 12 18:14:46 vpntepo pluto: | processing connection to-33
And this also from time to time:
"Jan 12 18:15:16 vpntepo pluto: "to-33" 189.X.X.145 #6094: ISAKMP
SA expired (superseded by #7236)"
This is the output of my "ipsec verify"
Checking your system to see if IPsec got installed and started correctly:
Version check and ipsec on-path [OK]
Linux Openswan U2.4.12/K2.6.26-2-686 (netkey)
Checking for IPsec support in kernel [OK]
NETKEY detected, testing for disabled ICMP send_redirects [FAILED]
Please disable /proc/sys/net/ipv4/conf/*/send_redirects
or NETKEY will cause the sending of bogus ICMP redirects!
NETKEY detected, testing for disabled ICMP accept_redirects [FAILED]
Please disable /proc/sys/net/ipv4/conf/*/accept_redirects
or NETKEY will accept bogus ICMP redirects!
Checking for RSA private key (/etc/ipsec.secrets) [DISABLED]
ipsec showhostkey: no default key in "/etc/ipsec.secrets"
Checking that pluto is running [OK]
Two or more interfaces found, checking IP forwarding [OK]
Checking NAT and MASQUERADEing [N/A]
Checking for 'ip' command [OK]
Checking for 'iptables' command [OK]
Opportunistic Encryption Support [DISABLED]
Is this a bug or configuration issue?
Any idea about how to solve it?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users