I am a new owner of a Vigor 2850Vn router, and I'm having serious problems with it.

My setup:

Internal network(s)
|
Firewall/Router
+--Linksys AG241 (currently primary DSL router)
+--D-Link DSL524T

The Vigor 2850Vn is replacing a D-link DSL524T modem - and is destined to become the primary DSL router once it's confirmed to work properly. The two DSL lines have static IPs, the primary line currently on the AG241 has a routed subnet (78.32.30.216/29), the secondary line has a single IP (84.45.216.196). This setup has worked well for the last 8+ years.

Replacing the D-Link with the 2850Vn, what I find is that the 2850Vn picks every packet off the ethernet - whether or not the destination MAC address is the 2850Vn's, and IP routes it. This has a very detrimental effect.

Firstly, all my IP connections through the AG241 drop out, because the peers on the Internet start seeing TCP packets for connections that they don't recognise, and send TCP resets back to the 2850Vn, which duely un-NATs them and forwards them back.

Secondly, pinging the linksys results in duplicated packets - my firewall sends the ICMP echo request to the AG241 with the correct IP and ethernet MAC address. The 2850Vn also receives this, routes it, and sends it also to the AG241. The AG241 duely replies with its ICMP echo replies to each ICMP packet, the result is that three ICMP echo replies are received by the firewall. One direct from the AG241 for the directly receives ICMP echo request. A second one from the forwarded ICMP echo request via the 2850Vn, and a third as the AG241's reply was picked up and again routed by the 2850Vn back to the firewall.

Further experimentation with ethernet packet sniffers and alternative configurations shows that the 2850Vn does indeed pick every single packet off its ethernet interface, and IP route it. For example:

