Everywhere that makes a TLS connection from what I can see.
I just set the go version to 1.22 in go.mod. I didnât test any other functionality, so I wouldnât rely on it working as expected.
The real fix here is getting people to configure their networks correctly, but thatâs obviously not a realistic goal. One thing that would probably vastly reduce the likelihood of these things is if Canonicalâs servers didnât advertise that they accept jumbo frames in the TCP handshake.
My understanding is that, essentially, if ingress and egress for public APIâs is done over interfaces with a 1500 MTU, this should be safe even if the end user has a botched configuration. This is because then the TCP handshake would ensure clients donât attempt to send jumbo frames and Canonicalâs API servers wouldnât send jumbo frames back to them either, so we donât have to rely on ICMP doing its magic unimpeded, and we donât have to hope PMTUD works as intended.
So, Iâll let @awnns tell you the full story - but setting the MTU to 1500 on the controller machines explicitly stabilizes the situation. It took us about 2,5 weeks to get unblocked on this. Such a nightmare.
Apart from setting the MTU to 1500 on the controllers, what would be needed to get a fix on the client side? What would be needed to get the TLS Client Hello packet to be less than 1500 bytes? Is there something to be done on the juju? Can I open a bug? Against which project?
I tried disabling PMTUD on the controller via net.ipv4.ip_no_pmtu_disc=1 but that did not work.
Thanks to @cjohnston for the workaround!
In juju systemd files add the following:
[Service]
Environment=GODEBUG=tlskyber=0,tlsmlkem=0
More info:
check also if you have MTU 1500 set on controller main interface going out on Internet. I had the same problem with juju 3.5.6 where controller had 9000 MTU, and experienced net/http TLS handshake error. As soon as i changed the MTU to 1500, everything went back to normal.