DrayTek UK Users' Community Forum

Help, Advice and Solutions from DrayTek Users

Do Draytek routers have some subtle MTU bugs?

  • peter-h
  • Topic Author
  • Offline
  • Junior Member
  • Junior Member
More
07 Feb 2019 15:19 #1 by peter-h
We are running a 2955, at each of two sites. Different ISP and different ADSL modem (Draytek and Zyxel).

At one site there is a web server.

2-3 years ago we discovered that the website was not reachable via Vodafone 3G. A lot of digging with ping and tracert etc was done then and it appeared there was a MTU negotiation issue between Vodafone and the ISP (Andrews & Arnold). A&A wasn't willing to discuss it and obviously Voda could not be contacted. Packets over ~1350 bytes did not get through.

It was solved by setting the web server, and the router, to a lower MTU, dropping itfrom the max allowed by the router of 1492, to 1300, and that fixed it. We found the 1300 figure at the time by doing a ping to vodafone.com with different size packets and blocking negotiation. Actually the router drops the 1492 (which is says is the max allowed) to 1442, but only at one site, on A&A, not at the other side (Voda broadband)!

And that's how it ran for years.

Recently, we were testing a VPN (Softether) from a PC on the internal LAN, terminated on a virtual server on the outside. It ran extremely slowly on the DOWN speed (from the server - the VPN terminator - to the PC); about 100kbits/sec. On the UP direction it was a few megabits; ok. We found that upping the MTU in the 2955 from 1300 to the max allowed (1492 or 1442) made it run fine; a few megabits each way. What is this telling us? The packets sent DOWN were bigger than 1300 and were not being negotiated to be split up.

Then we found one externally hosted website was not working for file transfers TO it. It was working in every other way. Debugging it found that it wasn't seeing the packets. So the ~1450 byte packets sent to it were too big and were not being negotiated to be split up. So, this was fixed by dropping the MTU back to the original 1300.

So now we are back to the very slow VPN, but it's not important.

One possibility is c--p software in the 2955, although these were "high end by Draytek standards" and it should have come to light if this was duff; these were their top business "200 VPN channels, hardware RSA etc blah" boxes at about 500 quid.

Another is that both the external servers have some funny config on them. I have some vague recollection that blocking pings (which is a DOS attack vector) can have this effect if done incorrectly, because pings are UDP packets and these are also used for MTU negotiation.

Does anyone recognise any of this? Could it really be the 2955? There is no config in it except the MTU in the one place, and all the DOS defences have been disabled since these are known to mess up file transfers.

Please Log in or Create an account to join the conversation.

  • hopkins35
  • User
  • User
More
07 Feb 2019 19:39 #2 by hopkins35
I'm surprised to hear that Andrews & Arnold were unwilling to help, I've been a customer of theirs for 15 years and have found them to be very helpful even when dealing with the most obscure queries. I would escalate it to Adrian Kennard, the big boss if support wont help you

Please Log in or Create an account to join the conversation.

  • peter-h
  • Topic Author
  • Offline
  • Junior Member
  • Junior Member
More
08 Feb 2019 13:55 #3 by peter-h
This stuff is very deep down in the configs.

More to the point, could the 2955, firmware c. 2016, have such a huge bug in it?

Or could there be some config item which causes the UDP packets to get binned? For example we have a firewall rule which drops UDP sent to port 123 to be dropped. That was to block some then-popular attack. But if the 2955 implemented this incorrectly and disregarded the destination port #, that might have such an effect. I have actually disabled that rule temporarily, so it isn't that ...

Please Log in or Create an account to join the conversation.