Akamai-CDN traffic is blocked

[Tutek]

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?

[Yurisk]

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]

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

Only AV and IPS.

[dingjerry_FTNT]

Hi @Tutek ,

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

[Tutek]

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

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

[dingjerry_FTNT]

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...

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

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

[dingjerry_FTNT]

Hi @Tutek ,

As per the screenshot of the logs, most of them were denied by the implicit policy.

That means the IPs do not match the ones resolved (wildcard FQDN) on FGT. 

Please check this KB on how to verify the FQDN IPs in the DNS cache:

https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-How-to-verify-the-FDQN-IP-address-in...

[Melissa]

Hola

tengo un caso parecido, si se sospecha sobre resolución de dns, cual seria la recomendación? habría que tomar alguna acción en fortigate?

[Leigh_Bennett]

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.