FG-100A problems with updates, ping & browsing

[#1]

We have recently purchased a FG-100A with 1 yr services bundle. I have upgraded the firmware to version 3.00,build0247,060417. I have been observing very weird behavior on the FG-100A. 1) After each restart of the firewall the updates are gone & Web Filtering, antispam shows Not Licensed. also all AV, IPS update lights are flashing red. 2) on the fortiguard center page the test availability button always shows DNS error. No matter if the DNS server is readily available on ping. 3) If we ping the firewall wan1 address from outside, we get a request timeout even though the gateway never times out. 4) More strange is if we keep a continuous ping on wan1 whenever we hit the status link on the web manager gui we get pings briefly, then it again goes back to timeout. 5) Even after putting the override ip address the updates do not take place. 6) The surfing through the firewall is at a standstill. 7) On the web manager gui only the status link comes up very fast. all other pages time out. Please help urgently as the entire campus internet access is down & this is the admission season.

[#2]

No!!! I did change the static routes positions. But as soon as I make both wan1 & wan2 equidistant I start getting timeouts on wan1. Whichever route is on number 1 position experiences timeouts. The static table now looks like this.. ( No changes so far to policy routes) IP Mask Gateway Device Distance 0.0.0.0 0.0.0.0 isp_1_gateway wan1 1 [Delete] [Edit] 0.0.0.0 0.0.0.0 isp_2_gateway wan2 1 [Delete] [Edit]

[UkWizard]

Have a read through this doc, might explain better on fortinets capabilities. [link]http://kc.forticare.com/default.asp?id=376&SID=&Lang=1[/link]

[#4]

Yes I have defined ping servers for both wan1 & wan2. also I am still not clear as to why the interface which is on number 1 position in the static route list should experience time outs? could it have to do anything with some parameter which I remember can be only set from the CLI? Let be brush up on that & the link you sent. But now its clear that its a routing issue.

[UkWizard]

i would expect the opposite, where the second one in the list timeouts.

[UkWizard]

actually i think if you remove all the wan1 policy routing statements and have wan1 at the top, this should resolve it.

[#7]

I have set the priority of both the static routes to same from CLI. ( Fortigate admin guide for ver 3.0 ). Now the priority as well as the distance of both routes are same. Even then the route at number 1 position experiences ping time outs. Whereas from the link you sent ...

. Monitoring both WAN interfaces simultaneously. If you need to be able to ping both WAN interfaces in order to demonstrate that the links are up, you will need to set the distance on both default routes to be the same.

And from the Admin guide for 3.0 ...

In summary, if a route in the routing table has a lower sequence number than another route to the same destination, the FortiGate unit will choose the route with the lower sequence number before choosing the other route. Because you can use the CLI to specify which sequence numbers or priority field settings to use when defining static routes, routes to the same destination can be prioritized according to their sequence numbers and priority field settings. To prioritize a static route, you must create the route using the config router static CLI command and specify a low sequence number or high priority for the route.

In effect monitoring both interfaces with ping does not work. I tried all permutations & combinations of distance & priority. The last route in sequence OR the highest priority route takes precedence. Now the problem is if wan2 has a precedence & if in DNS settings and wan1 isp' s dns server is 1st in the list, the firewall is unable to resolve the domain name & hence the updates fail. Even though the ip of 2nd isp is given in the second dns server field. I have verified this. This creates the problem that in case of link failure of the ISP with higher sequence number, updates are bound to fail. And I think same thing is happening on system restart. Is this a bug or is there a way to resolve this?

[UkWizard]

Wouldnt comment on any of that, seeing as its v3 you are running. I would not run v3 just yet for any of my customers, too early for that. I dont expect dns to be an issue, as every DNS server i have ever encountered is accessible from anywhere on the web, not just from its own ip addresses. Surely if you left the Fortinet default dns servers in there, either wan will be able to access it and thus resolve names for the update servers. As you are running v3 though, i dont really know what else to suggest, either contact support with the new info you have gained, or start deeper level diags, like using the " diag sniff" packet sniffing command to see what interfaces the packets are going out. I presume you did try what i suggested earlier, about removing the wan1 policy routes ? and checked the gateways for each entry.

[UkWizard]

Whoops should also mention, technically why..... Asymetrical routing, basically, when you ping wan1, because you have wan2 as the primary path, the packet replies via that interface. Which the response is dropped as it has a different source address. Stupid i know, but thats routing for ya ...

[UkWizard]

have you defined both ping servers on the interfaces ?