curl TLS hangshake hangs with some URI when using fan network and VM

[mrosset]

Required informationcurl

TLS hangshake hangs with some URI when using fan network and VM

• Distribution: Ubuntu 22.04.1 LTS
  • Storage backend in use:
    Local dir

Issue description

I've discovered a strange situation that only occurs when using a fan network and certain https URI's.

This command should not timeout.

curl -L -v https://raw.githubusercontent.com/getumbrel/umbrel/master/scripts/install

• Trying 185.199.111.133:443...
• Connected to raw.githubusercontent.com (185.199.111.133) port 443 (#0)
• ALPN, offering h2
• ALPN, offering http/1.1
• CAfile: /etc/ssl/certs/ca-certificates.crt
• CApath: /etc/ssl/certs
• TLSv1.0 (OUT), TLS header, Certificate Status (22):
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• SSL connection timeout
• Closing connection 0 curl: (28) SSL connection timeout

Steps to reproduce

1. Create a new lxd cluster with defaults and a fan network
2. Launch a new VM lxc launch images:ubuntu/jammy/cloud debug --vm
3. install curl lxc exec debug -- apt install -y curl
4. curl will time out using this URI lxc exec debug -- curl -L -v https://raw.githubusercontent.com/getumbrel/umbrel/master/scripts/install

Attached output for lxc info lxc.txt

[stgraber]

Sounds like an MTU problem, what's the link mtu you're getting inside the containers?

[mrosset]

Hello @stgraber thanks for the response. The MTU is 1500 I increased it to 2800 but it still hangs while handshaking.

Were you able to replicate this at all?

[stgraber]

Other way around, the MTU in your containers should be lower than 1500 when using the fan. You can try 1400 which will be a bit too low but should work fine.

[mrosset]

My mistake. setting the MTU to 1400 does solve the problem now.

What do you recommend for setting MTU for VM's that use fan? I can hack something together but I'd prefer a more top down way to set this if I could.

[tomponline]

If you are using lxds dhcp server then it will broadcast the MTU setting from the network as part of the dhcp responses and the instances should configure themselves that way.

[mrosset]

Thanks for closing the issue. I'll look into why the MTU is not being set properly later. My cluster is kinda adhoc. I'm transitioning from using zerotier to fan which should make this easier to sort out. Appreciate the help and all the work @stgraber