Date: Fri, 10 Nov 2000 02:32:01 +1100 From: "Chris Cason" <casonc@netplex.aussie.org> To: <freebsd-bugs@freebsd.org> Cc: <freebsd-stable@freebsd.org> Subject: Bug or feature ? Message-ID: <005701c04a62$366f7b20$023a1dac@dsat.net.au>
next in thread | raw e-mail | index | archive | help
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-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?005701c04a62$366f7b20$023a1dac>