PC
|
Hub--Firewall--AG241--Internet--Remote host
`---V2850Vn---Internet

---

'

The PC has an IP of 192.168.1.6/23 with a default route of 192.168.0.1. Firewall is 192.168.0.1/23. The 2850Vn is setup with an LAN IP address of 192.168.254.4/24 and no static routing. PC pings the remote host on the internet running a packet sniffer, what I see is that it receives an ICMP echo request via the AG241 (this comes from 78.32.30.218 - the firewall's public IP address). However, I also get an ICMP echo request from 84.45.216.196 (the 2850Vn's public IP) as well.

Given that the 2850Vn is going to have its own default route directing all traffic out to the ISPs router, what this means is that the 2850Vn will forward to the ISPs router all traffic on the directly connected LAN.

I am more than willing to provide packet logs to support the above. However, I am aware that in the UK, we have distance marketing regulations, which only give a limited time for returns. I would prefer not to return it but the problem be fixed, but realistically, I don't think that is possible.

Thanks.

Here's the packet logs - here's a ping of the AG241 on 192.168.254.1/24, V2850Vn on 192.168.254.4/24, firewall on 192.168.254.2 from 192.168.1.23.
Both the AG241 and V2850Vn have a route setup for 192.168.0.1/23 to 192.168.254.2.

AG241 has an ethernet address of 00:16:b6:c4:c5:f3.
V2850Vn has an ethernet address of 00:1d:aa:a8:db:e0
Firewall has an ethernet address of 00:50:04:27:a6:63

13:24:06.192833 00:50:04:27:a6:63 > 00:16:b6:c4:c5:f3, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.23 > 192.168.254.1: ICMP echo request, id 7482, seq 1, length 64
13:24:06.193208 00:1d:aa:a8:db:e0 > 00:16:b6:c4:c5:f3, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 192.168.1.23 > 192.168.254.1: ICMP echo request, id 7482, seq 1, length 64

Here, we can plainly see that the first packet had a destination MAC address for the AG241. Not broadcast, not destined for the V2850Vn. Yet, we can plainly see in the second packet that the V2850Vn has received and routed the packet, forwarding it to the AG241 - notice specifically how the IP TTL value has been reduced by one.

13:24:06.193760 00:16:b6:c4:c5:f3 > 00:50:04:27:a6:63, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 255, id 25934, offset 0, flags [none], proto ICMP (1), length 84) 192.168.254.1 > 192.168.1.23: ICMP echo reply, id 7482, seq 1, length 64

Here we see the AG241 echo reply back to the originating host.

13:24:06.194056 00:1d:aa:a8:db:e0 > 00:50:04:27:a6:63, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 254, id 25934, offset 0, flags [none], proto ICMP (1), length 84) 192.168.254.1 > 192.168.1.23: ICMP echo reply, id 7482, seq 1, length 64

And again, the V2850Vn has picked up that packet, routed it (again, notice the IP TTL reduced by one and the source MAC).

13:24:06.194486 00:16:b6:c4:c5:f3 > 00:50:04:27:a6:63, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 255, id 25935, offset 0, flags [none], proto ICMP (1), length 84) 192.168.254.1 > 192.168.1.23: ICMP echo reply, id 7482, seq 1, length 64

Here, the AG241 responds to the duplicated ping from packet 2.

13:24:06.194850 00:1d:aa:a8:db:e0 > 00:50:04:27:a6:63, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 254, id 25935, offset 0, flags [none], proto ICMP (1), length 84) 192.168.254.1 > 192.168.1.23: ICMP echo reply, id 7482, seq 1, length 64

And again, the V2850Vn picks up the packet, and again routes it.

Here's an example of pinging a host on the Internet - packet logs from the segment between the firewall and DSL routers, and at the target host on the Internet:

Local end:
13:30:22.283521 00:50:04:27:a6:63 > 00:16:b6:c4:c5:f3, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 78.32.30.218 > 195.92.253.2: ICMP echo request, id 7554, seq 1, length 64
13:30:22.300870 00:1d:aa:a8:db:e0 > 00:50:04:27:a6:63, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 54, id 31924, offset 0, flags [none], proto ICMP (1), length 84) 195.92.253.2 > 78.32.30.218: ICMP echo reply, id 7554, seq 1, length 64
13:30:22.330094 00:16:b6:c4:c5:f3 > 00:50:04:27:a6:63, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 52, id 39402, offset 0, flags [none], proto ICMP (1), length 84) 195.92.253.2 > 78.32.30.218: ICMP echo reply, id 7554, seq 1, length 64
13:30:22.330468 00:1d:aa:a8:db:e0 > 00:50:04:27:a6:63, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 51, id 39402, offset 0, flags [none], proto ICMP (1), length 84) 195.92.253.2 > 78.32.30.218: ICMP echo reply, id 7554, seq 1, length 64

Packet 1 above shows the ICMP echo request sent only to the AG241. Only one ICMP echo request was sent. Yet we get three responses.

Remote end:
13:30:22.287219 IP (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 84.45.216.196 > 195.92.253.2: ICMP echo request, id 7554, seq 1, length 64
13:30:22.287264 IP (tos 0x0, ttl 64, id 31924, offset 0, flags [none], proto ICMP (1), length 84) 195.92.253.2 > 84.45.216.196: ICMP echo reply, id 7554, seq 1, length 64
13:30:22.308702 IP (tos 0x0, ttl 53, id 0, offset 0, flags [DF], proto ICMP (1), length 84) 78.32.30.218 > 195.92.253.2: ICMP echo request, id 7554, seq 1, length 64
13:30:22.308740 IP (tos 0x0, ttl 64, id 39402, offset 0, flags [none], proto ICMP (1), length 84) 195.92.253.2 > 78.32.30.218: ICMP echo reply, id 7554, seq 1, length 64

Yet the remote end received two ICMP echo requests with:
1. the same ID as the one seen on the local end
2. one has the source IP address of the V2850Vn's WAN IP.
3. The other has the IP source address from the firewall.

What has happened here is the V2850Vn has picked the ICMP echo request packet off the local ethernet even though it was never destined for itself, routed it, NAT'd it, sent it out through its DSL interface onto the Internet.

So, Wednesday 27th February, I contacted the UK technical support using their web form. As yet, I've received no response.

Their page says "We do reply to all valid support requests, typically within 24 hours (exc. weekends), although during busy periods, it can take longer. If you have not received any response within 2 days, please email us but please check any anti-spam measures/folders." but they don't give an email address.

I've used the web form again in the hope of getting some kind of response.

Is this really the kind of support that this company provides?

So far, the progress is:
- A request for the wireshark logs (08 March)
- A request for access to the 2850Vn (11 March)
- A question whether I wish to continue "troubleshooting" the issue. (13 March)
In return, at the time of writing, they now have five emails from me.

The router arrived on 28 February, and that is the date of my initial report to Draytek UK via their web form (which they claim was lost). We're now at over two and a half weeks since then, and we're still no further forward in terms of having a router which is fit for purpose.

I'm getting really frustrated with Draytek UK's lack of effective assistance with this. Our ISP has an offer on for FTTC until the end of the month, which I need a working VDSL router for, and as things stand, I don't see Draytek UK sorting this out, so I can't migrate to FTTC. Given that Draytek UK are just a distributor (SEG Communications according to draytek.com) I'm not surprised that they can't effectively progress this issue - it is a bug in the product and only the original manufacturer would be able to resolve it.

That bug is that it runs the LAN in promiscuous mode, and IP routes every packet it sees there.

I will pursue further discussions with draytek.com on this issue to see if it's possible to have some progress; as the solution will require new firmware, I don't see how Draytek UK, with their "troubleshooting," would be able to resolve this.

A very frustrated and disappointed customer.

So, Draytek UK eventually responded to emails discussing this problem. Then they stopped. I've chased them a couple of times since the 19th March, but that is still the last time they responded. So much for support services.

I feel betrayed. I feel that I've wasted money on this product. This leaves me with no alternative but to either sell it on or dispose of it.

I will never again purchase a Draytek product.