Skip to main content
Tutek
Tutek
New Member
January 9, 2025
Question

Akamai-CDN traffic is blocked

  • January 9, 2025
  • 3 replies
  • 8879 views

Hi,

I have ipv4 policy rule to allow traffic to bitdefender servers like:

*.bitdefender.com

*.bitdefender.net

with both ports 80 and 443 TCP.

But when I go to transfer logs, I see that traffic is still blocked:

 

185.225.250.26 (update-onprem.2d585.cdn.bitdefender.net)443 Akamai-CDN Deny

 

and many other subdomains of .bitdefender.net with application name Akamai-CDN.

Why this traffic is blocked as I allowed every (wildcard) subdomains for this traffic?

 

3 replies

Yurisk
SuperUser
Yurisk
SuperUser
January 9, 2025

If you could post more of the actual log it'd easier to point in the right direction. 

It may be allowed by Web Filtering but then blocked by AppCOntrol. If you are not using Security profiles in a rule, only FQDN *.bitdefender, may be DNS resolving by FGT and by clients in the LAN differ. Again without knowing the rule you are using and what FGT mechanism blocks this traffic it is just a guess.

 

    Tutek
    TutekAuthor
    New Member
    January 9, 2025

    On this ipv4 policy there is no App Control or Web Filter security profile applied. 

    Only AV and IPS.

    dingjerry_FTNT
    Staff
    dingjerry_FTNT
    Staff
    January 9, 2025

    Hi @Tutek ,

     

    Can you share your firewall policy about how you are allowing it?

    Tutek
    TutekAuthor
    New Member
    January 9, 2025

     

     

     

    config firewall policy     edit 117         set name "Bitdefender_Internet"         set uuid 3cb9e45e-ab2e-51eb-0902-1e63e406c495         set srcintf "Zone_Mgmt"         set dstintf "virtual-wan-link"         set action accept         set srcaddr "Bitdefender_SRV"         set dstaddr "Bitdefender_Internet"         set schedule "always"         set service "HTTPS" "HTTP"         set utm-status enable         set ssl-ssh-profile "certificate-inspection"         set av-profile "AV-default"         set ips-sensor "IPS-Mgmt"         set nat enable         set comments "Bitdefender to Internet"     next end
    FGT (addrgrp) # edit "Bitdefender_Internet"  FGT (Bitdefender_Internet) # show config firewall addrgrp     edit "Bitdefender_Internet"         set uuid 19721a98-ab2e-51eb-e689-dc885e657614         set member "*.bitdefender.com" "*.bitdefender.net" "download.bitdefender.com" "upgrade.bitdefender.com" "lv2.bitdefender.com" "submit.bitdefender.com" "*.ubuntu.com" "*.cdn.bitdefender.net" "update-onprem.2d585.cdn.bitdefender.net"     next end

     

     

    Zrzut ekranu 2025-01-09 175357.png

     

    Once the traffic is allowed by the rule, other time it is not:

    Zrzut ekranu 2025-01-09 175908.png

     

      dingjerry_FTNT
      Staff
      dingjerry_FTNT
      Staff
      January 9, 2025

      Hi @Tutek ,

       

      So you defined the wildcard FQDN address objects? 

       

      I do not recommend that you use it.  

       

      1) You need to ensure that the DNS traffic is passing through the FGT device;

      2) Even if FGT uses the same DNS servers as the clients, they may still get different resolved IPs.

       

      So you may consider using the web filter (URL Filter) instead.

       

      https://community.fortinet.com/t5/FortiGate/Technical-Tip-Using-a-static-URL-filter-feature-to-allow-block/ta-p/193086

       

      https://community.fortinet.com/t5/FortiGate/Technical-Tip-URL-Filter-expressions-for-the-FortiGate/ta-p/192746

       

      You may use the URL Filter even if you do not have a valid Web Filter license.

       

        Leigh_Bennett
        Leigh_Bennett
        New Member
        October 29, 2025

        To resolve this DNS cache IP mismatch issue do the following.

         

        Edit the Fortigate 'Address' object. Go to 'Advanced Options'.

        Set 'cache-ttl' to something low, like 5 seconds. Save the config.

         

        This forces the Fortigate firewall to clear the DNS cache for that Address object within 5 seconds, regardless of the TTL set by the DNS lookup. Experiment with different timings, i think 0 can be set so its never cached (haven't tried it myself).

         

        Do not do this for too many Address Objects otherwise it may affect performance of the firewall overall.

         

        FYI - this is typically caused by Fortigate IDS default profile. There is no way to disable the blocks other than switching off IDS entirely. You may find UTM logs indicating 'RECONNAISSANCE' attempt blocks. If a FQDN you allow uses a DNS Alias, that DNS Alias lookup is being blocked by IDS because the DNS Alias is not an allowed FQDN in your ruleset. The Fortigate has no way to determine that the subsequent DNS lookup for the DNS Alias relates to the initial DNS lookup for your allowed FQDN. As far as the Fortigate is concerned, these are two completely separate DNS lookups.

         

        Follow the above instructions for any FQDN you are having issues with, and any subsequent DNS Aliases for that FQDN that you add to your rulesets.

         

         

         

         

        Terms & ConditionsAccessibility statement