Inbound rules based on URL.

[IrbkOrrum]

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?

[AEK · Accepted solution]

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

[IrbkOrrum]

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

[AEK]

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.

[IrbkOrrum]

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]

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.

[IrbkOrrum]

I don't think we plan to NOT have FortiCare, but it's good to know.  Thanks so much for this!  I never used it, didn't know it existed, but it's going to make a life a lot easier!  10 points too <insert your house here>!

[AEK]

Now I justed learned an interesting command from you:

diagnose internet-service match <vdom-name> <ip> <netmask>

Thanks!

[dingjerry_FTNT]

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