Nostr Archives

@LNVPS.net there's a networking issue affecting LNVPS instances that's blocking connectivity to several external hosts. Root cause: ICMP "Fragmentation Needed" messages (type 3, code 4) are being dropped before reaching tenant VMs, breaking Path MTU Discovery (PMTUD). Details: - LNVPS VMs have an effective path MTU of 1450, not 1500 - When a VM sends packets exceeding this MTU, the network correctly drops them, but never sends back the ICMP type 3/code 4 "Fragmentation Needed" response that TCP relies on to detect the limit - Without these ICMP messages, TCP sessions stall or reset when talking to peers with MTU < 1500 (e.g. during large downloads or `iperf -R`) - The filter appears to be somewhere between the hypervisor uplink and the VM's `eth0`, likely at the VXLAN/GRE tunnel layer or upstream border Reproduced via: ``` ping -M do -s 1422 94.156.119.69 → 4/4 received (within MTU) ping -M do -s 1423 94.156.119.69 → 0/4 received (exceeds MTU, silently dropped) tcpdump 'icmp[0] == 3' during probe → 0 packets (no ICMP unreachables arriving at eth0) ``` You can reproduce this directly: `curl -v https://deb.debian.org/debian/extrafiles` from any LNVPS machine will stall. `apt` on Debian is broken for the same reason. Fix (either of): 1. Allow ICMP type 3 code 4 through to tenant VMs 2. Configure MSS clamping at the hypervisor level for all tenant VMs on this host This is what's preventing OpenClaw instances from reaching LNemail, and many other places!

💬 16 replies

Replies (16)

LNemail24d ago

FYI @PayPerQ @Roland

0000 sats

PayPerQ24d ago

Great report, thank you. Will see if we can solve.

0000 sats

LNVPS.net23d ago

Hi, we don't filter any ICMP packets, and we have MSS clamping enabled already. Which VM is having problem?

0000 sats

LNVPS.net14d ago

Hi, none of those IPs belong to us, were able to trace to your host ok. ICMP loss in middlebox is normal, 0% loss to your host.

0000 sats

LNemail24d ago

The website and API are also available trough Tor, maybe with even better uptime: http://lnemailv7hfb2txbk7qihz32p4j376wv7pn2xa3nmfwj6lrdhs…

0000 sats

LNemail22d ago

A few users have reported this from different instances. It should be possible to reproduce from any VPS in the IE region, with the curl command to the large debian file.

0000 sats

LNVPS.net22d ago

I wasnt able to replicate the issue from IE server

0000 sats

LNemail22d ago

I've created a fresh VM with Debian 13 and without running anything else, reproduced the error: ``` debian@VM1159:~$ curl -v https://deb.debian.org/debian/extrafiles * Host deb.debian.org:443 was resolved. * IPv6: 2a04:4e42:4b::644 * IPv4: 151.101.62.132 * Trying [2a04:4e42:4b::644]:443... * ALPN: curl offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS alert, decode error (562): * TLS connect error: error:0A000126:SSL routines::unexpected eof while reading * closing connection #0 curl: (35) TLS connect error: error:0A000126:SSL routines::unexpected eof while reading debian@VM1159:~$ ping -M do -s 1422 94.156.119.69 PING 94.156.119.69 (94.156.119.69) 1422(1450) bytes of data. 1430 bytes from 94.156.119.69: icmp_seq=1 ttl=61 time=18.7 ms 1430 bytes from 94.156.119.69: icmp_seq=2 ttl=61 time=18.6 ms 1430 bytes from 94.156.119.69: icmp_seq=3 ttl=61 time=18.8 ms 1430 bytes from 94.156.119.69: icmp_seq=4 ttl=61 time=18.6 ms 1430 bytes from 94.156.119.69: icmp_seq=5 ttl=61 time=18.5 ms 1430 bytes from 94.156.119.69: icmp_seq=6 ttl=61 time=18.5 ms 1430 bytes from 94.156.119.69: icmp_seq=7 ttl=61 time=18.6 ms 1430 bytes from 94.156.119.69: icmp_seq=8 ttl=61 time=18.7 ms ^C --- 94.156.119.69 ping statistics --- 8 packets transmitted, 8 received, 0% packet loss, time 7013ms rtt min/avg/max/mdev = 18.536/18.632/18.762/0.070 ms debian@VM1159:~$ ping -M do -s 1423 94.156.119.69 PING 94.156.119.69 (94.156.119.69) 1423(1451) bytes of data. ^C --- 94.156.119.69 ping statistics --- 9 packets transmitted, 0 received, 100% packet loss, time 8189ms ```

