Hello Cisco Community,
I am facing an issue with a website workpace.kz (hosted on Tilda/Cloudflare) where modern browsers like Chrome fail to connect with an SSL_PROTOCOL_ERROR, while curl and InternetExplorer works fine.
Curl output from windows:
C:\Users\nyedige>curl -Iv https://workpace.kz
* Host workpace.kz:443 was resolved.
* IPv6: (none)
* IPv4: 213.130.74.49
* Trying 213.130.74.49:443...
* schannel: disabled automatic use of client certificate
* ALPN: curl offers http/1.1
* ALPN: server accepted http/1.1
* Connected to workpace.kz (213.130.74.49) port 443
* using HTTP/1.x
> HEAD / HTTP/1.1
> Host: workpace.kz
> User-Agent: curl/8.13.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< date: Thu, 26 Feb 2026 12:02:42 GMT
date: Thu, 26 Feb 2026 12:02:42 GMT
< content-type: text/html; charset=UTF-8
content-type: text/html; charset=UTF-8
< last-modified: Mon, 16 Feb 2026 05:47:41 GMT
last-modified: Mon, 16 Feb 2026 05:47:41 GMT
< etag: W/"157c44-64aea7e491165-gzip"
etag: W/"157c44-64aea7e491165-gzip"
< x-frame-options: SAMEORIGIN
x-frame-options: SAMEORIGIN
< x-ws-id: 8
x-ws-id: 8
< x-host: workpace.kz
x-host: workpace.kz
< x-tilda-server: 13
x-tilda-server: 13
< x-tilda-imprint: f9585d7b-4907-459e-9bfe-bc427efdfc21
x-tilda-imprint: f9585d7b-4907-459e-9bfe-bc427efdfc21
<
* Connection #0 to host workpace.kz left intact
Environment: FMC and FTD version 6.7.0. Internal clients are behind NAT on the FTD.
FTD managed via FMC
Topology: Users(NATed) -> FTD -> internet -> workpace.kz server
Technical details:
Path MTU to the destination is 1476 bytes. Chrome sends a large Client Hello with the DF bit set, which exceeds the MTU on the path i think.
Packet capture on the OUTSIDE interface shows that Cloudflare edge nodes (172.69.x.x) are sending back ICMP Type 3 Code 4 (Fragmentation Needed).
output from packet capture:
802.1Q vlan#1050 P0 172.69.50.55 > X.X.X.X icmp: 213.130.74.49 unreachable - need to frag (mtu 1476)
I think the problem is that FTD drops these ICMP packets from 172.69.50.55.
I added a Prefilter Fastpath rule and an Access Control Rule to allow ICMP Type 3 Code 4, but it didnt work
Packet-tracer shows that the packet passes the ACL but is dropped at the NAT stage: Drop-reason: (acl-drop) Flow is denied by configured rule, Drop-location: (nat-rpf-failed).
I think this happens because the ICMP error comes from a different IP (172.69.x.x) than the original destination of the TCP flow (213.130.74.49). The NAT engine rejects this unsolicited ICMP message because it does not match the exact stateful entry.
Question: Is there a way on FTD 6.7.0 to allow these asymmetric ICMP unreachable messages to pass through NAT to the internal client without globally lowering the TCP MSS? I want to fix PMTUD properly.
Alternatively, maybe there are other possible solutions or workarounds. I would appreciate any information or suggestions. Thank you!
