DrayTek UK Users' Community Forum
Help, Advice and Solutions from DrayTek Users
2862n can't access to https://forum.draytek.co.uk - why?
- dottedquad
- Topic Author
- Offline
- Junior Member
Less
More
- Posts: 68
- Thank yous received: 0
07 Jun 2018 17:08 #91989
by dottedquad
Replied by dottedquad on topic Re: 2862n can't access to https://forum.draytek.co.uk - why?
Another update: I have a Huawei USB dongle in the 2862n's port 3 to provide access to the internet when my regular ISP fails. Just for kicks, I unplugged the WAN2 cable from the 2862n and checked to see if I could then access https://forum.draytek.co.uk after failover to Three's network...and I can!!
I think my brain just exploded!
Martin
I think my brain just exploded!
Martin
Please Log in or Create an account to join the conversation.
- x64
- Offline
- Junior Member
Less
More
- Posts: 95
- Thank yous received: 0
07 Jun 2018 17:15 #91990
by x64
Replied by x64 on topic Re: 2862n can't access to https://forum.draytek.co.uk - why?
Back to two earlier suggestions. Even though you’re not using 5GHz on client side, ensure the radio is turned off.
Secondly I think there was a suggestion about MTU. That has merit. You need to make sure that the MTU on WAN2 matches thr MTU on your wireless uplink.
I can’t clarify in this post but if you need guidance, maybe I can post more tonight.
Secondly I think there was a suggestion about MTU. That has merit. You need to make sure that the MTU on WAN2 matches thr MTU on your wireless uplink.
I can’t clarify in this post but if you need guidance, maybe I can post more tonight.
Please Log in or Create an account to join the conversation.
- dottedquad
- Topic Author
- Offline
- Junior Member
Less
More
- Posts: 68
- Thank yous received: 0
07 Jun 2018 17:47 #91991
by dottedquad
Changing the MTU (from 1492 to 1442 - which the 2820n was set to) solved things! I can now connect tohttps://forum.draytek.co.uk and mail.yahoo.com without any significant delay. Have asked my ISP what MTU to use on the wireless uplink.
So, many thanks x64. The suggestion about MTU did indeed have merit!
I for one would like to understand why this change fixed things, if you'd care to post further?
I wonder if Draytek Uk Support will come up with the same idea?
Martin
Replied by dottedquad on topic Re: 2862n can't access to https://forum.draytek.co.uk - why?
x64 wrote:
Secondly I think there was a suggestion about MTU. That has merit. You need to make sure that the MTU on WAN2 matches thr MTU on your wireless uplink.
I can’t clarify in this post but if you need guidance, maybe I can post more tonight.
Changing the MTU (from 1492 to 1442 - which the 2820n was set to) solved things! I can now connect to
So, many thanks x64. The suggestion about MTU did indeed have merit!
I for one would like to understand why this change fixed things, if you'd care to post further?
I wonder if Draytek Uk Support will come up with the same idea?
Martin
Please Log in or Create an account to join the conversation.
- x64
- Offline
- Junior Member
Less
More
- Posts: 95
- Thank yous received: 0
07 Jun 2018 20:37 #91992
by x64
Replied by x64 on topic Re: 2862n can't access to https://forum.draytek.co.uk - why?
I was posting from my mobile earlier, so writing a lot was difficult.
OK.. MTU is effectively the maximum packet size that can pass down a link. If you need to send a larger packet, it needs to be split up ("Fragmented"). If a packet cannot be forwarded onwards as the link that way is too narrow (MTU-wise), the router receiving the packet will attempt to fragment it and send it on in smaller fragments. However this needs both ends of that onward link to know what the MTU of the link actually is (or else one end might be sending too large packets for the link). For best optimisation both ends of the link should be set to the actual maximum packet size for the media that joins them.
The problem comes when one end of the link is a firewall. The firewall will want to remain stealthy and immune from manipulation from outside, particuarly from DDoS attacks. As such if it is set to too large an MTU, it may ignore clues and control messages that warn it of the problem (as they may be fake). There are attacks for instance that send control messages that try to make a firewall reduce its MTU in order to cripple it.
So the trick is to accurately tune links, particularly those immediately outside a firewall. Both ends must be the same MTU, and it's best if that matches the intermediate media's MTU.
So.... How do we do this?......
Well if we KNOW the MTU of the link and that the far end router is set to that, we can just set that on the WAN interface.... Job done.
If we don't (have accurate knowledge), we can test for it...
If possible, connect a PC to the wireless link (instead of the firewall, using the IP address/gateway that would normally be on the WAN interface of the router). Otherwise use the router with a WAN side MTU of 1500.
Perform various pings with the -f and -l (that s lower case "L" flags as follows
The -f is an option that disallows fragmentation.
The 1464 is a data size within the packet we are sending add 28 to get the full packet size, so we are testing a 1492 byte packet.
If its passes, increase the data size. If it fails reduce it. You can do a 'cooks tour' to home in on the best data size (Big change, then repeatedly halve the difference to home in on the best value - the largest that succeeds). Add 28 to the data size you homed in on and set that sum as the WAN MTU... Job done.
For avoidance of doubt - we are only adjusting the WAN side MTU. Leave the MTUs on internal devices as 1500, and you can probably assume that the WAN MTU will not be greater than 1500.
Technically we are testing the smallest MTU all of the way out to google DNS, but in practice, only the link or couple of links closest to you will be constricted.
OK.. MTU is effectively the maximum packet size that can pass down a link. If you need to send a larger packet, it needs to be split up ("Fragmented"). If a packet cannot be forwarded onwards as the link that way is too narrow (MTU-wise), the router receiving the packet will attempt to fragment it and send it on in smaller fragments. However this needs both ends of that onward link to know what the MTU of the link actually is (or else one end might be sending too large packets for the link). For best optimisation both ends of the link should be set to the actual maximum packet size for the media that joins them.
The problem comes when one end of the link is a firewall. The firewall will want to remain stealthy and immune from manipulation from outside, particuarly from DDoS attacks. As such if it is set to too large an MTU, it may ignore clues and control messages that warn it of the problem (as they may be fake). There are attacks for instance that send control messages that try to make a firewall reduce its MTU in order to cripple it.
So the trick is to accurately tune links, particularly those immediately outside a firewall. Both ends must be the same MTU, and it's best if that matches the intermediate media's MTU.
So.... How do we do this?......
Well if we KNOW the MTU of the link and that the far end router is set to that, we can just set that on the WAN interface.... Job done.
If we don't (have accurate knowledge), we can test for it...
If possible, connect a PC to the wireless link (instead of the firewall, using the IP address/gateway that would normally be on the WAN interface of the router). Otherwise use the router with a WAN side MTU of 1500.
Perform various pings with the -f and -l (that s lower case "L" flags as follows
Code:
ping -f -l 1464 8.8.8.8
The -f is an option that disallows fragmentation.
The 1464 is a data size within the packet we are sending add 28 to get the full packet size, so we are testing a 1492 byte packet.
If its passes, increase the data size. If it fails reduce it. You can do a 'cooks tour' to home in on the best data size (Big change, then repeatedly halve the difference to home in on the best value - the largest that succeeds). Add 28 to the data size you homed in on and set that sum as the WAN MTU... Job done.
For avoidance of doubt - we are only adjusting the WAN side MTU. Leave the MTUs on internal devices as 1500, and you can probably assume that the WAN MTU will not be greater than 1500.
Technically we are testing the smallest MTU all of the way out to google DNS, but in practice, only the link or couple of links closest to you will be constricted.
Please Log in or Create an account to join the conversation.
- dottedquad
- Topic Author
- Offline
- Junior Member
Less
More
- Posts: 68
- Thank yous received: 0
08 Jun 2018 09:55 #92002
by dottedquad
Replied by dottedquad on topic Re: 2862n can't access to https://forum.draytek.co.uk - why?
Thanks x64! Most interesting.
Does that explain why just a few web sites cause Firefox to get stuck at the 'performing a TLS handshake' stage?
Just a note: the 2862n has a 'Path MTU discovery' button in 'WAN>>Internet Access'.
Martin
Does that explain why just a few web sites cause Firefox to get stuck at the 'performing a TLS handshake' stage?
Just a note: the 2862n has a 'Path MTU discovery' button in 'WAN>>Internet Access'.
Martin
Please Log in or Create an account to join the conversation.
- x64
- Offline
- Junior Member
Less
More
- Posts: 95
- Thank yous received: 0
08 Jun 2018 11:29 #92003
by x64
Interesting re the button. I’d not looked for it. I’m so used to doing the discovery the manual way.
Re Firefox. Windows has mtu discovery built in is as well I’m assuming that was papering over a lot of cracks. If too many packets go missing (unacknowledged) it will reduce the MTU that IT sends with, to see if that helps.
I’m hypothesising that the certificate negotiation process is less fault tolerant than fully established data transfers, and that the certificate chains for the erroring sites were larger than your real MTU (causing some of the negotiation packets to become “lost”)
Replied by x64 on topic Re: 2862n can't access to https://forum.draytek.co.uk - why?
Thanks x64! Most interesting.dottedquad wrote:
Does that explain why just a few web sites cause Firefox to get stuck at the 'performing a TLS handshake' stage?
Just a note: the 2862n has a 'Path MTU discovery' button in 'WAN>>Internet Access'.
Martin
Interesting re the button. I’d not looked for it. I’m so used to doing the discovery the manual way.
Re Firefox. Windows has mtu discovery built in is as well I’m assuming that was papering over a lot of cracks. If too many packets go missing (unacknowledged) it will reduce the MTU that IT sends with, to see if that helps.
I’m hypothesising that the certificate negotiation process is less fault tolerant than fully established data transfers, and that the certificate chains for the erroring sites were larger than your real MTU (causing some of the negotiation packets to become “lost”)
Please Log in or Create an account to join the conversation.
Moderators: Chris
Copyright © 2025 DrayTek