From owner-freebsd-security Sun May 12 3: 6:37 2002 Delivered-To: freebsd-security@freebsd.org Received: from dubb05h07-0.dplanet.ch (dubb05h07-0.dplanet.ch [212.35.36.31]) by hub.freebsd.org (Postfix) with ESMTP id 25DE837B403 for ; Sun, 12 May 2002 03:06:26 -0700 (PDT) Received: (from luser@localhost) by dubb05h07-0.dplanet.ch (8.11.6/8.11.6) id g4CA6FM01637; Sun, 12 May 2002 12:06:15 +0200 Date: Sun, 12 May 2002 12:06:15 +0200 Message-Id: <200205121006.g4CA6FM01637@dubb05h07-0.dplanet.ch> X-Authentication-Warning: dubb05h07-0.dplanet.ch: luser set sender to quak@mydiax.ch using -f Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.411 (Entity 5.404) From: quak@mydiax.ch To: freebsd-security@FreeBSD.org Subject: IPSEC: is ipcomp broken in 4.5-stable ? Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Greetings, Is there anyone who have gotten the ipsec compression (ipcomp) working in t= he 4.5-stable ?? We try to establish a transport compression between 2 machines with followi= ng setkey setup Box 1 (192.168.20.1) add 192.168.20.1 192.168.10.1 ipcomp 2010 -C deflate; add 192.168.10.1 192.168.20.1 ipcomp 1020 -C deflate; spdadd 192.168.20.1 192.168.10.1 any -P out ipsec ipcomp/transport//require; spdadd 192.168.10.1 192.168.20.1 any -P in ipsec ipcomp/transport//require; Box 2 (192.168.10.1) add 192.168.20.1 192.168.10.1 ipcomp 2010 -C deflate; add 192.168.10.1 192.168.20.1 ipcomp 1020 -C deflate; spdadd 192.168.10.1 192.168.20.1 any -P out ipsec ipcomp/transport//require; spdadd 192.168.20.1 192.168.10.1 any -P in ipsec ipcomp/transport//require; Now we can ping both machines, but as soon as we begin doing a simple ftp t= ransfer from box1 to box2, the transfer will *always* hang up at the 34816 = bytes transferred. There seems to be some mess in the compression / decompression mechanism, b= ecause if we add a racoon to this mix (Default configuration, no changes to= racoon.conf, just psk.txt entries on both boxes) the transfers suddenly be= gin to work better, that is: we infact get some major speed boost, but it c= omes in waves, time to time boxes will spit out something like=20 ipcomp_decompress: inflate(Z_FINISH): unknown error (-2) and transfer will = stall for 3-6 seconds, the proceed again. Also, the setkey does not accept lzs as an compression option. man setkey s= ays that it should. What is going on ? Regards Kirill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message