DrayTek Vigor 120 as router without NAT hack

I got the DrayTek Vigor 120 ADSL2+ (Annex A) modem for use with SURFsnelADSL, offered by InterNLnet and SURFnet. The advantage of this Internet subscription is the ability to use multiple public IPs, as they offer you a public /29 address range (or more when requested) for use on your local network. This means, no more NAT! 🙂

Unfortunately, the Vigor 120 does not (officially) support this. Luckily I found a hack to solve this.

Configuring ADSL

First things first. To configure the ADSL connection I used the telnet interface of the Vigor 120, but it is also possible to use the web configuration interface. I assume you start out from a “factory default” configuration.


> adsl ppp 0 35 0 0 0 4 0 -1 fkooman@dsl.inter.nl.net PaSsWoRd
pvc no.=0
vci=35
vpi=0
encap=VC_MUX(0)
proto=PPPoA(0)
modu=MULTI(4)
AcquireIP: Dhcp_client(1)
Idle timeout:-1
Username=fkooman@dsl.inter.nl.net
Password=PaSsWoRd

This is enough the get everything working. A reboot of the modem may be required though. The default configuration will use NAT and any computer connected to the modem can use DHCP to obtain a private (RFC 1918) address in the 192.168.1.0/24 network. The Vigor itself will obtain the first available IP address from your /29 range on the PPPoA interface, which is a bit strange I would say in a routed network… The external interface should typically not have an IP address in the same range as the IP address on the LAN…

Hacking the Vigor

So far so good. Now to use the public IP addresses one needs to hack around in the web interface. There is no way to use the telnet interface to accomplish the use of the public IP addresses unfortunately. This seems to be left out on purpose and not restricted for a good (technical) reason.

Now if you go to LAN >> General Setup in the web interface you will see the following:

Before Firebug...


In the more expensive Vigor routers it is possible to also configure (LAN) IP addresses for routing, however here these configuration options are not visible, even though they are there! You can show these options by using Firebug or Google Chrome and “inspect” elements on the page. If you look around the HTML code you’ll find some page elements there are hidden using inline CSS. By deselecting the “hidden” property in Firebug for instance you can make them visible and actually use them, like this:

After Firebug...

As you see it becomes possible to add an IP range for routing. What I did was use the first IP address of the /29 network as well, so identical to the IP address on the PPPoA interface. Submitting the form will actually make it work. It still won’t show the configured options on page refresh, but they DO work.

Other Options

I also would like to be able to PING the modem (from the Internet), the telnet configuration option is a bit confusion (i.e.: it does the opposite of what you expect). The following will enable the PING functionality:


> mngt echoicmp disable
%% Echo ICMP packet disabled.

In the web interface, this options is a bit better explained. Also, I wanted to disable the DHCP server functionality in the modem, as the clients will configure the IP address they use statically:


> srv dhcp off

This function need rebooting router, please type "sys reboot" command to reboot router.

Using DHCP on the LAN with public IP address may work though, as the button “2nd Subnet DHCP server” is available above. I didn’t test this though.

Issues

Not all is fine though. There is an issue with this modem in the configuration as shown. The modem itself blocks all outgoing ICMP messages (except echo reply, see above). It does not do that for the machines on the LAN, so their ICMP responses are passed along. It seems impossible to configure this. Other types of ICMP messages that would be (very) helpful are time exceeded in-transit for traceroute and fragmentation needed for Path MTU Discovery.

It seems this fragmentation needed ICMP message type is really important for the case where the modem is used in PPPoE/PPPoA bridge mode. This was the mode of operation I was using first with some other router behind the Vigor 120. From the UK website:

The DrayTek Vigor 120 is an ADSL modem with an Ethernet connection; it is not a router but a true ADSL Ethernet Modem. By providing a PPPoE to PPPoA bridge, the connected device (firewall, router or PC) can log into the Internet (your ISP) directly and have full control over the ADSL connection – that makes the Vigor 120 a unique product. You can connect any device to the Vigor 120 which has a PPPoE client facility, which includes PCs, most Ethernet-WAN routers and the Apple Airport™ but the actual connection to your ISP is still PPPoA (unlike other modems which only provide PPPoE native bridging), which is the unique feature of this product and makes it compatible with all UK ISPs, where PPPoA is used as standard.

Now, using this bridging functionality means that the MTU of the connection is not 1500 like it is in my current setup, but 1492. 8 bytes are used for the PPPoE connection. With blocking the fragmentation-needed ICMP response message, Path MTU Discovery breaks and remote hosts won’t be able to find out the MTU to your modem is actually only 1492 and not 1500. This results in a “black hole connection” (See Path MTU Discovery link above). For TCP this can be fixed by using MSS Clamping by specifying the maximum size as 1492 bytes. This will work for TCP connections, but not for UDP traffic! So with the wider deployment of DNSSEC this will certainly mean trouble! DNSSEC uses UDP packets with bigger than usual sizes and will run into this fragmentation issue. In case the fragmentation-needed ICMP message can’t be delivered back to the sender the DNSSEC response will never arrive. A great test to confirm this problem is running the ICSI Netalyzr.

It would be helpful if DrayTek could confirm (and fix if needed) these issues before DNSSEC is widely deployed as I have only limited ability to test this… For this reason I was unable to use the PPPoE/PPPoA bridging functionality, one of the reasons for buying this otherwise awesome device!

Update (20110129): DrayTek support responded to (some) of the issues above. They will fix (I assume make visible) the LAN routing option in the Vigor 120 firmware:

I’ve applied the hacked/ 2nd routing subnet be visible and usable issue with ID G31067 for R&D’s fixing.

As for the fragmentation of packets, it seems not quite clear to them what the problem is. They suggest setting wan DF_check on on the modem, but this does not work as far as I can see in PPPoE/PPPoA bridging mode (with MTU of 1492) unfortunately. In the “router” mode it can’t be tested as the MTU is 1500 in that case and the hop before the modem would already discard the packet if the DF bit was set.

The issue with the ICMP was not addressed to make traceroute work properly (in routing mode).

Update (20110427): The end result of contact with DrayTek is now that DrayTek will make it impossible in the future to use the true routing mode (through the web interface hack) with a firmware update. The other issues were not looked into at all or even responded to. Further mails to DrayTek support were ignored.

Update (20110628): It seems with XS4ALL Path MTU Discovery works fine with MTU of 1492 instead of 1500 using the PPPoE/PPPoA bridging mode! So it seems to indeed be an ISP issue…

Advertisements