Martin F. Krafft: 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...

