From owner-freebsd-net@freebsd.org Thu Aug 9 05:28:40 2018 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 589351055ACD for ; Thu, 9 Aug 2018 05:28:40 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id D3D3580F54 for ; Thu, 9 Aug 2018 05:28:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 984F71055ACB; Thu, 9 Aug 2018 05:28:39 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86E8B1055ACA for ; Thu, 9 Aug 2018 05:28:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 287C280F51 for ; Thu, 9 Aug 2018 05:28:39 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 6F64014C6B for ; Thu, 9 Aug 2018 05:28:38 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w795ScDb084493 for ; Thu, 9 Aug 2018 05:28:38 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w795Scub084492 for net@FreeBSD.org; Thu, 9 Aug 2018 05:28:38 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 228108] if_ipsec drops all the icmp v4&v6 error messages Date: Thu, 09 Aug 2018 05:28:37 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.1-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ae@FreeBSD.org X-Bugzilla-Flags: mfc-stable11+ X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2018 05:28:40 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D228108 --- Comment #10 from Andrey V. Elsukov --- (In reply to dpd from comment #9) > This change breaks ICMP ECHO (pings) to the receiving end of peer to peer > /30 of the IPsec tunnel between FreeBSD and Juniper JunOS on their SRX > products.=20 >=20 > To JunOS 12.x, this seems to block both ICMP and BGP packets to the other > end of the tunnel (being compared to 11.1-STABLE r331329), which works in > this setup. >=20 > To JunOS 17.x and an SRX, OSPF seems to work, but ICMP ECHO does not. (I > don't yet have BGP in this setup). >=20 > However, between 11.1-STABLE r331329 and 11.2-STABLE r335594, IPsec tunne= ls > get established, pings work, and BGP does establish. >=20 > In the case of 11.2 -> JunOS 17, the tunnels and OSPF did come up, and IC= MP > does work routed across the tunnel, just not to the tunnel's termination > point.=20 >=20 > I can't seem to explain it, and seemly a little strange mix of OS and > hardware, but reverting this one line seemed to fix all the issues I had. I have no idea how this commit can affect something. It should only affect inbound ICMP errors handling. Are you sure that described problems is not something related to misconfiguration across several booting? --=20 You are receiving this mail because: You are on the CC list for the bug.=