Bug 150179

This should not be an issue with the shipped-with-RHEL kernel. What
kernel are you using?

hi bill,

i took the time setup a reasonably good lab with two machines running
up2date rhel 4 -- using kernel 2.6.9-5.0.3.ELsmp. i also setup this up
lab using FC3 boxes.

the results are the same (rhel->rhel, rhel->fc3 and fc3->rhel) --
packets coming from the "right side" network do not make it back to
the "left side" unless "fwd" policy is manually added to the right
side. i will try to build/install .5 ipsec-tools to see if this cures
the issue, however the issue does exist.

cheers

charles

hi bill,

i built .5 ipsec-tools and ran them on the "right side" -- as the
tunnel comes up:

2005-03-04 13:02:04: ERROR: such policy does not already exist:
172.16.7.1/32[0] 172.16.11.0/24[0] proto=any dir=in
2005-03-04 13:02:04: ERROR: such policy does not already exist:
172.16.7.1/32[0] 172.16.11.0/24[0] proto=any dir=fwd
2005-03-04 13:02:04: ERROR: such policy does not already exist:
172.16.11.0/24[0] 172.16.7.1/32[0] proto=any dir=out

notice that the fwd policy is automatically generated! this is not the
case under the ipsec tools currently availble for rhel and fc3.


hth ...

cheers

charles

*Sigh*. As I understand it, the code that required forward policies
was only added in 2.6.10. Will check some more.

Yes, that patch is in the RHEL4 kernel. Please try the ipsec-tools at:

http://people.redhat.com/notting/ipsec/

Yes, the RHEL4 kernel required forward policies for network-2-network
conections. I am able to set the "fwd" policies with the RHEL4
"ipsec-tools-0.3.3-2.1" version in my own scripts (actual result is in
#145424 with the ipsec-tools-0.3.3-2.1). Test with the new
ipsec-tools-0.5-0.RHEL4.i386.rpm follows.

"initscripts-7.93.11.EL-1" do not generate/delete the "fwd" policies
in ifup-ipsec/ipdown-ipsec. Please look for Bugilla #147001.

ipsec-tools-0.5-0.RHEL4.*.rpm can automatically generate the "fwd" policies
needed for network-2-network connections. At this time the new ipsec-tools
version 0.5 was not build RHEL4 conform. I have added a ipsec-tools.spec patch
in #145424 (this was the first issue for problems with ipsec connections
RHEL3-RHEL4(Beta)).

The question is now, what will Red Hat do to fix the problem?

- update ipsec-tools to version 0.5 (RHEL4 kernel required the "fwd" policies
for network-2-network connections!)
or
- fix initscripts

I think, update to ipsec-tools-0.5 will be the better way.

hi bill, hi uwe,

i compiled and installed the FC4 ipsec-tools (based on v 0.5) and it
works under rhel-4 and fc3.

the issue here is different than in bug #147001 as a "road warrior"
connection needs to have his policy "auto generated" and the auto
generation as currently implemented does not contain the necessary fwd
rules and doen't work as desired.


bill, i'll try the ipsec tools in your directory and post back with
results.

cheers

charles

hi bill,

tested your ipsec-tools package (compiled) and it works as expected --
it creates the proper forwarding policy when a new tunnel is established.

there are two issues before making this package public:

1) the new package expects the presence of the directory 

/var/racoon

to place the racoon.sock file. the install section in the package
should therefore create /var/racoon with 0700 permission.

2) the racoon binary has not been ./configure (d) to default to
/etc/racoon/racoon.conf -- if the user installs this package, he must
specify the location of racoon.conf with "-f" argument. probably
better to configure the racoon build to default to /etc/racoon when
its looking for its config.

THANKS!

charles

Yes, new packages are in the same place that fix this. /var/racoon is
left as 755; I don't think that will cause any problems (the socket is
0600 by default.)

hi bill,

i didn't quite follow your last post, but just a note that a: 

rpm -Uvh ipsec-tools-0.5-0.RHEL4.i386.rpm

will not create the /var/racoon directory -- i had to manually create
it and also add -f to raccon to help it find the racoon.conf.

cheers & thanks again

charles

There's a 0.5-1.RHEL4 in that directory with those fixes.

I tryed to use 0.5-1 and even better success then with stock RHEL3 ipsec-tools,
the tunnel between RHEL3 and RHEL4 is not established (LAN-LAN). The
configuration has worked with both RHEL3.

RHEL4:
# cat /etc/sysconfig/network-scripts/ifcfg-ipsec0
DEVICE=ipsec0
TYPE=IPSEC
ONBOOT=yes
IKE_METHOD=PSK
SRCGW=A.1.1.1
DSTGW=B.1.1.1
SRCNET=10.0.0.0/24
DSTNET=10.0.1.0/24
DST=B.1.1.1
# cat /etc/sysconfig/network-scripts/keys-ipsec0
IKE_PSK=SecretkeY

