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
This is a cryptographically signed message in MIME format.
--------------ms50176497FAAA46CD92274AF2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
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
--------------ms50176497FAAA46CD92274AF2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIIIIwYJKoZIhvcNAQcCoIIIFDCCCBACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BfQwggLYMIICQaADAgECAgMDIwUwDQYJKoZIhvcNAQEEBQAwgZQxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYDVQQKEwZU
aGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJzb25h
bCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MB4XDTAwMDgyNDIwMzAwOFoXDTAxMDgyNDIwMzAw
OFowVDEPMA0GA1UEBBMGRWdnZXJ0MQ0wCwYDVQQqEwRMYXJzMRQwEgYDVQQDEwtMYXJzIEVn
Z2VydDEcMBoGCSqGSIb3DQEJARYNbGFyc2VAaXNpLmVkdTCBnzANBgkqhkiG9w0BAQEFAAOB
jQAwgYkCgYEAz1yfcNs53rvhuw8gSDvr2+/snP8GduYY7x7WkJdyvcwb4oipNpWYIkMGP214
Zv1KrgvntGaG+jeugAGQt0n64VusgcIzQ6QDRtnMgdQDTAkVSQ2eLRSQka+nAPx6SFKJg79W
EEHmgKQBMtZdMBYtYv/mTOcpm7jTJVg+7W6n04UCAwEAAaN3MHUwKgYFK2UBBAEEITAfAgEA
MBowGAIBBAQTTDJ1TXlmZkJOVWJOSkpjZFoyczAYBgNVHREEETAPgQ1sYXJzZUBpc2kuZWR1
MAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUiKvxYINmVfTkWMdGHcBhvSPXw4wwDQYJKoZI
hvcNAQEEBQADgYEAi65fM/jSCaPhRoA9JW5X2FktSFhE5zkIpFVPpv33GWPPNrncsK13HfZm
s0B1rNy2vU7UhFI/vsJQgBJyffkLFgMCjp3uRZvBBjGD1q4yjDO5yfMMjquqBpZtRp5op3lT
d01faA58ZCB5sxCb0ORSxvXR8tc9DJO0JIpQILa6vIAwggMUMIICfaADAgECAgELMA0GCSqG
SIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYD
VQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9D
ZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9uMSQwIgYDVQQDExtUaGF3dGUgUGVyc29u
YWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEWHHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0
ZS5jb20wHhcNOTkwOTE2MTQwMTQwWhcNMDEwOTE1MTQwMTQwWjCBlDELMAkGA1UEBhMCWkEx
FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoT
BlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNv
bmFsIEZyZWVtYWlsIFJTQSAxOTk5LjkuMTYwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGB
ALNpWpfU0BYLerXFXekhnCNyzRJMS/d+z8f7ynIk9EJSrFeV43theheE5/1yOTiUtOrtZaeS
Bl694GX2GbuUeXZMPrlocHWEHPQRdAC8BSxPCQMXMcz0QdRyxqZd4ohEsIsuxE3x8NaFPmzz
lZR4kX5A6ZzRjRVXjsJz5TDeRvVPAgMBAAGjNzA1MBIGA1UdEwEB/wQIMAYBAf8CAQAwHwYD
VR0jBBgwFoAUcknCczTGVfQLdnKBfnf0h+fGsg4wDQYJKoZIhvcNAQEEBQADgYEAa8ZZ6TH6
6bbssQPY33Jy/pFgSOrGVd178GeOxmFw523CpTfYnbcXKFYFi91cdW/GkZDGbGZxE9AQfGuR
b4bgITYtwdfqsgmtzy1txoNSm/u7/pyHnfy36XSS5FyXrvx+rMoNb3J6Zyxrc/WG+Z31AG70
HQfOnZ6CYynvkwl+Vd4xggH3MIIB8wIBATCBnDCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgT
DFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEd
MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt
YWlsIFJTQSAxOTk5LjkuMTYCAwMjBTAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAwMTEwOTE4MzgzN1owIwYJKoZIhvcNAQkEMRYE
FJnGfmztehuIjlnLvzPr2VJq34GkMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYI
KoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0G
CSqGSIb3DQEBAQUABIGAGg4dQ0XwdHZ8dZ3CKd9eglnvr99tlnW6Wh4W0ETF8+uAG+7RPoe7
TYeTtxicxIVQtgqZV/d5Nl+vvz51EV5TWwe/YFQmZ7QndQpehjM4saS1IgS+kFs7tymT3L5X
TQLCz/u3/0bORJ1kHjUa1QgT6Gsrj7QnJUrlQzXNHT9QcoA=
--------------ms50176497FAAA46CD92274AF2--
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?3A0AEF2D.7665487F>