Bug 179829 - net/route.c MFC 248895 breaks some VPNs [regression]
Summary: net/route.c MFC 248895 breaks some VPNs [regression]
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 9.1-STABLE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Alexander V. Chernikov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-22 05:30 UTC by john
Modified: 2018-05-28 19:48 UTC (History)
1 user (show)

See Also:


Attachments
Patch which fixes the issue. (649 bytes, patch)
2014-08-05 03:07 UTC, john
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description john 2013-06-22 05:30:00 UTC
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.

Fix: 

Replacing net/route.c 248895 with net/route.c 235103 fixes the problem.
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.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2013-06-23 07:21:19 UTC
Responsible Changed
From-To: freebsd-bugs->melifaro

over to committer.
Comment 2 john 2014-08-05 03:07:45 UTC
Created attachment 145375 [details]
Patch which fixes the issue.
Comment 3 john 2014-08-05 03:08:05 UTC
I still encountered the problem after upgrading to FreeBSD 10 r269288.
The attached patch fixed the issue for me.
Comment 4 Alexander V. Chernikov freebsd_committer freebsd_triage 2014-08-05 08:09:22 UTC
Thanks, I'll take a look
Comment 5 john 2014-11-09 17:33:24 UTC
Just curious about your thoughts regarding the supplied patch for FreeBSD 10.
Comment 6 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:48:05 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.