/var/log/messages (with new ipsec-utils):
Mar  9 13:46:14 rhel4 racoon: INFO: IPsec-SA expired: AH/Tunnel B.1.1.1->A.1.1.1
spi=187224658(0xb28d252)
Mar  9 13:46:14 rhel4 racoon: INFO: initiate new phase 2 negotiation:
A.1.1.1[0]<=>B.1.1.1[0]
Mar  9 13:46:14 rhel4 racoon: INFO: IPsec-SA expired: ESP/Tunnel
B.1.1.1->A.1.1.1 spi=186300334(0xb1ab7ae)
Mar  9 13:46:14 rhel4 racoon: INFO: IPsec-SA expired: ESP/Tunnel
A.1.1.1->B.1.1.1 spi=223323650(0xd4fa602)
Mar  9 13:46:15 rhel4 racoon: INFO: IPsec-SA established: AH/Tunnel
B.1.1.1->A.1.1.1 spi=201287890(0xbff68d2)
Mar  9 13:46:15 rhel4 racoon: INFO: IPsec-SA established: ESP/Tunnel
B.1.1.1->A.1.1.1 spi=229815939(0xdb2b683)
Mar  9 13:46:15 rhel4 racoon: ERROR: pfkey ADD failed: File exists
Mar  9 13:46:15 rhel4 racoon: ERROR: pfkey ADD failed: File exists
Mar  9 13:46:15 rhel4 racoon: INFO: IPsec-SA expired: AH/Tunnel B.1.1.1->A.1.1.1
spi=32213957(0x1eb8bc5)
Mar  9 13:46:15 rhel4 racoon: INFO: initiate new phase 2 negotiation:
A.1.1.1[0]<=>B.1.1.1[0]
Mar  9 13:46:15 rhel4 racoon: INFO: IPsec-SA expired: ESP/Tunnel
B.1.1.1->A.1.1.1 spi=163553378(0x9bfa062)
Mar  9 13:46:15 rhel4 racoon: INFO: IPsec-SA expired: AH/Tunnel A.1.1.1->B.1.1.1
spi=153390621(0x9248e1d)
Mar  9 13:46:16 rhel4 racoon: INFO: IPsec-SA established: AH/Tunnel
B.1.1.1->A.1.1.1 spi=25404293(0x183a385)
Mar  9 13:46:16 rhel4 racoon: INFO: IPsec-SA established: ESP/Tunnel
B.1.1.1->A.1.1.1 spi=199398497(0xbe29461)
Mar  9 13:46:16 rhel4 racoon: ERROR: pfkey ADD failed: File exists
Mar  9 13:46:16 rhel4 racoon: ERROR: pfkey ADD failed: File exists
...
Mar  9 13:58:15 rhel4 racoon: INFO: IPsec-SA expired: AH/Tunnel B.1.1.1->A.1.1.1
spi=32213957(0x1eb8bc5)
Mar  9 13:58:15 rhel4 racoon: INFO: IPsec-SA expired: ESP/Tunnel
B.1.1.1->A.1.1.1 spi=163553378(0x9bfa062)
Mar  9 13:58:15 rhel4 racoon: INFO: IPsec-SA expired: AH/Tunnel A.1.1.1->B.1.1.1
spi=153390621(0x9248e1d
...

RHEL3:
# cat /etc/sysconfig/network-scripts/ifcfg-ipsec0
DEVICE=ipsec0
TYPE=IPsec
ONBOOT=yes
IKE_METHOD=PSK
SRCGW=B.1.1.1
DSTGW=A.1.1.1
SRCNET=10.0.1.0/24
DSTNET=10.0.0.0/24
DST=A.1.1.1
# cat /etc/sysconfig/network-scripts/keys-ipsec0
IKE_PSK=SecretkeY


Mar  9 13:46:42 rhel3 racoon: INFO: pfkey.c:1394:pk_recvexpire(): IPsec-SA
expired: ESP/Tunnel B.1.1.1->A.1.1.1 spi=186300334(0xb1ab7ae)
Mar  9 13:46:42 rhel3 racoon: INFO: pfkey.c:1127:pk_recvupdate(): IPsec-SA
established: AH/Tunnel A.1.1.1->B.1.1.1 spi=93102862(0x58ca30e)
Mar  9 13:46:42 rhel3 racoon: INFO: pfkey.c:1127:pk_recvupdate(): IPsec-SA
established: ESP/Tunnel A.1.1.1->B.1.1.1 spi=197907145(0xbcbd2c9)
Mar  9 13:46:42 rhel3 racoon: INFO: pfkey.c:1348:pk_recvadd(): IPsec-SA
established: AH/Tunnel B.1.1.1->A.1.1.1 spi=28687864(0x1b5bdf8)
Mar  9 13:46:43 rhel3 racoon: ERROR: pfkey.c:741:pfkey_timeover(): A.1.1.1 give
up to get IPsec-SA due to time up to wait.
Mar  9 13:46:43 rhel3 racoon: INFO: pfkey.c:1348:pk_recvadd(): IPsec-SA
established: ESP/Tunnel B.1.1.1->A.1.1.1 spi=118201422(0x70b9c4e)
Mar  9 13:46:43 rhel3 racoon: INFO: pfkey.c:1127:pk_recvupdate(): IPsec-SA
established: AH/Tunnel A.1.1.1->B.1.1.1 spi=93102862(0x58ca30e)

Charles: I believe 0.5 is all that's needed to fix the fwd policy.

Milan: see also bug 145424. It *appears* the crosstalk problem between
RHEL 3 and RHEL 4 is unrelated to the fwd issue.

hi bill,

agreed: for me, your fix is working great -- fwd policy is established
correctly.

thanks for your attentive help,

charles

I agree. It seems that we are able to close this bug as RAWHIDE IMHO.

hi once more,

as this is a bug under an up2date rhel 4, should not it be closed with
status ERRATA?

cheers

charles

It was my fault. There is an fixed package in FC devel tree so this
could be closed as RAWHIDE. See comment #5 for a package for RHEL4.

Reopening until something more official for RHEL 4 is pushed.

A version of 0.3.3 with forward policy support backported is
now at http://people.redhat.com/notting/ipsec/

This will likely be pushed instead of 0.5.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-232.html

Not really on RHEL4, kind of taking a free ride here (system built from RHEL4
SRPM packages).

The updated ipsec-tools do not work correctly in my case.  I have simple
net-2-net configuration, configured to use X509 certificates.  The configuration
file looks something like this:

DST=192.168.1.100
SRCNET=192.168.0.0/24
DSTNET=192.168.1.0/24
TYPE=IPSEC
ONBOOT=no
IKE_METHOD=X509
IKE_CERTFILE=/etc/racoon/certs/host-a
IKE_PEER_CERTFILE=/etc/racoon/certs/host-b 

Similar configuration on remote end.  I'm using patched ifup-ipsec and
ifdown-ipsec scripts as described in bug #146169.  The system is patched with
all updates that Red Hat released (using SRPMs).  When I bring "interfaces" up
with "ifup vpn0", and try to ping from host-a to host-b, first I get usual and
normal "Resource temporarily unavailable".  When I try to ping again, nothing
happens.  Using tcpdump I can see host-a sending AH/ESP packets to host-b, and I
can see host-b attempting to renegotiate encryption keys.  I can attach tcpdump
output, if anybody is interested.  Also, if I check /var/log/messages, I can see
the same thing.  Using "setkey -D" I see growing SAD lists on both hosts. 
"setkey -DP" shows in, out, and fwd rules being correctly set (or at least they
appear that way to me).

If I don't use ifup (ifup-ipsec) and configure things manually so that AH is not
used (only ESP) like this:

setkey -F
setkey -FP
/sbin/setkey -c <<EOF
spdadd 192.168.1.0/24 192.168.0.0/24 any -P in ipsec
        esp/tunnel/192.168.1.100-192.168.0.100/require;
spdadd 192.168.0.0/24 192.168.1.0/24 any -P out ipsec
        esp/tunnel/192.168.0.100-192.168.1.100/require;
EOF
/sbin/ip route add 192.168.1.0/24 via 192.168.0.100 src 192.168.0.100
/usr/sbin/racoon

then things seem to work for some time.  Racoon configuration is the same as
generated by ifup-ipsec script.  However after some period of inactivity, if I
attempt to generate some more network traffic (for example ping remote end),
same thing happens.  Racoon attempts to establish new encryption keys again and
again in a loop.  It seems as it is successfull every time, at least by "setkey
-D" output on both hosts.  After some time, SAD list is so large, that "setkey
-D" gives up when printing it with error.

As I said, I'm kind of taking a free ride.  I'm not asking for any kind of
support.  However this smells like it might be a bug in RHEL4, and if anybody is
interested looking into it (to save some potential grief to paying customers), I
can attach tcpdump output, as well as relevant parts of /var/log/messages and
output of setkey -D (while the list of SAD entries was still managably "small").

The only case when things work reliably was if I setup static manual encryption
keys (KEY_AH{_IN,_OUT}, KEY_ESP{_IN,_OUT}, SPI_{ESP,AH_{IN,OUT}} variables). 
BTW, while we are at this type of setup, system-config-network tool should allow
user to enter values for SPI_{ESP,AH_{IN,OUT}}.  They need to match on both
sides (INs on one side should match OUTs on the other side).  If they are
randomly generated on both sides (and do not match), things are not going to work.

First: I do not use system-config-network and the ifcfg-ipsec to build my net-2
net connections. Because I have dynamic ip adresses on both IPSec-VPN-Gateways I
use my own script for IPSec configuration.
I use only ESP and X509 certificates in RHEL and I do not plan to use AH.

But I know this problem:

> Racoon attempts to establish new encryption keys again and again in a loop.

In Bugzilla #145424 you can find the reason and the solution. This is a bug in
2.6 kernel.

Fixed kernel available at http://people.redhat.com/notting/ipsec/ or a newer in
RHN RHEL4 BETA Channel. This kernel fix will come with RHEL4 U1 soon.