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
AcquireIP: Dhcp_client(1)
Idle timeout:-1

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 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.


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…


27 thoughts on “DrayTek Vigor 120 as router without NAT hack

  1. Regarding the ICMP response issue, may I suggest that you may be observing the symptom, not the cause.

    Firstly, the ICMP is carried as part of the IP protocol which is encapsulated in PPP. The PPP is end to end between your router and the ISPs BRAS. If the modem were to block specific ICMP messages, it would have to be doing more than mere bridging. It would need to act as some sort of filtering PPP middle-man. I doubt this is the case (it may not even be possible with CHAP negotiation).

    I have done my own experiments and have observed that, with a PPPoE connection, I do not actually get the oversized packets on my end of the PPP connection. I may get related fragments, but I always am missing the first part of the payload. Without this, the router will not (and does not) send ICMP responses as there is nothing to respond to.

    So I suggest that the lack of ICMP “fragmentation-needed” responses is actually down to the fact that the router doesn’t see these oversized packets.

    …and, if you think about it, it shouldn’t. It should be the upstream router that takes care of this. When the router at the other end of the PPP connection sees a packet come in, and sees a PPP connection that’s too small for it, it shoudl generate this ICMP response. That device is somewhere in the ISPs network (perhaps the BRAS). I suspect the root of this issue is some configuration issue at the ISP’s BRAS.

    • Keith,
      Whilst I agree with you inprinciple and your posts on the vodaphone and pfsense forums are very enlightening, you’ll see that Francois is using the v120 as a router. Not in pppoa-pppoe mode.

      • It’s true he’s using it as a router, but his references to this issue were when using it as a PPPoA-PPPoE bridge:

        It seems this fragmentation needed ICMP message type is really important for the case where the modem is used in PPPoE/PPPoA bridge mode.

      • True.
        Yet as you have said, how can it block ICMP when the IP is encapsulated within ppp?
        Need more hard fact.


      • I’m guessing that it blocks ICMP as a router (although in this context it wouldn’t be “blocking” but “not responding with”).

        Unfortunately, testing whether it blocks certain ICMP messages in bridge mode is something that isn’t easy to do in a conventional ISP setup which is another reason I’m suspicious of the conclusion above, as I’m not sure there’s an easy way to actually test it with any confidence unless you have a captive telecoms lab.

    • Thanks for you comment!

      Ok, but… How does the ISP know that your connection can only handle 1492 bytes if the modem doesn’t tell it to the ISP? The modem will never send it 1500 bytes out to begin with, but how does it convey the fact that it is locally doing PPPoE/PPPoA bridging and thus its MTU is 1492 instead of 1500? To the ISP you are just using PPPoA with a little smaller outgoing packets, or do I misunderstand something?

      • The modem never tells the ISP this when it’s in bridge mode.

        The thing which negotiates the PPP session does this. This is your router (or firewall, etc.). The MTU should be negotiated with the far end during PPP setup. For instance, on my firewall I see the following:

        May 4 15:23:08 ishtar ppp: [wan_link0] LCP: rec’d Configure Request #229 (Opened)
        May 4 15:23:08 ishtar ppp: [wan_link0] MRU 1456
        May 4 15:23:08 ishtar ppp: [wan_link0] AUTHPROTO CHAP MD5
        May 4 15:23:08 ishtar ppp: [wan_link0] MAGICNUM dc1784ba
        May 4 15:23:08 ishtar ppp: [wan_link0] LCP: LayerDown
        May 4 15:23:08 ishtar ppp: [wan_link0] LCP: SendConfigReq #11
        May 4 15:23:08 ishtar ppp: [wan_link0] MAGICNUM 37b676cb
        May 4 15:23:08 ishtar ppp: [wan_link0] LCP: SendConfigAck #229
        May 4 15:23:08 ishtar ppp: [wan_link0] MRU 1456
        May 4 15:23:08 ishtar ppp: [wan_link0] AUTHPROTO CHAP MD5
        May 4 15:23:08 ishtar ppp: [wan_link0] MAGICNUM dc1784ba

        This tells the other end of the PPP connection (the ISPs router) that this link has an MRU of 1456. From then on the ISPs router should take the appropriate action, which is either to fragment or to ICMP respond.

      • By the way, in this example the default MRU on the firewall is 1492. I have specifically set it to 1456 because it is actually more efficient.

      • What about in the situation where your ISP doesn’t support pppoe at all? The Vigor is bridging the connection so you can use a pppoe client on your network. But surely in that situation IT is the first point (from the isp’s view) using pppoe and therefore responsible for sending a fragmentation needed message.

      • Of course it can’t send back a message since it doesn’t have a IP address.
        Effectively the MTU of the IP connection seen by the ISP changes size half way. Hmm…

      • Regarding PPPoE support from the ISP, that’s a bit of a myth/misunderstanding.
        The ISPs equipment does not specifically support PPPoE or PPPoA. They support PPP, period.

        In the ADSL case this happens to be (partially) carried across an ATM network and is presented to you as PPPoA, but in the rest of the ISPs network past the DSLAM it’s actually likely to be carried across Ethernet and presented as PPPoE to the ISPs BRAS. At the end of the day it is PPP.

        When your router negotiates the PPP connection with the ISP, the ISP’s BRAS has no idea that you are using PPPoA, PPPoE, PPPoWetstring or anything else. It just sees a PPP session with a negotiated MRU.

        The requested MRU is a good hint that PPPoE is in use, but it could also be a PPPoA connection with a router configured to request an MRU of 1492.

        (To clarify, MRU = Maximum Receive Unit. this effectively becomes the MTU at the other end of the link)

        So, once the PPP session is established you end up with a PPP connection between your router and the ISPs BRAS which has a MTU in each direction. These MTUs are normally the same, but don’t have to be.

        The MTU on my end is used when I send packets to the Internet. In this case I should either fragment or send the ICMP “fragmentation-needed” response to the device on my LAN that orginated the packet as appropriate.

        The MTU at the ISPs should be used when the Internet sends me stuff, and the ISPs equipment is responsible for fragmentation and/or ICMP messages.

        The problem, at least in my case (although this does seem to be a common issue), is that my ISP is ignoring the MTU setting on their end when they should be obeying it and refragmenting the packet.

        I’m not sure I understand the comment about the MTU changing halfway. Whatever you meant by it, it’s wrong. The MTUs (there are 2, one for each direction) are absolute and fixed for each point to point connection in the network. The routers that are at the ends of these connections should know the MTU for sending down any of its connections, and should refragment or send ICMP accordingly.

      • The only way an ISP can claim not to support PPPoE is by saying they don’t support MTUs smaller than 1500 (which seems like the case here), but that would equally apply to a PPPoA connection which negotiates it MRU down to 1492.

      • Ok, to convert this to my situation:

        The Vigor 120 does not seem to support “wan ppp_mru” command through the telnet interface. It is explained in the Telnet Commands manual, but is not there.

        Minor setback: what about if I enable PPPoE/PPPoA mode en use PPPoE on OpenWRT to request a smaller MRU. You can specify “pppd_options” which can contain “mru n” where you can specify the MRU. If both the translation on the Vigor and the BRAS supports setting the MRU through PPP I should be in business…

      • Yes, exactly so.

        The issue then becomes whether your ISP handles large (bigger than the MRU) incoming packets properly. Remember the MRU effectively should end up as the MTU used by the router at the ISPs end. In my experience, negotiating 1492 is not a problem.

        However, the issue then becomes whether the ISP handles the fragmentation properly for incoming packets with a larger size than 1492. In my experience many ISPs (at least in the UK) simply discard these packets.

      • In other words, there can be a fundamental issue with using PPPoE on DSL lines as this reduces the MTU from 1500 to something less (usually 1492). Many ISPs are simply not prepared to deal with the reduced MTU for some reason.
        As it only impacts large sized UDP packets (for the reasons you have given above) this situation is pretty rare, but when it does occur it can be fatal for the application.

        The point it this is not a fault or function of the Vigor modem.

        Vodafone Suresignal, for instance, doesn’t work with many PPPoE connections for this reason. I understand that Slingbox had to rewrite their firmware to use smaller UDP packets for the same reason.

      • I finally managed to test this now. Unfortunately it doesn’t seem to work:

        May 15 15:12:36 OpenWrt daemon.debug pppd[2174]: sent [LCP ConfReq id=0x1 <mru 1492> <magic 0x130fce9b>]
        May 15 15:12:36 OpenWrt daemon.debug pppd[2174]: rcvd [LCP ConfNak id=0x1 <mru 1500>]

        It enforces the 1500 MTU 😦

  2. Hi.
    Great post, lots of good information there.
    Is your modem the V1 or V2 hardware?
    I believe the V2 is marked as such but the V1 has no type marking.

    • I’m not quite sure, maybe this is some indication: Firmware Version:321311_A. The modem itself doesn’t say anything about V2 though.

      Can this be determined based on the serial number? Draytek support asked me to send that to them to determine whether it was a V1 or V2.

      • I only have one example to work with but it seems the V2 shows,
        Model name :Vigor120 V2
        On the system status page of the web gui

      • Also from the telnet interface using:
        > sys version
        Router Model: Vigor120 v2 Version: English
        Profile version: 3.0.0 Status: 1 (0x273d3001)
        Router IP: Netmask:
        Firmware Build Date/Time: Jul 16 2010 17:33:53
        Revision: 23085 v120
        ADSL Firmware Version: 332201_A Annex A

      • > sys version
        Router Model: Vigor120 Version: beta_0302 English
        Profile version: 3.0.0 Status: 1 (0x283d3101)
        Router IP: Netmask:
        Firmware Build Date/Time: Mar 2 2011 10:33:56
        Revision: 26485 v120
        ADSL Firmware Version: 321311_A Annex A


  3. I also sent a question to Draytek support about half-bridge support in Vigor V120. They never replied to me, it looks the tech support it’s really really bad.
    I will never buy another product from Draytek of course, but if someone knows how to use it in half-bridge PPPoA let me know.

  4. Hi, I found your post after getting no responses from Draytek..
    Do you know if it’s possible to change a Vigor 120 Annex B version to Annex A (with firmware changes / hacks) ?

    Thanks, you are my last chance!

    • It doesn’t seem to be officially possible.

      At your own risk:

      – try to flash the Annex A firmware on the B modem
      – just try it by connecting the Annex B modem to POTS and see if it works (frequency for upload seems to be a bit shifted, but it may just work?)

  5. Seriously? You hack a product, use it in a way that the mfr. doesn’t intend and then go all sulky because it doesn’t work how you want and they won’t provide you with support for the unsupported functions and hacked device? Duh !

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s