Getting Stuck with DHCPd
At work we are trying to establish a Virtual Private Network (VPN) connection to another company in Melbourne. Being a die-hard Microsoft shop themselves, we have settled down to use Microsoft’s VPN (PPTP or IPSec) technology to connect our internal LAN and their network together over the Internet. We are on the client side and they provide the server. Initially, they want to give each of us in the office a separate certificate so that we can connect to their network independently via separate VPN channels. This is just stupid – why don’t we just have gateway box connecting to them so all the packets from our LAN destined to their network can route through one single PPP session on the VPN link? We can install a Linux PPTP client or a Linux IPSec implementation on our router box, and everyone will be happy. However, after they have been enlightened, they decided that they don’t want to let our Linux router box to connect to their VPN. Instead, they are going to provide their own box to sit inside our network, ring home using its VPN client through our router box and NAT, and then everyone in the office can then connect to their office by routing the traffic to it. They want to do it o that not only we can have a peek at their network, they too can access our network in this way. I don’t see having our router box connecting to their network would prevent what they are trying to achieve here, but anyway, they have settled on this decision and started building the box for us.
But it does give me a challenge in terms of routing. Actually, not really a challenge on routing but a challenge on configuring routing information on each of the boxes here. So, once this box arrived sometime tomorrow, and it will receive a private IP address inside our LAN (10.0.0.100 for example). For all the requests to their LAN (10.20.30.0 for example) to route through this box, it is simply adding a route command similar to…
C:\< route ADD 10.20.30.0 MASK 255.255.255.0 10.0.0.100
But I am think of whether it is possible to configure our DHCP server to automatically distribute this extra static routing information to its clients, so that no one has to enter them manually, and everything will just happen automatic. I am by means a network engineer, and my knowledge of DHCPd is quite limited. After digging the man pages and Googling the news groups, here’s the closest I can find:
option static-routes ip-address ip-address
[, ip-address ip-address...];
This option specifies a list of static routes that the client should
install in its routing cache. If multiple routes to the same desti-
nation are specified, they are listed in descending order of prior-
ity.
The routes consist of a list of IP address pairs. The first address
is the destination address, and the second address is the router for
the destination.
The default route (0.0.0.0) is an illegal destination for a static
route. To specify the default route, use the routers option.
Also, please note that this option is not intended for classless IP
routing - it does not include a subnet mask. Since classless IP
routing is now the most widely deployed routing standard, this
option is virtually useless, and is not implemented by any of the
popular DHCP clients, for example the Microsoft DHCP client.
It is exactly the kind of option I would like to use – broadcasting static routes to DHCP clients. However, notice the emphasised paragraph – it is only intended for classless IP routing, and it does not work with a subnet. D’oh. That means for every machine I would like to connect to on their end, I need to add an option to the DHCP server configuration. Moreover, Microsoft DHCP client might not work (actually, Windows 2000 in front of me seems to work fine). At the end, the problem is only half solved.
Another option is to put their machine on a separate IP network, so that the main router (which is the default route of all other boxes) can decide where the pocket should go. Then I do not need to modify the DHCP configuration, as the default route is already broadcasted. But then there is hardware problem. Our main router box is on an old IBM Pentium 166 with only 2 PCI slot – and both of them filled with network card already. One is for the LAN, and another one for the ADSL modem… Maybe it is just easier to get another cheap box and a few more network cables…
Okay. Back to work.
Comments
Here’s how I did it with dhcp-3:
# MS routes: adds extras to supplement routers option
option ms-classless-static-routes code 249 = array of integer 8;
# RFC3442 routes: overrides routers option
option rfc3442-classless-static-routes code 121 = array of integer 8;
option routers 172.22.0.1;
option ms-classless-static-routes 24, 172, 22, 99, 172, 22, 0, 1 ;
option rfc3442-classless-static-routes 24, 172, 22, 99, 172, 22, 0, 1,
0, 172, 22, 0, 1 ;
The ms- option has just one route, to 172.22.99.0/24 via 172.22.0.1 (yes, a portion of 172.22.0.0/16 is elsewhere; without the route the client would expect to find 172.22.99.0/24 on the LAN); RFC3442 says that if you use the option, you have to specify the default route too and that clients MUST ignore the routers option if present.
There are dual-port PCI cards, I’ve recently looked at exactly IBM’s one. You should be able to find yours at ebay if doing a separate subnet is still a more desirable approach.
Those options worked for me, too, except that dhcpd could not run on ppp interfaces (which did not necessarily even exist when dhcp3-server starts); I first had to add the “bcrelay eth0″ option to my pptpd.conf so dhcpd sees the DHCPInform messages.
Add a comment
Gravatar is used. Email address is required but will not be displayed. Please keep your comment on topic. No spamming and/or bad language. First time poster will be moderated. Scott reserves the right to delete/edit your comments.

I’ve just (3 hours ago :) began to work on the same problem… here are some links you may find usefull
http://www.faqs.org/rfcs/rfc3442.html
http://marc.theaimsgroup.com/?l=dhcp-server&m=105543458410819&w=2
http://rfc3442svc.sourceforge.net/
and man dhcp-options
email me art (at) academ.org in case you resolv this problem, or any other info