From owner-freebsd-net@FreeBSD.ORG Tue Nov 18 07:32:39 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98EF616A4FE for ; Tue, 18 Nov 2003 07:32:39 -0800 (PST) Received: from mizar.origin-it.net (mizar.origin-it.net [194.8.96.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 125E7442A3 for ; Tue, 18 Nov 2003 07:28:01 -0800 (PST) (envelope-from helge.oldach@atosorigin.com) Received: from matar.hbg.de.int.atosorigin.com (dehsfw3e.origin-it.net [194.8.96.68])hAIFRwUQ034866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 18 Nov 2003 16:27:59 +0100 (CET) (envelope-from helge.oldach@atosorigin.com) Received: from galaxy.hbg.de.ao-srv.com (galaxy.hbg.de.ao-srv.com [161.89.20.4])ESMTP id hAIFRw35082753; Tue, 18 Nov 2003 16:27:58 +0100 (CET) (envelope-from helge.oldach@atosorigin.com) Received: (from hmo@localhost) by galaxy.hbg.de.ao-srv.com (8.9.3p2/8.9.3/hmo30mar03) id QAA03150; Tue, 18 Nov 2003 16:27:54 +0100 (MET) Message-Id: <200311181527.QAA03150@galaxy.hbg.de.ao-srv.com> In-Reply-To: <000801c3adba$17a09cb0$115dcfc2@nico> from Jamie Heckford at "Nov 18, 2003 10:55:26 am" To: jamie@tridentmicrosystems.co.uk From: Helge Oldach X-Address: Atos Origin GmbH, Friesenstraße 13, D-20097 Hamburg, Germany X-Phone: +49 40 7886 7464, Fax: +49 40 7886 9464, Mobile: +49 160 4782517 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: Problem with Racoon/IPSec/Setkey - Routing to/from multiple n etwo rks X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Tue, 18 Nov 2003 15:32:39 -0000 X-Original-Date: Tue, 18 Nov 2003 16:27:54 +0100 (MET) X-List-Received-Date: Tue, 18 Nov 2003 15:32:39 -0000 Jamie Heckford: >Helge Oldach wrote: >> Jamie Heckford: >>> /usr/sbin/setkey -c << EOF >>> flush; >>> spdflush; >>> spdadd ${LOCAL_NETWORK} ${STJUST_NETWORK} any -P out ipsec >>> esp/tunnel/${LOCAL_OUTSIDE}-${STJUST_OUTSIDE}/require; >>> spdadd ${STJUST_NETWORK} ${LOCAL_NETWORK} any -P in ipsec >>> esp/tunnel/${STJUST_OUTSIDE}-${LOCAL_OUTSIDE}/require; >>> spdadd ${ALLNET_1} ${STJUST_NETWORK} any -P out ipsec >>> esp/tunnel/${LOCAL_OUTSIDE}-${STJUST_OUTSIDE}/require; >>> spdadd ${STJUST_NETWORK} ${ALLNET_1} any -P in ipsec >>> esp/tunnel/${STJUST_OUTSIDE}-${LOCAL_OUTSIDE}/require; >>> spdadd ${LOCAL_NETWORK} ${BENELUX_NETWORK} any -P out ipsec >>> esp/tunnel/${LOCAL_OUTSIDE}-${BENELUX_OUTSIDE}/require; >>> spdadd ${BENELUX_NETWORK} ${LOCAL_NETWORK} any -P in ipsec >>> esp/tunnel/${BENELUX_OUTSIDE}-${LOCAL_OUTSIDE}/require; >>> spdadd ${ALLNET_1} ${BENELUX_NETWORK} any -P out ipsec >>> esp/tunnel/${LOCAL_OUTSIDE}-${BENELUX_OUTSIDE}/require; >>> spdadd ${BENELUX_NETWORK} ${ALLNET_1} any -P in ipsec >>> esp/tunnel/${BENELUX_OUTSIDE}-${LOCAL_OUTSIDE}/require; >>> EOF >> >> Try using "unique" instead of "require". >> >> Helge > >Thanks a lot Helge, this worked fine :) > >What does unique do instead of require..? Frankly, I never understood this in detail. "unique" appears to tie together the SA and the policy and appears to ensure that the correct SA is being used for a policy. But then I don't see what "require" would be useful for at all, as the "unique" behaviour is what one usually wants to achieve when using IKE (racoon). Actually this question pops up every now and then, with always the same answer. :-) For example, if you're talking against a Cisco VPN gateway, you *must* use unique, otherwise it won't work at all. Maybe somebody else can shed some light into the matter? Helge