<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic FTD 6.7.0 Dropping ICMP Fragmentation Needed (Type 3 Code 4) in Network Security</title>
    <link>https://community.cisco.com/t5/network-security/ftd-6-7-0-dropping-icmp-fragmentation-needed-type-3-code-4/m-p/5372932#M1124578</link>
    <description>&lt;P&gt;Hello Cisco Community,&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;Curl output from windows:&lt;BR /&gt;C:\Users\nyedige&amp;gt;curl -Iv &lt;A href="https://workpace.kz" target="_blank"&gt;https://workpace.kz&lt;/A&gt;&lt;BR /&gt;* Host workpace.kz:443 was resolved.&lt;BR /&gt;* IPv6: (none)&lt;BR /&gt;* IPv4: 213.130.74.49&lt;BR /&gt;* Trying 213.130.74.49:443...&lt;BR /&gt;* schannel: disabled automatic use of client certificate&lt;BR /&gt;* ALPN: curl offers http/1.1&lt;BR /&gt;* ALPN: server accepted http/1.1&lt;BR /&gt;* Connected to workpace.kz (213.130.74.49) port 443&lt;BR /&gt;* using HTTP/1.x&lt;BR /&gt;&amp;gt; HEAD / HTTP/1.1&lt;BR /&gt;&amp;gt; Host: workpace.kz&lt;BR /&gt;&amp;gt; User-Agent: curl/8.13.0&lt;BR /&gt;&amp;gt; Accept: */*&lt;BR /&gt;&amp;gt;&lt;BR /&gt;* Request completely sent off&lt;BR /&gt;&amp;lt; HTTP/1.1 200 OK&lt;BR /&gt;HTTP/1.1 200 OK&lt;BR /&gt;&amp;lt; date: Thu, 26 Feb 2026 12:02:42 GMT&lt;BR /&gt;date: Thu, 26 Feb 2026 12:02:42 GMT&lt;BR /&gt;&amp;lt; content-type: text/html; charset=UTF-8&lt;BR /&gt;content-type: text/html; charset=UTF-8&lt;BR /&gt;&amp;lt; last-modified: Mon, 16 Feb 2026 05:47:41 GMT&lt;BR /&gt;last-modified: Mon, 16 Feb 2026 05:47:41 GMT&lt;BR /&gt;&amp;lt; etag: W/"157c44-64aea7e491165-gzip"&lt;BR /&gt;etag: W/"157c44-64aea7e491165-gzip"&lt;BR /&gt;&amp;lt; x-frame-options: SAMEORIGIN&lt;BR /&gt;x-frame-options: SAMEORIGIN&lt;BR /&gt;&amp;lt; x-ws-id: 8&lt;BR /&gt;x-ws-id: 8&lt;BR /&gt;&amp;lt; x-host: workpace.kz&lt;BR /&gt;x-host: workpace.kz&lt;BR /&gt;&amp;lt; x-tilda-server: 13&lt;BR /&gt;x-tilda-server: 13&lt;BR /&gt;&amp;lt; x-tilda-imprint: f9585d7b-4907-459e-9bfe-bc427efdfc21&lt;BR /&gt;x-tilda-imprint: f9585d7b-4907-459e-9bfe-bc427efdfc21&lt;BR /&gt;&amp;lt;&lt;BR /&gt;* Connection #0 to host workpace.kz left intact&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Environment: FMC and FTD version 6.7.0. Internal clients are behind NAT on the FTD.&lt;BR /&gt;FTD managed via FMC&lt;BR /&gt;&lt;BR /&gt;Topology: Users(NATed) -&amp;gt; FTD -&amp;gt; internet -&amp;gt; workpace.kz server&lt;/P&gt;&lt;P&gt;Technical details:&lt;BR /&gt;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.&lt;/P&gt;&lt;P&gt;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).&lt;BR /&gt;output from packet capture:&lt;BR /&gt;802.1Q vlan#1050 P0 172.69.50.55 &amp;gt; X.X.X.X icmp: 213.130.74.49 unreachable - need to frag (mtu 1476)&lt;/P&gt;&lt;P&gt;I think the problem is that FTD drops these ICMP packets from 172.69.50.55.&lt;/P&gt;&lt;P&gt;I added a Prefilter Fastpath rule and an Access Control Rule to allow ICMP Type 3 Code 4, but it didnt work&lt;/P&gt;&lt;P&gt;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).&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;Alternatively, maybe there are other possible solutions or workarounds. I would appreciate any information or suggestions. Thank you!&lt;/P&gt;</description>
    <pubDate>Thu, 26 Feb 2026 12:33:18 GMT</pubDate>
    <dc:creator>nazar_y</dc:creator>
    <dc:date>2026-02-26T12:33:18Z</dc:date>
    <item>
      <title>FTD 6.7.0 Dropping ICMP Fragmentation Needed (Type 3 Code 4)</title>
      <link>https://community.cisco.com/t5/network-security/ftd-6-7-0-dropping-icmp-fragmentation-needed-type-3-code-4/m-p/5372932#M1124578</link>
      <description>&lt;P&gt;Hello Cisco Community,&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;Curl output from windows:&lt;BR /&gt;C:\Users\nyedige&amp;gt;curl -Iv &lt;A href="https://workpace.kz" target="_blank"&gt;https://workpace.kz&lt;/A&gt;&lt;BR /&gt;* Host workpace.kz:443 was resolved.&lt;BR /&gt;* IPv6: (none)&lt;BR /&gt;* IPv4: 213.130.74.49&lt;BR /&gt;* Trying 213.130.74.49:443...&lt;BR /&gt;* schannel: disabled automatic use of client certificate&lt;BR /&gt;* ALPN: curl offers http/1.1&lt;BR /&gt;* ALPN: server accepted http/1.1&lt;BR /&gt;* Connected to workpace.kz (213.130.74.49) port 443&lt;BR /&gt;* using HTTP/1.x&lt;BR /&gt;&amp;gt; HEAD / HTTP/1.1&lt;BR /&gt;&amp;gt; Host: workpace.kz&lt;BR /&gt;&amp;gt; User-Agent: curl/8.13.0&lt;BR /&gt;&amp;gt; Accept: */*&lt;BR /&gt;&amp;gt;&lt;BR /&gt;* Request completely sent off&lt;BR /&gt;&amp;lt; HTTP/1.1 200 OK&lt;BR /&gt;HTTP/1.1 200 OK&lt;BR /&gt;&amp;lt; date: Thu, 26 Feb 2026 12:02:42 GMT&lt;BR /&gt;date: Thu, 26 Feb 2026 12:02:42 GMT&lt;BR /&gt;&amp;lt; content-type: text/html; charset=UTF-8&lt;BR /&gt;content-type: text/html; charset=UTF-8&lt;BR /&gt;&amp;lt; last-modified: Mon, 16 Feb 2026 05:47:41 GMT&lt;BR /&gt;last-modified: Mon, 16 Feb 2026 05:47:41 GMT&lt;BR /&gt;&amp;lt; etag: W/"157c44-64aea7e491165-gzip"&lt;BR /&gt;etag: W/"157c44-64aea7e491165-gzip"&lt;BR /&gt;&amp;lt; x-frame-options: SAMEORIGIN&lt;BR /&gt;x-frame-options: SAMEORIGIN&lt;BR /&gt;&amp;lt; x-ws-id: 8&lt;BR /&gt;x-ws-id: 8&lt;BR /&gt;&amp;lt; x-host: workpace.kz&lt;BR /&gt;x-host: workpace.kz&lt;BR /&gt;&amp;lt; x-tilda-server: 13&lt;BR /&gt;x-tilda-server: 13&lt;BR /&gt;&amp;lt; x-tilda-imprint: f9585d7b-4907-459e-9bfe-bc427efdfc21&lt;BR /&gt;x-tilda-imprint: f9585d7b-4907-459e-9bfe-bc427efdfc21&lt;BR /&gt;&amp;lt;&lt;BR /&gt;* Connection #0 to host workpace.kz left intact&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Environment: FMC and FTD version 6.7.0. Internal clients are behind NAT on the FTD.&lt;BR /&gt;FTD managed via FMC&lt;BR /&gt;&lt;BR /&gt;Topology: Users(NATed) -&amp;gt; FTD -&amp;gt; internet -&amp;gt; workpace.kz server&lt;/P&gt;&lt;P&gt;Technical details:&lt;BR /&gt;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.&lt;/P&gt;&lt;P&gt;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).&lt;BR /&gt;output from packet capture:&lt;BR /&gt;802.1Q vlan#1050 P0 172.69.50.55 &amp;gt; X.X.X.X icmp: 213.130.74.49 unreachable - need to frag (mtu 1476)&lt;/P&gt;&lt;P&gt;I think the problem is that FTD drops these ICMP packets from 172.69.50.55.&lt;/P&gt;&lt;P&gt;I added a Prefilter Fastpath rule and an Access Control Rule to allow ICMP Type 3 Code 4, but it didnt work&lt;/P&gt;&lt;P&gt;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).&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;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.&lt;/P&gt;&lt;P&gt;Alternatively, maybe there are other possible solutions or workarounds. I would appreciate any information or suggestions. Thank you!&lt;/P&gt;</description>
      <pubDate>Thu, 26 Feb 2026 12:33:18 GMT</pubDate>
      <guid>https://community.cisco.com/t5/network-security/ftd-6-7-0-dropping-icmp-fragmentation-needed-type-3-code-4/m-p/5372932#M1124578</guid>
      <dc:creator>nazar_y</dc:creator>
      <dc:date>2026-02-26T12:33:18Z</dc:date>
    </item>
  </channel>
</rss>

