home of the madduck/ blog/
A first glance at the Draytek Vigor 2900VG

I got myself the Draytek Vigor 2900VG, as announced, to handle my home office connection needs. I've been playing with the device all morning and am somewhat undecided as to whether I should keep it, or replace it with a tiny computer without moveable parts that runs Debian, simply for the benefit of greater control.

But first, let me review the device. Don't get me wrong when I say that I am not sure whether I should keep it: the router seems solid and has a lot of functionality, and with few glitches, it mostly seems to work. Go read the specs yourself if you care, in the following I want to give my view on some of the pros and cons of the device after a few hours:

The device is an all-in-one, combining WAN access (DHCP, PPPoE, PPTP) with NAT (with support for a DMZ), DHCP, VPN (PPTP, L2CAP, IPsec), a stateful packet filter, a 802.11g access point with support for WPA2 and 802.1x, VoIP gateway, a 4-port switch with VLAN and rate control, static routing and RIP, QoS, UPNP, dynamic DNS updates (e.g. no-ip.com), syslog or SMTP-based logging, and a printer server for USB printers. Basic HTTP URL and content filtering is provided, though most of it comes through the interface to SurfControl (no subscription included). Content control includes the most popular IM and P2P protocols. For all that functionality, the price is quite reasonable, if you ask me.

Interaction is through a web interface that can be restricted to a couple of clients only, and is password protected (though in the clear). In any case, the device also comes with a telnet console that has a larger feature set than the web interface, but lacks documentation. Several forums exist, however, to fill this hole. The router also sports SNMP!

The packet filter seems limited in what it can do: TCP, UDP, ICMP, IGMP, and only the basics for each (e.g. sockets for TCP). There are 12 filter sets with 7 rules each, and if/then logic can be implemented by branching to other filter sets. However, I can well imagine that the limit can be quickly reached.

For QoS, you can define three classes, and to each assign services based on sockets and diffserv. That's it, but it should be enough for most basic use cases.

VPN can be achieved with L2CAP, PPTP, or IPsec, but only pre-shared secrets are supported. Users can dial-in, up to 16 "Road Warrior" profiles can be created, and 32 LAN-to-LAN tunnels can coexist.

A nice feature are the 16 schedules you can define and use throughout. For instance, certain filters can be restricted to only apply during working hours, some users may only be allowed to use the VPN to dial in during specific times, WLAN can be turned off at dusk, and VoIP devices can be routed based on the time of the day. NTP ensures this all happens accurately.

I am really missing a RADIUS server on the device. As it stands, I am left to run a separate RADIUS server on the LAN, or resort to WPA2-PSK, which is a little less desirable but quite okay for my case.

The device can separate LAN and WLAN clients and block any traffic between the two. I have not found a way to put LAN and WLAN into their own subnets and allow traffic inbetween.

The DHCP server seems okay, it does not remember leases and will simply time out leases and use them for new requests. It is not possible to lock a MAC address to a specific IP through the web interface, one has to resort to the telnet prompt, and the limit is on 10 static leases.

The device has no support for DNS updates for DHCP clients, nor is there any integration with a DNS server whatsoever. This means that for 10+ clients, you'll need ZeroConf stuff or you cannot use DNS between clients on the LAN/WLAN.

All of the above are minor annoyances. I have also already found a bug (which has been known for more than a year now but remains unfixed in the latest firmware from December 2005): the device has a DNS relay without a cache (ugh!). If you request an A record, it all works. If you request an AAAA or MX record, it forgets to translate the source IP of the answer and feeds the upstream forwarder's packet straight throught. Thus, it is not possible to resolve AAAA or MX records without hard-coding the DNS servers to use in the DHCP server configuration to bypass the DNS relay.

That's all for now. I have not gotten around to play with VoIP stuff yet, but one of these days...