Skip site navigation (1)Skip section navigation (2) 
Date:      Thu, 09 Nov 2000 10:38:37 -0800
From:      Lars Eggert <larse@ISI.EDU>
To:        Chris Cason <casonc@netplex.aussie.org>
Cc:        freebsd-bugs@freebsd.org, freebsd-stable@freebsd.org
Subject:   Re: Bug or feature ?
Message-ID:  <3A0AEF2D.7665487F@isi.edu>
References:  <005701c04a62$366f7b20$023a1dac@dsat.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help 

[-- Attachment #1 --]
I submitted that patch on behalf of the X-Bone project to both KAME and
FreeBSD. Jun-ichiro itojun Hagino from KAME has just identified the same
problem: The patch is too restrictive if ANY SAs are used. Sorry for
introducing this problem. We didn't catch it here because we do not use ANY
SAs in our VPN setups. The correct patch should be:

  /* do not decapsulate if the SA is for transport mode only */
  if (sav->sah->saidx.mode == IPSEC_MODE_TRANSPORT)
          return 0;

A full patch is available from
http://www.kame.net/dev/cvsweb.cgi/kame/kame/sys/netinet6/ipsec.c.diff?r1=1.82&r2=1.83

Pending approval, could the fix please be committed to -STABLE?

Thanks,
Lars


Chris Cason wrote:
> 
> Yesterday I updated a 4.1-STABLE gateway via cvsup (tracking RELENG_4)
> and discovered that the machines sitting behind the gateway that had
> previously been communicating via an IPSEC VPN stopped talking.
> 
> After some hair-pulling I upgraded the other gateway(s) as I suspected
> that it may have been a change to the ipsec code that required to be
> done at both ends, but unfortunately it didn't help.
> 
> The symptom was that IPSEC transport mode between the gateways would
> still work fine, but that any tunnelled packets would get swallowed up
> upon receipt inside the kernel of the newly-upgraded machine (they went
> out fine). netstat showed no errors, with the IPSEC received packet count
> incrementing as expected, but the data never saw the light of day.
> 
> Investigation showed that version 1.7 of netinet6/ipsec.c (v1.3.2.3 of
> RELENG_4) which was put into CVS a few days ago had the following added
> to the function ipsec4_tunnel_validate () (at line 3151)
> 
>   if (sav->sah->saidx.mode != IPSEC_MODE_TUNNEL)
>     return 0;
> 
> Since my SAD entries were configured to mode 'ANY' (the default, which is
> exactly what I want since I encrypt both the tunneled traffic for the VPN
> and the normal transport-level traffic between the gateways), the received
> tunneled traffic was all being dropped.
> 
> While I could work around this by not using mode 'any' I chose to patch
> instead - removing the above code from ipsec.c and rebuilding the kernel
> solved the problem.
> 
> The question I have is if this is a bug or not. The change shown above was
> the only change (along with ipsec6_tunnel_validate) between v1.6 and 1.7 of
> ipsec.c, so it is obviously very deliberate and must have some logic behind
> it.
> 
> Can anyone suggest if this is a bug or is it intentional ? [If the latter
> you may want to change the docs as I've already seen someone on the SAGE-AU
> mailing list with this exact fault, except he's trying to set up a tunnel
> for the first time and as such believes it's his fault; I was fortunate in
> that I had a working setup previously to compare against].
> 
> -- Chris
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message

-- 
Lars Eggert <larse@isi.edu>                 Information Sciences Institute
http://www.isi.edu/larse/                University of Southern California
[-- Attachment #2 --]
0#	*H
010	+0	*H
00A#0
	*H
010	UZA10UWestern Cape10UDurbanville10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 1999.9.160
000824203008Z
010824203008Z0T10
UEggert1
0U*Lars10ULars Eggert10	*H
	
larse@isi.edu00
	*H
0\p9޻ H;v֐r∩6"C?mxfJf7I[3CF́L	I
-zHRVA怤2]0-bL)%X>nӅw0u0*+e!000L2uMyffBNUbNJJcdZ2s0U0
larse@isi.edu0U00U#0`fUXFa#Ì0
	*H
_3	F=%nWY-HXD9UOc6ܰwf@uܶNԄR?Pr}E1֮23mFhySwM_h|d yR=$P 00}0
	*H
010	UZA10UWestern Cape10U	Cape Town10U
Thawte Consulting1(0&UCertification Services Division1$0"UThawte Personal Freemail CA1+0)	*H
	personal-freemail@thawte.com0
990916140140Z
010915140140Z010	UZA10UWestern Cape10UDurbanville10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 1999.9.1600
	*H
0iZz]!#rLK~r$BRW{azr98e^eyvL>hput,O	1ArƦ]D.Mօ>lx~@эWs0FO7050U00U#0rIs4Uvr~wƲ0
	*H
kY1rr`HU{gapm¥7؝(V\uoƑlfq|ko!6-	-mƃRt\~
orzg,ksnΝc)	~U100010	UZA10UWestern Cape10UDurbanville10
U
Thawte10UCertificate Services1(0&UPersonal Freemail RSA 1999.9.16#0	+0	*H
	1	*H
0	*H
	1
001109183837Z0#	*H
	1~lzY˿3Rj߁0R	*H
	1E0C0
*H
0*H
0+0
*H
@0
*H
(0
	*H
CEtv|u)^YmuZD>MąP
Wy6_>u^S[`T&g'u
^38"[;)ܾWMFDd5k+'%JC5?Pr

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3A0AEF2D.7665487F>