FQDN Addresses for Destination in a Policy

[#1]

Hello I have a FortiGate running v4.0.0, build0092. I have been messing around for days now trying to make it allow my Trend Micro OfficeScan and ScanMail servers use the ActiveUpdate service without looking at the traffic at all. I have figured out how to make it work by creating a policy at the top of the list that allows HTTP to go unscanned, unprotected, all the time to an IP address for the Trend ActiveUpdate server (one of them...) but the problem now is that I noticed that the IP addresses that Trend uses for the servers are all dynamic (they change very quickly), I called Trend support and they confirmed that this is correct. I can get it to work by pinging the FQDN of each update server to get the current IPs then quickly going into the Fortigate and changing the IPs on the firewall addresses that are assigned to the policy and then quickly going into the Trend applications and forcing a manual server update. This you can imagine is not a solution. So I thought that I would just use the FQDNs in the firewall addresses for the policy. They don' t work, and I just can' t figure out why when I can ping them just fine. I will try to explain what I have set up and hopefully someone here may have some insight. Firewall Policy (at the top) internal -> wan1 Source: all Destination: Trend Update Servers (this is an address group) Schedule: always Service: HTTP Profile: None Action: ACCEPT Firewall Address 1 Name: Trend OS Update Server FQDN: osce8-p.activeupdate.trendmicro.com Interface: wan1 Firewall Address 2 Name: Trend SM Update Server 1 FQDN: smex8-as.activeupdate.trendmicro.com Interface: wan1 Firewall Address 3 Name: Trend SM Update Server 2 FQDN: smex8-p.activeupdate.trendmicro.com Interface: wan1 The above 3 addresses are grouped into the group name: Trend Update Servers As I mentioned above, this configuration doesn' t work, but, if I go into each address and change it to current IP instead of FQDN then everything works wonderfully, until the Trend IPs dynamically change (faster than you can blink). I would appreciate anyone' s help with this as I am now really frustrated. Thanks! Marc Jones

[rwpatterson]

If you know for sure that these servers fall into a class c subnet, just make that subnet the destination for the policy. Usually it is only one or 2 class c subnets... ADDED*** Never mind. These subnets are fed from AKAMAI.

 C:\>ping smex8-p.activeupdate.trendmicro.com
 Pinging a151.d.akamai.net [96.7.46.16] with 32 bytes of data:
 Reply from 96.7.46.16: bytes=32 time=24ms TTL=54
 
 C:\>ping  smex8-as.activeupdate.trendmicro.com
 Pinging a151.d.akamai.net [96.7.46.9] with 32 bytes of data:
 Reply from 96.7.46.9: bytes=32 time=25ms TTL=54
 
 C:\>ping osce8-p.activeupdate.trendmicro.com
 Pinging e132.d.akamaiedge.net [96.17.32.158] with 32 bytes of data:
 Reply from 96.17.32.158: bytes=32 time=46ms TTL=50
 
 C:\>

They are also used by other companies to distribute updates and patches... You' ll have to find another way around this one.... Maybe using URL filtering, or Fortiguard custom ratings...

[#3]

The IP addresses that I can see when pinging for a little while are all over the place. Trend will not give out any IP address information for these update servers (I asked them and they said NO). Pinging: osce8-p.activeupdate.trendmicro.com I get all these within 5 minutes: 96.17.240.158, 96.17.224.158, 72.247.200.158 Pinging: smex8-p.activeupdate.trendmicro.com I get all these within 5 minutes: 96.6.120.8, 96.6.120.9, 96.6.120.19 I can' t understand why using the FDQNs doesn' t work. It makes no sense.

[#4]

Hey Bob I appreciate your quick help on this one as it has solved the problem. I created a URL filter and entered those 3 URLs with the Action: Exempt. Then I assigned that URL filter to my internal -> wan1 HTTP policy. Now all of my Trend Micro servers are successfully updating their components. Thank you! Marc Jones

[rwpatterson]

You are welcome.