dhclient-scripts fails on point-to-point network configurations

[Andreas Jellinghaus]

it is perfectly legal to have a point to point network configuration.
in that case the netmask is /32 and the router cannot be reached
using netmask allone. therefore any route is added after setting
a route for the router to that interface.

windows does that already for quite some time :)

here is the patch for the script:
--- /etc/dhcp3/dhclient-script.orig 2006-03-02 10:17:01.632936504 +0000
+++ /etc/dhcp3/dhclient-script 2006-03-02 10:17:26.043225576 +0000
@@ -195,6 +195,7 @@
                 $new_broadcast_arg $mtu_arg

             for router in $new_routers; do
+ route add $router dev $interface
                 route add default dev $interface gw $router $metric_arg
             done
         fi
@@ -254,6 +255,7 @@
            fi

             for router in $new_routers; do
+ route add $router dev $interface
                 route add default dev $interface gw $router $metric_arg
             done

[Matt Zimmerman (mdz)]

This patch would add superfluous routes in more typical configuration; can that be avoided?

[Martin Pitt (pitti)]

Can you please explain this with a little more detail? You mean you have a DHCP configuration like

subnet 172.16.0.2 netmask 255.255.255.255 {
  range 172.16.0.2 172.16.0.2;
  option routers 172.16.0.1;
}

? That does not seem to make much sense to me (since the idea of a default gateway is that it is in the local subnet). OTOH, if using e. g. 255.255.255.0 as netmask, then the routes are already set up correctly by default. Can you please be a bit more specific what you want to achieve?

[Andreas Jellinghaus (tolonuga)]

Am Donnerstag, 4. Mai 2006 20:51 schrieb Martin Pitt:
> Can you please explain this with a little more detail? You mean you have a
> DHCP configuration like
>
> subnet 172.16.0.2 netmask 255.255.255.255 {
> range 172.16.0.2 172.16.0.2;
> option routers 172.16.0.1;
> }
>
> ? That does not seem to make much sense to me (since the idea of a default
> gateway is that it is in the local subnet). OTOH, if using e. g.
> 255.255.255.0 as netmask, then the routes are already set up correctly by
> default. Can you please be a bit more specific what you want to achieve?

well, the range can be bigger. but essentialy all machines get a dhcp address
with netmask 255.255.255.255 and a gateway address, so all communication
is to that gateway, which is a firewall and filters unwanted traffic. also the
switch is reconfigured so each machine is in it is own private vlan, and can
only talk to the gateway / firewall.

this configuration is usd in high security environment, where you want to
police all machine to machine traffic, but it is also used in much simpler
scenario: server hosting. here you don't want to one customer to attack
any other customer with arp spoofing or anything like that. so each
customer is limited to a network with only him and the gateway. but you
can't use a /30 network with 4 addresses per machine, that would be a
huge waste of ip space. so what providers do point to point configuration
with one official address for the server connected to the gateway which
is also the direction for the default route.

dhcp works fine in this setup. all you need to do is drop the assumption,
that the gateway is reachable via the implicint ip/netmask routing entry.
instead add a host route to the interface where you got the gateway
entry, and you will be fine.

for example, replace in dhclient-script:
            for router in $new_routers; do
                route add default dev $interface gw $router $metric_arg
            done
with
            for router in $new_routers; do
                route add -host dev $interface gw $router
                route add default dev $interface gw $router $metric_arg
            done

and you will be fine. (note: no idea if the metric_arg is better used on the
host route for the gw or the default route, but I gess the default is the
better place. also note that the default route coulde be without "dev
$interface", as you prefer)

microsoft is doing this by default as far as I know and it works fine in such
setups.

Regards, Andreas

[Otavio Salvador (otavio)]

Please do a look at #69183 since the proposed solution looks to add this route only when it's really needs

[Andreas Jellinghaus (tolonuga)]

Am Samstag, 31. März 2007 15:49 schrieb Otavio Salvador:
> Please do a look at #69183 since the proposed solution looks to add this
> route only when it's really needs

needs to be added to two places, not only one.

and I think it it good to add it always, I think in some vpn
scenarios with the default route via vpn you can use it too,
if I remember correctly. but this is not a strong preference.

Regards, Andreas

[Martin Pitt (pitti)]

patch in bug 69183 makes sense and does not affect default behaviour. Thanks!

[Martin Pitt (pitti)]

Andreas, 'two places'? The TIMEOUT section already has similar code, so it's not necessary there. Where else, apart from the BOUND|RENEW|REBIND|REBOOT case?

[Martin Pitt (pitti)]

 dhcp3 (3.0.4-12ubuntu4) feisty; urgency=low
 .
   * debian/dhclient-script.linux: Set a direct route to the gateway if subnet
     mask is 255.255.255.255, so that it gets actually reachable. This mask
     happens on PPP connections and other scenarios where all traffic should go
     through one host. (LP: #33382)
   * debian/dhcp3-server.init.d: Fix test_config() to actually display the
     error in the config file. Thanks to Diego Torres Milano! (LP: #94804)

[Andreas Jellinghaus (tolonuga)]

Am Montag, 2. April 2007 09:44 schrieb Martin Pitt:
> Andreas, 'two places'? The TIMEOUT section already has similar code, so
> it's not necessary there. Where else, apart from the
> BOUND|RENEW|REBIND|REBOOT case?

sorry, that code looks good.

Regards, Andreas

[Andre Klapper (a9016009)]

Martin: Has this been upstreamed to Debian? If so, which upstream dhcp3 version release does contain this fix?

[Martin Pitt (pitti)]

Andre, I'm currently merging with 3.1.1 from Debian. In the process of this, I'll pick apart our current delta and send it to Debian/Upstream.

[Martin Pitt (pitti)]

Ah, it's already in Debian's 3.1.1-1.