From owner-freebsd-bugs@FreeBSD.ORG Mon May 16 07:10:03 2005 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 084B316A4CE for ; Mon, 16 May 2005 07:10:03 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8DC843D39 for ; Mon, 16 May 2005 07:10:02 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j4G7A2ne094194 for ; Mon, 16 May 2005 07:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j4G7A2QB094193; Mon, 16 May 2005 07:10:02 GMT (envelope-from gnats) Resent-Date: Mon, 16 May 2005 07:10:02 GMT Resent-Message-Id: <200505160710.j4G7A2QB094193@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, Ari Suutari Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5C7C16A4EF for ; Mon, 16 May 2005 07:03:01 +0000 (GMT) Received: from espresso2.syncrontech.com (sync-old.syncrontech.com [213.28.98.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id F172C43DA8 for ; Mon, 16 May 2005 07:02:57 +0000 (GMT) (envelope-from asu@guinness.syncrontech.com) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.57])j4G72tGH041231 for ; Mon, 16 May 2005 10:02:56 +0300 (EEST) (envelope-from asu@guinness.syncrontech.com) Received: from guinness.syncrontech.com (localhost [127.0.0.1]) j4G72oph073301 for ; Mon, 16 May 2005 10:02:50 +0300 (EEST) (envelope-from asu@guinness.syncrontech.com) Received: (from asu@localhost)j4G72o2M073300; Mon, 16 May 2005 10:02:50 +0300 (EEST) (envelope-from asu) Message-Id: <200505160702.j4G72o2M073300@guinness.syncrontech.com> Date: Mon, 16 May 2005 10:02:50 +0300 (EEST) From: Ari Suutari To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 Subject: kern/81095: IPsec connection stops working if associated network interface goes down and then up again. X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Ari Suutari List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 07:10:03 -0000 >Number: 81095 >Category: kern >Synopsis: IPsec connection stops working if associated network interface goes down and then up again. >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon May 16 07:10:02 GMT 2005 >Closed-Date: >Last-Modified: >Originator: Ari Suutari >Release: FreeBSD 5.4-RELEASE i386 >Organization: >Environment: FreeBSD poison2.syncrontech.com 5.4-RELEASE FreeBSD 5.4-RELEASE #0: Fri May 13 09:13:34 EEST 2005 root@poison2.syncrontech.com:/usr/src/sys/i386/compile/POISON i386 >Description: IPsec VPN tunnel stops working after associated network interface goes down and then back up again (which can happen with networks using tun device, for example). When the network interface goes down, IPsec stack updates it's cached route to use system default route. However, when the interface comes back again the cached route is not updated to use that interface again. >How-To-Repeat: Create a setup of 3 machines: A: "remote server" B: IPsec VPN server, use 5.4-RELEASE here C: "local workstation" Build a network between A and B which uses tun device (ppp or vtund). Set up racoon and ipsec policies so that traffic from C to A is transmitted via VPN tunnel. Start pinging A from C. Cause somekind of problems between A and B which causes the tun device to go down. Fix the temporary problem. Although the tun device goes now up, the vpn never recovers and ping doesn't work any more. >Fix: Somehow updated or invalidate sa_route field (updated at least in netinet6/ipsec.c now) when routing table changes. As a temporary workaround, I have modified ipsec.c so that it always calls rtalloc to ensure valid route. >Release-Note: >Audit-Trail: >Unformatted: