From owner-freebsd-bugs@FreeBSD.ORG Sun May 18 13:40:02 2008 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E2ED1065673 for ; Sun, 18 May 2008 13:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7BBFC8FC37 for ; Sun, 18 May 2008 13:40:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m4IDe2H3068229 for ; Sun, 18 May 2008 13:40:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m4IDe2S5068222; Sun, 18 May 2008 13:40:02 GMT (envelope-from gnats) Resent-Date: Sun, 18 May 2008 13:40:02 GMT Resent-Message-Id: <200805181340.m4IDe2S5068222@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Eugene Grosbein Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22A1C1065674 for ; Sun, 18 May 2008 13:37:51 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (grgw.svzserv.kemerovo.su [213.184.64.166]) by mx1.freebsd.org (Postfix) with ESMTP id 2E5EF8FC1B for ; Sun, 18 May 2008 13:37:48 +0000 (UTC) (envelope-from eugen@grosbein.pp.ru) Received: from grosbein.pp.ru (localhost [127.0.0.1]) by grosbein.pp.ru (8.14.2/8.14.2) with ESMTP id m4IDbZRQ090663 for ; Sun, 18 May 2008 21:37:36 +0800 (KRAST) (envelope-from eugen@grosbein.pp.ru) Received: (from eugen@localhost) by grosbein.pp.ru (8.14.2/8.14.2/Submit) id m4IDbZ8A090662; Sun, 18 May 2008 21:37:35 +0800 (KRAST) (envelope-from eugen) Message-Id: <200805181337.m4IDbZ8A090662@grosbein.pp.ru> Date: Sun, 18 May 2008 21:37:35 +0800 (KRAST) From: Eugene Grosbein To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Cc: Subject: kern/123793: [ipsec] [patch] KAME IPSEC does not pass processed packets to pfil hooks X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eugene Grosbein List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 May 2008 13:40:02 -0000 >Number: 123793 >Category: kern >Synopsis: [ipsec] [patch] KAME IPSEC does not pass processed packets to pfil hooks >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Sun May 18 13:40:02 UTC 2008 >Closed-Date: >Last-Modified: >Originator: Eugene Grosbein >Release: FreeBSD 6.3-STABLE i386 >Organization: Svyaz-Service JSC >Environment: System: RELENG_6 >Description: (This issue applies to RELENG_6 only, as newer versions do not contain KAME IPSEC implementation anymore.) When AH, ESP or IPCOMP protocols finish packets processing, they pass them directly to pr_input() for appropriate encapsulated protocol. Thus, it is not possible to filter incoming packets processed with this IPSEC implementation after they has been decrypted. Let's consider simple schema: L-R+G-Internet Here R is a router (FreeBSD 6.3), L is a host in its LAN using private IP-addresses (RFC 1918). Plus sign designates provider's radio-ethernet segment built with L2 radio-bridges, G is provider's gateway to the Internet. R and G use public IP-addresses within radio-ethernet, so R does NAT for L. There is also another host H in the same radio-ethernet segment, in the same IP-network as R and G, it has public IP-address. We need to protect traffic between R and H so run IPSEC on R and H. It works nice for traffic running between R and G. Now let's see what happens when L connects to H. Outgoing packet from L goes through NAT on R, translated packet then goes through IPSEC and finally reaches H. Now H sends its encrypted reply that reaches R that decrypts it. But IPSEC does not pass decrypted packed downto ip_input(), it passes it to pr_input() directly so H's reply gets delivered locally instead of being NAT'ed and forwarded. Finally, it is dropped. Kernel option IPSEC_FILTERGIF should help in this case but it does not. Newer FAST_IPSEC implementation does not have this problem, it passes decrypted answer to ip_input() via netisr, so it reaches pfil hooks and may be processed with NAT and then routed successfully. However, switching to FAST_IPSEC is not an option when we require working IPCOMP support. See this PR for details: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/123587 So, the solution is to make kernel option IPSEC_FILTERGIF to cover this case and pass decrypted incoming packet again to ip_input() via netisr just like FAST_IPSEC does, thus bringing old implementation's behavour more in line with new one. >How-To-Repeat: See description >Fix: The patch is pretty small and simple: ftp://www.kuzbass.ru/pub/freebsd/patches/ipsec-filter.diff.gz >Release-Note: >Audit-Trail: >Unformatted: