Subject: misc/18418: pppd route created with wrong interface
To: None <>
From: None <>
List: netbsd-bugs
Date: 09/25/2002 11:42:58
>Number:         18418
>Category:       misc
>Synopsis:       pppd route created with wrong interface
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Sep 25 10:44:01 PDT 2002
>Originator:     Chris Jones
>Release:        NetBSD 1.6
System: NetBSD ns 1.6 NetBSD 1.6 (NS) #0: Mon Sep 23 13:18:58 MDT 2002 i386
Architecture: i386
Machine: i386

Machine is a router, IPSec gateway, and dialup server.  More detailed
information follows:

Abbreviated routing table:
default        UGS         3   426388      -  we1   link#1             UC         18        0      -  fxp0      00:90:27:87:95:55  UHLc        1   103621      -  lo0     UGS         0      246      -  fxp0   link#2             UC          1        0      -  we1

Interface information:
        address: 00:90:27:87:95:55
        inet netmask 0xffffffc0 broadcast
        address: 00:00:c0:50:b9:0a
        inet netmask 0xfffffff8 broadcast
ppp0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1524
        inet -> netmask 0xffffffc0
ppp1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500
        inet -> netmask 0xffffffc0

IPSec configured as a gateway between and a remote network,
and and the same remote network.  Running racoon.

When a user dials in, the route added by pppd either doesn't get added,
or gets added on the wrong interface.

Scenario 1:  The user's assigned IP ( is in the range for the
local net.  When he dials in, he gets two route entries added.  One
has "link#1" as its next-hop, and the other has this machine's MAC addr as
its next-hop (results of the proxyarp pppd option).  Both entries have
fxp0 (the interface for the local network) listed as their interface,
instead of ppp1.  Traffic from this node to the remote one doesn't go
through, presumably because it's sent over fxp0.

Scenario 2:  The user's assigned IP is in a free range, not listed in this
node's routing tables (  When he dials in, he gets no route
entries added.  Traffic to the remote node doesn't go through, presumably
because it's sent over the default interface (we1).

To make things stranger, another user is using ppp0, and he is reachable.
His route entry (from netstat) looks like this:      UH          0     4491      -  ppp0

See above.