From owner-freebsd-bugs@FreeBSD.ORG Wed Mar 28 05:40:10 2012 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7BF711065670 for ; Wed, 28 Mar 2012 05:40:10 +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 39AE58FC1A for ; Wed, 28 Mar 2012 05:40:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2S5eAI9023001 for ; Wed, 28 Mar 2012 05:40:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2S5eAQO023000; Wed, 28 Mar 2012 05:40:10 GMT (envelope-from gnats) Resent-Date: Wed, 28 Mar 2012 05:40:10 GMT Resent-Message-Id: <201203280540.q2S5eAQO023000@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 M. Zheganin" Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3981D106564A for ; Wed, 28 Mar 2012 05:32:40 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id 22DEA8FC14 for ; Wed, 28 Mar 2012 05:32:40 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id q2S5WdqR026370 for ; Wed, 28 Mar 2012 05:32:39 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id q2S5Wdtx026369; Wed, 28 Mar 2012 05:32:39 GMT (envelope-from nobody) Message-Id: <201203280532.q2S5Wdtx026369@red.freebsd.org> Date: Wed, 28 Mar 2012 05:32:39 GMT From: "Eugene M. Zheganin" To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/166462: gre(4) when using a tunnel source address from carp(4) doesn't honor the MASTER/BACKUP state X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 05:40:10 -0000 >Number: 166462 >Category: kern >Synopsis: gre(4) when using a tunnel source address from carp(4) doesn't honor the MASTER/BACKUP state >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: Wed Mar 28 05:40:09 UTC 2012 >Closed-Date: >Last-Modified: >Originator: Eugene M. Zheganin >Release: 8.2-RELEASE >Organization: RealService LLC >Environment: FreeBSD moscow-omega 8.2-RELEASE FreeBSD 8.2-RELEASE #5: Sat Mar 10 14:15:00 MSK 2012 emz@moscow-omega:/usr/obj/usr/src/sys/MOSCOW amd64 >Description: When using a HA system of two nodes for corporate VPN I encountered a problem: Imagine node A and B share the same public ip address on their carp(4) interface. Imagine A and B have a gre(4) interface, and its tunnel source address is the carp(4) address. Imagine there is an ospf daemon running on those gre(4) interfaces. Then the OSPF neiborship will be constantly reestablished, because A and B will interfere with OSPF sessions of each other. This happens because both nodes will send a HELO packet, and the backup node isn't honoring its BACKUP state properly. >How-To-Repeat: Build a setup mentioned above. Use OSPF or just try to send icmp packets via the tunnel from the BACKUP node. >Fix: Use IPSEC with 'required' policies. This will prevent the backup node from establishing SA, thus preventing the tunnel from working. >Release-Note: >Audit-Trail: >Unformatted: