Skip site navigation (1)Skip section navigation (2) 
Date:      Wed, 18 Jan 2017 10:21:06 +0000 (UTC)
From:      "Andrey V. Elsukov" <ae@FreeBSD.org>
To:        src-committers@freebsd.org, svn-src-projects@freebsd.org
Subject:   svn commit: r312377 - projects/ipsec/sys/netipsec
Message-ID:  <201701181021.v0IAL6sZ066489@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help 
Author: ae
Date: Wed Jan 18 10:21:06 2017
New Revision: 312377
URL: https://svnweb.freebsd.org/changeset/base/312377

Log:
  Do not require the presence of tunnel mode IPsec request for outbound
  security policies used by IPSEC_FORWARD() method.
  
  The rationale for this requirement was the need for handling encrypted
  replies. We can handle replies, only if they are destined for our
  addresses. And since we are doing forwarding, this usually means that
  source address of packet is not our own. But some users reported, that
  they are doing source address translation for forwarded packets. In this
  case pfil(9) does NAT and source address becomes our own, then packet
  is sent to forwarding routine, where it can be matched by security policy
  with transport mode IPsec request.

Modified:
  projects/ipsec/sys/netipsec/ipsec_output.c

Modified: projects/ipsec/sys/netipsec/ipsec_output.c
==============================================================================
--- projects/ipsec/sys/netipsec/ipsec_output.c	Wed Jan 18 09:46:02 2017	(r312376)
+++ projects/ipsec/sys/netipsec/ipsec_output.c	Wed Jan 18 10:21:06 2017	(r312377)
@@ -302,7 +302,7 @@ static int
 ipsec4_common_output(struct mbuf *m, struct inpcb *inp, int forwarding)
 {
 	struct secpolicy *sp;
-	int error, idx;
+	int error;
 
 	/* Lookup for the corresponding outbound security policy */
 	sp = ipsec4_checkpolicy(m, inp, &error);
@@ -315,22 +315,15 @@ ipsec4_common_output(struct mbuf *m, str
 		return (0); /* No IPsec required. */
 	}
 
-	if (forwarding) {
-		/*
-		 * Check that SP has tunnel mode IPsec transform.
-		 * We can't use transport mode when forwarding.
-		 */
-		for (idx = 0; idx < sp->tcount; idx++) {
-			if (sp->req[idx]->saidx.mode == IPSEC_MODE_TUNNEL)
-				break;
-		}
-		if (idx == sp->tcount) {
-			IPSECSTAT_INC(ips_out_inval);
-			key_freesp(&sp);
-			m_freem(m);
-			return (EACCES);
-		}
-	} else {
+	/*
+	 * Usually we have to have tunnel mode IPsec security policy
+	 * when we are forwarding a packet. Otherwise we could not handle
+	 * encrypted replies, because they are not destined for us. But
+	 * some users are doing source address translation for forwarded
+	 * packets, and thus, even if they are forwarded, the replies will
+	 * return back to us.
+	 */
+	if (!forwarding) {
 		/*
 		 * Do delayed checksums now because we send before
 		 * this is done in the normal processing path.
@@ -616,7 +609,7 @@ static int
 ipsec6_common_output(struct mbuf *m, struct inpcb *inp, int forwarding)
 {
 	struct secpolicy *sp;
-	int error, idx;
+	int error;
 
 	/* Lookup for the corresponding outbound security policy */
 	sp = ipsec6_checkpolicy(m, inp, &error);
@@ -629,29 +622,7 @@ ipsec6_common_output(struct mbuf *m, str
 		return (0); /* No IPsec required. */
 	}
 
-	if (forwarding) {
-		/*
-		 * Check that SP has tunnel mode IPsec transform.
-		 * We can't use transport mode when forwarding.
-		 *
-		 * RFC2473 says:
-		 * "A tunnel IPv6 packet resulting from the encapsulation of
-		 * an original packet is considered an IPv6 packet originating
-		 * from the tunnel entry-point node."
-		 * So, we don't need MTU checking, after IPsec processing
-		 * we will just fragment it if needed.
-		 */
-		for (idx = 0; idx < sp->tcount; idx++) {
-			if (sp->req[idx]->saidx.mode == IPSEC_MODE_TUNNEL)
-				break;
-		}
-		if (idx == sp->tcount) {
-			IPSEC6STAT_INC(ips_out_inval);
-			key_freesp(&sp);
-			m_freem(m);
-			return (EACCES);
-		}
-	} else {
+	if (!forwarding) {
 		/*
 		 * Do delayed checksums now because we send before
 		 * this is done in the normal processing path.

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201701181021.v0IAL6sZ066489>