Date: Wed, 10 Jul 2002 09:43:38 -0000 From: "Duncan Patton a Campbell" <campbell@neotext.ca> To: <security@FreeBSD.ORG> Subject: racoon/FreeBSD 4.5 problems & observations Message-ID: <200207100943.g6A9hcA01547@localhost.neotext.ca>
next in thread | raw e-mail | index | archive | help
Ok, so here are my observations wrt racoon and problems with FreeBSD
I have a vpn with 3 nodes that is used for system maintenance and to
transfer data around a replicated mysql database.
Two of the nodes are 4.3. These are visible to the net as www.indx.ca
(ww1 and ww2, individually).
The third node is ww0.indx.ca and is used for system maintenance and
development. Until recently ww0 was also a 4.3 node.
While all three nodes were running 4.3, I was able to run the VPN using
the racoon key server. Everything was hunky-dory.
Then I upgraded (several months or so ago) ww0 to run 4.5. On doing this
I first found my /var/log/racoon.log would bloat and overrun the
filesystem (the 110% useage syndrome). So I then linked /var/log/racoon.log
to /dev/null and ran like that. No good. The racoon task would bloat
by 4k per packet transmitted across the VPN to the 4.5 node and would
quickly reach 2, 3 or 4 hundred megabytes in memory useage. Didn't matter
whether I was setting up for tunnel or transport. And it didn't matter
which version of the racoon task I was using: binaries from 4.3 behaved
as badly on the 4.5 system as did the latest release. Same with binaries
I compiled on both systems.
What this implies is either
1. there is a flaw in racoon that is sensitive to 4.5 (and beyond???)
or
2. there is a flaw in some library called by racoon on the 4.5 system
which may be in syslogd but does not evidence itself in the logging or
behaviour of any other 4.5 system task.
Very queer. I sent my configs to Munechika Sumikawa <sumikawa@FreeBSD.org>
and haven't heard anything back, from which I must assume that he can't
find anything wrong with them either.
So I have reverted to a static configuration using host<->host transport.
(tunneled is a little more complicated and needs gif configuration...)
Here are my static configs (suitably edited) for your use/perusal. To
test that your encryption is in place (*not* testing for quality of
encryption) do:
tcpdump -e -s1500 -w - | grep wheel
on one system
and
ls -l /usr/bin
on the other.
if the pipe breaks, grep found "wheel" in the tcpdump and you
aren't set up right. You will see something like:
babayaga# tcpdump -e -s1500 -w - | grep wheel
tcpdump: listening on xl0
Binary file (standard input) matches
if you aren't setup rite.
In these shell scripts you need to do the following replacements:
IPA_addr -> Node A's IP address in dotted quad (WWW.XXX.YYY.ZZZ)
IPD_addr -> Node D's IP address in dotted quad (WWW.XXX.YYY.ZZZ)
BFkey8ch -> An 8 character key for Blowfish
HMAC_SHA1_KEY_20char -> A 20 character key for the hmac
INT16A -> an int16 for the D to A sequence start
INT16B -> an int16 for the A to D sequence start
Put the scripts somewhere they will get executed on boot,
run chown root and chmod 700 on them, and away you go...
Please do let me know of any flaws you see ;-)
Dhu
#!/bin/sh
# Node A script
setkey -c << EOF
spdflush ; flush ;
# A <-> D
spdadd IPA_addr/32 IPD_addr/32 any -P out ipsec
esp/transport/IPA_addr-IPD_addr/require;
spdadd IPD_addr/32 IPA_addr/32 any -P in ipsec
esp/transport/IPD_addr-IPA_addr/require;
add IPD_addr IPA_addr esp INT16A -m transport -E blowfish-cbc "BFkey8ch" -A
hmac-sha1 "HMAC_SHA1_KEY_20char";
add IPA_addr IPD_addr esp INT16B -m transport -E blowfish-cbc "BFkey8ch" -A
hmac-sha1 "HMAC_SHA1_KEY_20char";
EOF
exit 0
#!/bin/sh
# Node D script
setkey -c << EOF
spdflush ; flush ;
# D <-> A
spdadd IPA_addr/32 IPD_addr/32 any -P in ipsec
esp/transport/IPA_addr-IPD_addr/require;
spdadd IPD_addr/32 IPA_addr/32 any -P out ipsec
esp/transport/IPD_addr-IPA_addr/require;
add IPD_addr IPA_addr esp INT16A -m transport -E blowfish-cbc "BFkey8ch" -A
hmac-sha1 "HMAC_SHA1_KEY_20char";
add IPA_addr IPD_addr esp INT16B -m transport -E blowfish-cbc "BFkey8ch" -A
hmac-sha1 "HMAC_SHA1_KEY_20char";
EOF
exit 0
--
Duncan (Dubh) Campbell ;-)
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207100943.g6A9hcA01547>