Date: Sun, 18 May 2008 21:37:35 +0800 (KRAST) From: Eugene Grosbein <eugen@grosbein.pp.ru> To: FreeBSD-gnats-submit@FreeBSD.org Subject: kern/123793: [ipsec] [patch] KAME IPSEC does not pass processed packets to pfil hooks Message-ID: <200805181337.m4IDbZ8A090662@grosbein.pp.ru> Resent-Message-ID: <200805181340.m4IDe2S5068222@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200805181337.m4IDbZ8A090662>