LNVPS.net22d ago

Seems like its maybe a debian image issue, i just tested on a clean ubuntu vm and it works first try, checking debian.. ``` ubuntu@VM1160:~$ curl -v https://deb.debian.org/debian/extrafiles | more % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Host deb.debian.org:443 was resolved. * IPv6: 2a04:4e42:f::644 * IPv4: 199.232.58.132 * Trying [2a04:4e42:f::644]:443... * ALPN: curl offers h2,http/1.1 } [5 bytes data] * TLSv1.3 (OUT), TLS handshake, Client hello (1): } [512 bytes data] * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs { [5 bytes data] * TLSv1.3 (IN), TLS handshake, Server hello (2): { [122 bytes data] * TLSv1.3 (IN), TLS change cipher, Change cipher spec (1): { [1 bytes data] * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): { [19 bytes data] * TLSv1.3 (IN), TLS handshake, Certificate (11): { [2716 bytes data] * TLSv1.3 (IN), TLS handshake, CERT verify (15): { [264 bytes data] * TLSv1.3 (IN), TLS handshake, Finished (20): { [36 bytes data] * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): } [1 bytes data] * TLSv1.3 (OUT), TLS handshake, Finished (20): } [36 bytes data] * SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256 / x25519 / RSASSA-PSS * ALPN: server accepted h2 * Server certificate: * subject: CN=cdn-fastly.deb.debian.org * start date: Jan 1 01:02:30 2026 GMT * expire date: Apr 1 01:02:29 2026 GMT * subjectAltName: host "deb.debian.org" matched cert's "deb.debian.org" * issuer: C=US; O=Let's Encrypt; CN=R12 * SSL certificate verify ok. * Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption * Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption * Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption * Connected to deb.debian.org (2a04:4e42:f::644) port 443 * using HTTP/2 * [HTTP/2] [1] OPENED stream for https://deb.debian.org/debian/extrafiles * [HTTP/2] [1] [:method: GET] * [HTTP/2] [1] [:scheme: https] * [HTTP/2] [1] [:authority: deb.debian.org] * [HTTP/2] [1] [:path: /debian/extrafiles] * [HTTP/2] [1] [user-agent: curl/8.12.1] * [HTTP/2] [1] [accept: */*] } [5 bytes data] > GET /debian/extrafiles HTTP/2 > Host: deb.debian.org > User-Agent: curl/8.12.1 > Accept: */* ```

LNemail1d ago

They might be your provider's IPs. In any case, all we know is that the simple request `curl -v https://lnemail.net` does not work from LNVPS machines but does work from everywhere else. So there is a problem, just can't tell you what it is exactly. Any ideas?

0000 sats

LNemail22d ago

Nice progress. Not sure what distro the original report users were using: nevent1qqs8vvsux6lj6m49atqxpul8tnlpxpy769ywyclemnwyqwh0cvwcatqfytcvd And also @Roland from another VM.

0000 sats

LNVPS.net22d ago

Should be ok now, PMTU isnt very reliable (on certain paths), takes a while to learn mss, and if youre on debian it tries fancy post quantum crypto which is too big for even 1500 mtu so its almost always dropped

0000 sats

Roland22d ago

Looks like you fixed something, overnight my OpenClaw has been running much more reliably. Thanks!

0000 sats

LNemail21d ago

The curl to the Debian extrafiles now works, but `curl https://lnemail.net/api/v1/health -v` still doesn't. All valid HTTP(s) requests should work, regardless of the TLS key agreement used. Otherwise it indicates that there's still a network misconfiguration. Thanks for the progress!

0000 sats

LNVPS.net21d ago

I dont think we have an MSS issue with lnemail, even with a really low MSS it still doesnt connect, unless on your side its forcing the MSS higher than the actual path MSS between us.

0000 sats

LNemail21d ago

Nothing special on our side. Hosted at @268b948b…ed541495 LNemail does work well from any other place and has no special configuration(s). Any ideas on what could be going on?

0000 sats