bin/126892: Routing problems when using pppoed and ppp as PPPoE
Joao Paulo Just
just at rg3.net
Wed Aug 27 15:10:01 UTC 2008
>Synopsis: Routing problems when using pppoed and ppp as PPPoE server
>Arrival-Date: Wed Aug 27 15:10:00 UTC 2008
>Originator: Joao Paulo Just
>Release: FreeBSD 7.0-RELEASE-p3 amd64
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
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
If another Windows client tries to make another connection, it works fine also:
route to: 192.168.0.11
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
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.
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.
set log Chat Command Phase LCP IPCP CCP TUN LQM Radius
allow mode direct
set mru 1492
set mtu 1492
set speed sync
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
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
set rad_alive 30
set rad_port_id tunnum
pppoed_flags="-P /var/run/pppoed.pid -a MyISP -l myisp"
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
# Fixes routing table's incorrect entry added by ppp
# by deleting the current entry and adding a correct
# 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
# Get some values
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
route delete $ip
route add $ip 172.16.0.1 -ifp $tun
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.
More information about the freebsd-bugs