Explorer III

Solved

Inbound rules based on URL.

Forum|Forum|1 year ago
April 1, 2025
3 replies
2067 views

We've got some development that's going on in Azure which makes a call to our internal servers. I've got the "source" inbound rule pointing to a VIP and restricted to traffic coming from

*.azure-api.net

*.microsoft.com

*.slope.io

The problem is with something like apimanagement-cors-proxy-prd.azure-api.net depending on what IP that resolves to, the firewall may or may not allow traffic coming from that URL. As I understand it from FortiNet support, this is "expected" behavior. IE if the firewall has resolved apimanagement-cors-proxy-prd.azure-api.net to be 13.91.254.72 and the traffic is coming from 13.91.254.72, then the traffic will be allowed in. However if traffic coming from apimanagement-cors-proxy-prd.azure-api.net is coming from 20.121.82.216 and the firewall hasn't resolved 20.121.82.216 as a valid IP for apimanagement-cors-proxy-prd.azure-api.net then the traffic won't be allowed in.
The only other option would be to allow Azure traffic via IPs but that's a list of 1000's of IPs that change weekly and that's not really a sustainable solution.
How do you work around this issue?

Best answer by AEK

Did you check if ISDB as source can help in your case?

AEKAnswer

SuperUser

Did you check if ISDB as source can help in your case?

AEK

IrbkOrrumAuthor

Explorer III

I'm unfamiliar with what ISDB is? Please explain.

AEK

SuperUser

In your inbound rule, you select "Internet Service" as source, instead of FQDN. Then try to find azure-api and others if they exist. In case they don't exist in the DB then forget about this solution.

AEK

IrbkOrrumAuthor

Explorer III

I've never used this feature before! This is kind of awesome. Doing some research it looks like you could look up the service via a CLI command
diagnose internet-service match <vdom-name> <ip> <netmask>
IE
diagnose internet-service match root 20.121.82.216 255.255.255.255
which returns a list like so:
Internet Service: 327786(Microsoft-Azure), matched entry num: 2, matched num: 2
Internet Service: 327681(Microsoft-Web), matched entry num: 4, matched num: 4
Internet Service: 327682(Microsoft-ICMP), matched entry num: 1, matched num: 1
Internet Service: 327683(Microsoft-DNS), matched entry num: 2, matched num: 2
Internet Service: 327684(Microsoft-Outbound_Email), matched entry num: 4, matched num: 4
ETC....
Does that mean that I would use "Microsoft-Azure" as a source on my inbound firewall rule and it would always allow traffic from apimanagement-cors-proxy-prd.azure-api.net regardless of if the firewall has resolved the IP as 13.91.254.72 or 20.121.82.216 or whatever other IP the traffic might be coming from?

AEK

SuperUser

I agree with you that ISDB is a great feature, but since they are dynamic addresses, you need to have valid FortiCare subscription so that you can get ISDB updates.

Every ISDB service can be used either as source, or as destination, or both. You can see if a service can be used as source or destination or both under menu Policy & Objects > ISDB, then see the column "Direction" for the required service. But for MS Azure I can see it is bidirectional.

Just to make sure, you can check if the IP address is in the service by double-clicking on the service, then show entries.

AEK

dingjerry_FTNT

Staff

Hi @IrbkOrrum ,

The wildcard FQDN resolution depends on the DNS traffic passing through FGT. So if there is no relevant DNS traffic passing through FGT, FGT may not get the correct IPs.

You may try with ISDB. You may check the following article about the usage of ISDB as source/destination addresses in a firewall policy:

https://docs.fortinet.com/document/fortigate/7.6.2/administration-guide/336471/allow-creation-of-isdb-objects-with-regional-information

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded