Bug 150179 - ipsec/racoon/setkey does not properly forward packets to vpn peer
ipsec/racoon/setkey does not properly forward packets to vpn peer
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: ipsec-tools (Show other bugs)
4.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-03 07:12 EST by charles schick
Modified: 2014-03-16 22:52 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-23 05:10:32 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description charles schick 2005-03-03 07:12:03 EST
hi bill,

Description of problem:

ipsec works for for host-> host vpns
host->net, roadwarrior cannot work

Version-Release number of selected component (if applicable):

ipsec-tools-0.3.3-2.1


How reproducible:
always

Description:
the "fwd" policy in setkey is not respected if presented to a server
from a client. additionally, it is not "added" as default policy for a
connection that would need it. 

assume a client trying to connect from a host to lan. if we use the
following policy on the client, the server will not add the "fwd"
policy, thusly, packets from the lan are not forwarded.

spdadd 172.16.11.0/24 172.16.12.27/32 any -P fwd  ipsec
esp/tunnel/172.16.12.254-172.16.12.27/require;

spdadd 172.16.12.27/32 172.16.11.0/24 any -P out ipsec
esp/tunnel/172.16.12.27-172.16.12.254/require;

spdadd 172.16.11.0/24 172.16.12.27/32 any -P in  ipsec
esp/tunnel/172.16.12.254-172.16.12.27/require;

a windows client connecting to the server will experience the same
issue -- the "in" and "out" policies are added by the server (assuming
generate_policy on in racoon.conf) however, no forwarding takes place.

apparently this issue is addressed in ver 0.5 of ipsec-tools. probably
worth building or patching the existing -- red hat enterprise linux
ought to be able to support vpns.

cheers

charles
Comment 1 Bill Nottingham 2005-03-03 12:40:08 EST
This should not be an issue with the shipped-with-RHEL kernel. What
kernel are you using?
Comment 2 charles schick 2005-03-04 05:46:29 EST
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
Comment 3 charles schick 2005-03-04 07:12:59 EST
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

Comment 4 Bill Nottingham 2005-03-04 13:06:05 EST
*Sigh*. As I understand it, the code that required forward policies
was only added in 2.6.10. Will check some more.
Comment 5 Bill Nottingham 2005-03-04 15:23:57 EST
Yes, that patch is in the RHEL4 kernel. Please try the ipsec-tools at:

http://people.redhat.com/notting/ipsec/
Comment 6 Uwe Beck 2005-03-05 07:01:26 EST
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.

Comment 7 Uwe Beck 2005-03-05 16:31:20 EST
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.
Comment 8 charles schick 2005-03-07 03:41:29 EST
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
Comment 9 charles schick 2005-03-07 05:39:57 EST
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
Comment 10 Bill Nottingham 2005-03-07 14:40:47 EST
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.)
Comment 11 charles schick 2005-03-08 04:29:52 EST
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

Comment 12 Bill Nottingham 2005-03-08 12:04:14 EST
There's a 0.5-1.RHEL4 in that directory with those fixes.
Comment 13 Milan Kerslager 2005-03-09 08:15:12 EST
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)
Comment 14 Bill Nottingham 2005-03-10 19:16:27 EST
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.
Comment 15 charles schick 2005-03-11 03:35:14 EST
hi bill,

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

thanks for your attentive help,

charles
Comment 16 Milan Kerslager 2005-03-11 04:52:33 EST
I agree. It seems that we are able to close this bug as RAWHIDE IMHO.
Comment 17 charles schick 2005-03-11 05:17:37 EST
hi once more,

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

cheers

charles
Comment 18 Milan Kerslager 2005-03-11 05:45:14 EST
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.
Comment 19 Bill Nottingham 2005-03-11 16:06:21 EST
Reopening until something more official for RHEL 4 is pushed.
Comment 20 Bill Nottingham 2005-03-11 17:19:51 EST
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.
Comment 21 Mark J. Cox (Product Security) 2005-03-23 05:10:32 EST
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
Comment 22 Aleksandar Milivojevic 2005-05-13 17:06:45 EDT
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.
Comment 23 Uwe Beck 2005-05-14 07:42:37 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.