4 ms·
Hey Peteris, thank you for the reply, hope things are well. One thing we found is that sometimes clients on a VPN have a smaller max packet size, causing SSL c
by encoderer 6y ago
Hey Peteris, thank you for the reply, hope things are well.
One thing we found is that sometimes clients on a VPN have a smaller max packet size, causing SSL connections to fail, but it's not a main thing we're trying to solve. Primarily it's bandwidth and speed.
- toast0 6y ago> sometimes clients on a VPN have a smaller max packet size This sounds like a path MTU problem. There's a couple ways to solve this. -1) Make sure you're not dropping icmp needs frag packets. 0) Ignore it --- it's not really your problem, and it's 2020, people shouldn't screw up MTU like it's 1997 anymore. This is easy, but not very effective. 1) clamp your outgoing MTU to 1480. A lot of big sites do this, and it avoids problems in most of the broken networks, but you're adding overhead. But it's pretty easy to do. Doing it so you send lower MSS back to the client helps with large packets they send you. 2) Clamp effective MTU to whatever the other side told you in the TCP SYN - 20 (or whatever value you like). This isn't easy, but it fixes a lot more networks. 3) Like 2, but targetted to only networks were you detect path issues. This would be a lot of work, but very effective. (I haven't been able to convince people to do this, but I've seen packet traces that show it would work). You could also try to reach out to the most broken networks, and change the world for the better. 4) Your OS almost certainly has path MTU blackhole detection, but it might not be enabled, or it might not be very fast acting. Check if you can enable it with a fast timeout. (To the thread; sorry, this isn't related to the article at all)