bin/126892: Routing problems when using pppoed and ppp as PPPoE server

Wed Aug 27 15:10:01 UTC 2008

>Number:         126892
>Category:       bin
>Synopsis:       Routing problems when using pppoed and ppp as PPPoE server
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Aug 27 15:10:00 UTC 2008
>Closed-Date:
>Last-Modified:
>Originator:     Joao Paulo Just
>Release:        FreeBSD 7.0-RELEASE-p3 amd64
>Organization:
RG3.Net
>Environment:
FreeBSD zeus.rg3network.com.br 7.0-RELEASE-p3 FreeBSD 7.0-RELEASE-p3 #7: Sat Aug 16 09:09:11 BRT 2008 root at zeus.rg3network.com.br:/usr/obj/usr/src/sys/ZEUS amd64
>Description:
When a FreeBSD 7.0 server is set up to work as a PPPoE server using pppoed and ppp, we have routing problems when Linux machines tries to establish a PPPoE connection.

Everything works fine when Windows clients connect to the server, but if a Linux machine (be it a computer or any device, as an small router), we get routing problems. The connection is established fine, but ppp adds an incorrect entry in the routing table.

Let's suppose a Windows client established a connection to our server. ppp creates a virtual interface "tun0" to handle this connection. The Windows client gets the IP address 192.168.0.10 and ppp uses 192.168.0.1 as server's address. A new entry in the routing table is created as follow (the output below was get using the command "route get 192.168.0.10"):

   route to: 192.168.0.10
destination: 192.168.0.10
  interface: tun0
..

If another Windows client tries to make another connection, it works fine also:

   route to: 192.168.0.11
destination: 192.168.0.11
  interface: tun1
..

But if a Linux machine tries to make a connection, it is established, but the entry in the routing table is incorrect. Let's suppose our Linux box gets 192.168.0.12 as IP address and ppp creates "tun2" as a virtual interface. The entry ppp adds in the routing table would be:

   route to: 192.168.0.12
destination: 192.168.0.12
  interface: tun0
..

Pay attention to "interface" field. ppp creates "tun2" as interface for Linux client's tunnel, but it adds a entry using "tun0". The Linux client can't even ping the server.

If the Linux client is the first one to connect, it works OK, just because as first one to establish a connection, its vitual interface would be "tun0" and the "incorrect" entry in the routing table would work.

The same setup was working fine on a 6.3-RELEASE. The problem started happening after installing a new server with FreeBSD 7.0-p3.

A curious fact is that it only happens with Linux machines. I really don't know why. I even tried to change Linux configuration, but with no success. FreeBSD as a client was not tested.

>How-To-Repeat:
Install FreeBSD 7.0 and set up a PPPoE server as follows. Then, use a Windows machine to establish a connection to this server and, after Windows' connection was made, establish another connection using a Linux machine.

/etc/ppp/ppp.conf:
default:
 set log Chat Command Phase LCP IPCP CCP TUN LQM Radius

myisp:
  allow mode direct 
  enable proxy
  disable ipv6cp
  set mru 1492
  set mtu 1492
  set speed sync
  enable vjcomp

  enable MSCHAPv2
  enable mppe
  enable chap
  deny pap
  disable deflate pred1
  deny deflate pred1

  enable lqr echo

  set timeout 0

  # IP configuration
  set ifaddr 192.168.0.1 192.168.0.2-192.168.0.254 255.255.255.255
  accept dns
  set dns xx.xx.xx.xx yy.yy.yy.yy # Use two DNS servers here

  # Although I haven't tested without RADIUS, I can assume it is not the problem
  # as the error is in the routing table entry
  set radius /etc/radius.conf
  enable NAS-IP-Address
  set rad_alive 30
  set rad_port_id tunnum

/etc/rc.conf:
  pppoed_enable="YES"
  pppoed_interface="em0"
  pppoed_flags="-P /var/run/pppoed.pid -a MyISP -l myisp"

>Fix:
Workaround #1:

I could "fix" the problem creating a shell script to correct the routing table entry. I had also to add the following line to /etc/ppp/ppp.conf to call my new script:

!bg /etc/ppp/fixit.sh INTERFACE

The script:

/etc/ppp/fixit.sh:
  #!/bin/sh
  #
  # Fixes routing table's incorrect entry added by ppp
  # by deleting the current entry and adding a correct
  # one.
  #
  # You must add the following line in /etc/ppp/ppp.conf:
  #
  #   !bg /path/to/fixit.sh INTERFACE
  #
  # Author: Joao Paulo Just <just at rg3.net>
  # Thanks to: Giancarlo Rubio

  # We need to wait until ppp creates the tun interface
  sleep 10

  # Get some values
  tun=${1}
  ip=`/sbin/ifconfig $tun | grep inet | cut -f 4 -d " " -`

  # Log (optional)
  echo "$tun: $ip" >> /etc/ppp/fixit.log

  # Fixes the routing table. The command "route change"
  # didn't work here, because something, maybe ppp, changes
  # the entry again, using the incorrect interface, so,
  # we must add a static entry. But this creates another
  # problem: when the connection is closed, the entry stills
  # there.
  route delete $ip
  route add $ip 172.16.0.1 -ifp $tun

Workaround #2:

Actually, this was the one I choosed. Stop using pppoed and ppp and migrate to mpd. mpd also is working faster here, I mean, the connections are being established quicker. The routing problem doesn't exist anymore and we are happy again.

>Release-Note:
>Audit-Trail:
>Unformatted: