From owner-freebsd-bugs@FreeBSD.ORG Sat Jun 22 04:30:01 2013 Return-Path: Delivered-To: freebsd-bugs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0D5B4D7B for ; Sat, 22 Jun 2013 04:30:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id EA1DF1B68 for ; Sat, 22 Jun 2013 04:30:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r5M4U0Ei099190 for ; Sat, 22 Jun 2013 04:30:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r5M4U0On099187; Sat, 22 Jun 2013 04:30:00 GMT (envelope-from gnats) Resent-Date: Sat, 22 Jun 2013 04:30:00 GMT Resent-Message-Id: <201306220430.r5M4U0On099187@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, John Wehle Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7115FBB5 for ; Sat, 22 Jun 2013 04:21:40 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121]) by mx1.freebsd.org (Postfix) with ESMTP id 4A8EC1B27 for ; Sat, 22 Jun 2013 04:21:40 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id r5M4Ldlf096966 for ; Sat, 22 Jun 2013 04:21:39 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id r5M4LdAX096957; Sat, 22 Jun 2013 04:21:39 GMT (envelope-from nobody) Message-Id: <201306220421.r5M4LdAX096957@oldred.freebsd.org> Date: Sat, 22 Jun 2013 04:21:39 GMT From: John Wehle To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: kern/179829: net/route.c 248895 breaks some VPNs X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 04:30:01 -0000 >Number: 179829 >Category: kern >Synopsis: net/route.c 248895 breaks some VPNs >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: Sat Jun 22 04:30:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: John Wehle >Release: FreeBSD 9.1-STABLE 252047M >Organization: >Environment: FreeBSD carmen.FEITH.COM 9.1-STABLE FreeBSD 9.1-STABLE #1 r235103:252047M: Fri Jun 21 23:31:53 EDT 2013 root@wagner.FEITH.COM:/usr/obj/amd64.amd64/usr/src/sys/CUSTOM amd64 >Description: Have been using mpd to maintain a VPN for years. The link up script does: /sbin/route add -host "${REMOTE}" "${DEFAULT}" /sbin/route add -net "${REMOTE}/24" -interface "${IFACE}" where REMOTE = 192.251.93.62, DEFAULT = 71.224.208.1, IFACE = ng0. This normally produces a routing table such as: Destination Gateway Flags Refs Use Netif Expire default 71.224.208.1 UGS 0 45 ale0 71.224.208.0/21 link#2 U 0 0 ale0 71.224.209.156 link#2 UHS 0 0 lo0 192.251.93.62 71.224.208.1 UGHS 0 118 ale0 192.251.93.165 link#13 UHS 0 0 lo0 192.251.93.0/24 ng0 US 0 82 ng0 The latest change to net/route.c produces a routing table such as: Destination Gateway Flags Refs Use Netif Expire default 71.224.208.1 UGS 0 557 ale0 71.224.208.0/21 link#2 U 0 0 ale0 71.224.209.156 link#2 UHS 0 0 lo0 192.251.93.62 link#13 UH 0 10 ng0 192.251.93.165 link#13 UHS 0 0 lo0 192.251.93.0/24 ng0 US 0 0 ng0 Specifically note that the remote VPN endpoint (192.251.93.62) is no longer accessed through the correct interface. Instead a loop is created ... packets to 192.251.93.62 are routed through ng0 which generates encapsulated packets going to 192.251.93.62 which are routed through ng0 .... An explict route table entry for a host should have a higher priorty than a route table entry for a net. >How-To-Repeat: Configure a VPN where the remote endpoint is on the same network as the the remote network being accessed over the VPN. Use route to add an explict route for the remote VPN endpoint and a separate route for the remote VPN network. Notice that the VPN endpoint gets routed over the VPN interface thus creating a loop. >Fix: Replacing net/route.c 248895 with net/route.c 235103 fixes the problem. >Release-Note: >Audit-Trail: >Unformatted: