Forticlient Network Startup delay in Windows 7 x64

[#1]

Symptoms: After Windows start and logon, it takes up to 5 Minutes until Network Interfaces (LAN and/or WLAN) get online and their IPs. Until there network has just a red x. An ipconfig /all in this situation does also not show them. Reproducibility: Always, uninstallation of FortiClient solves the Problem Facts: FortiClient 4.1.2.132 and 4.1.2.138 Windows 7 x64 Enterprise and Ultimate No special component of FortiClient, happens also with just WebFilter Its a really burning issue to me, cause i need FortiClient for my work

[#2]

I am affraid the network startup problems related to Forticlient on Windows 7 64bit have not been resolved. I am also having the same problem. I had to use the Fortinet Client for my remote work (only VPN) for a while but I actually no longer need it now. I have therefore uninstalled Fortinet client completely from my Windows 7 (64bit) laptop and now it takes ages (usually much more than 5 minutes) for either of my network cards (standard NIC and wireless) to obtain IP from a DHCP and furthermore - even when it does get the IP, it takes ages (around 3-5 minutes) for applications, that use Winsock (such as web browsers) to perform DNS resolution and eventually connect to the Internet and every time I start a new web browser tab, it keeps resolving DNS for ages before it attempt to load the page... I have reset Winsock as well, using the netsh commands as well as removed network cards from the computer and re-installed the drivers and still no luck. I have the following observations: - when I reboot the computer and have either wireless or LAN ready, then the network will be available immediately (i.e. computer will obtain the IP from DHCP during boot-up), however the network status tray icon will show there is no Internet connectivity. As soon as I start browsing and wait ages until the first page comes up, the tray icon immediately removes the exclamation mark showing Internet connectivity but I still have to struggle with the long DNS resolution problem. - as soon as I disable LAN or wireless (i.e. manually or laptop goes to hibernate mode) and re-enable it again, I have to wait ages for the computer to obtain IP address and further ages for the web browser to be able to resolve DNS and browse the Internet - this makes the computer useless for networking.... - I also noticed that since this happened, the svchost.exe (one amongst many) process associated with WwanSvc (Automatic wireless WAN configuration), MpsSvc (Windows Firewall), DPS (diagnostic policy) and BFE (filtering) services, is consuming a lot of processor (around 25-30%), which was never the case before. I hope someone (i.e. Fortinet) will eventually post the solution soon as working with my laptop became extremely painful if not at all impossible.

edkulus, I' ve RECENTLY(using FortiClient 4.2.0.0250) experienced EXACTLY like you have described on several Windows 7 machines (32 and 64 bit). I too have tried: Removing NIC from Device manager and re-adding it, using the ReinstallNIC.exe tool in the " FortiClientTools" , disabling FortiProxy, resetting winsock, netsh int ip reset, and finally uninstalling FortiClient. Still had exactly the same issues as described above. Also noticed extremely high CPU usage on reboot of various services which never occurred before, experienced the same long waits to obtain an address, then after obtaining an address still took a long time to be able to browse the web, etc. I think this is a major problem that really needs to be addressed. Anyone have any open tickets on this issue with Fortinet?

[#3]

mike0, Great to hear people have similar problems. This means there is a major problem with Fortinet client software! I have made another observation: - the processor as I mentioned on the above post is consumed by a svchost.exe process (one amongst many other svchost.exe processes). This lasts for a lot of minutes (i.e. 20 minutes) after computer boot-up and it finally magically releases the processor resources and everything magically starts to work (i.e. networking, fast web browsing) until I make another reboot... I checked the Windows services related to network immediately after boot-up and throghout these lengthy minutes when I wait and wait.. it seems Windows is attempting to start the PolicyAgent (IPsec) and SSDPSRV (discovery) services and as soon as these are started (after very long time) the processor resources are released and this I think is precisely what makes the magic auto-cure happening. This is very odd I' d say and I really hope I won' t have to do a rebuild by the time Fortinet does something to fix the problem...

[#4]

I am having the same issue as above. After installing FortiClient the network adapters take a few min to configure after a shutdown or restart. This is a very annoying issue. Hopefull a fix comes soon.

[#5]

Does anyone have a pending ticket with Fortinet on this? The release notes in the FortiClient say: Description: Slow DHCP address acquisition with FortiClient installed and when upgrading from FortiClient v4.0 MR1 Patch 1 or Patch 2. Affected Platforms: Windows 7 Bug ID: N/A Status: N/A Workaround: Run the ReinstallNIC.exe utility. That is from the most recent version' s release notes 4.2.1 (I am pretty sure the same text was in 4.2.0' s release notes). I tried running their supplied ReinstallNIC.exe tool (there are also a few switches you can run it with as well - tried those still no luck). On this one particular machine it seemed no matter what I tried nothing was fixing it. Eventually I did a system restore prior to installation and all was fixed(certainly not a solution).

[#6]

mike0, I also have had enough of this trouble and eventually I gave up and went to restore the machine and now everything works great! Obviously that' s not the desired solution but the lesson is learned. I am not getting near to the Fortinet Client software (v.4.x). There are far too many bugs in it. On top of the network issues discussed on this thread, there are also major problems with strong IPSec VPN tunnel encryption (AES256), which simply does not work. Our IT people working with Fortinet appliances have reported all of these troubles to Fortinet but I doubt a workable solution will be provided soon... Will follow this thread with interest to see how long it takes Fortinet to get to the bottom of this clue.

[#7]

I saw in another post that the 4.2.1 has been released and the AES256 bug has been fixed

[Carl_Wallmark]

AES 256 bug is fixed, im using it.

[#9]

Can anyone comment if the Windows 7 Slow network start-up issue is still persistent in 4.2.1.0255? I re-read the release notes and as stated in one of my earlier posts the only thing that resembles this issue is still listed as a " known issue" Description: Slow DHCP address acquisition with FortiClient installed and when upgrading from FortiClient v4.0 MR1 Patch 1 or Patch 2. Affected Platforms: Windows 7 Bug ID: N/A Status: N/A Workaround: Run the ReinstallNIC.exe utility. Basically the same exact " known issue" is in the 4.2.0 release notes, which is what I have experienced a lot of problems with on several Windows 7 machines. On those machines I have tried running their ReinstallNIC.exe utility and it doesn' t solve the issue. Also tried uninstalling the NIC from device manager then reinstalling, uninstalling Forticlient, resetting tcp/ip stack and winsock and still nothing would fix the issue. As others described upon reboot there would be extremely high cpu utilization bringing the system to a crawl, no network access, if/when the computer obtained an IP, still unable to load web pages, etc. This was all on 4.2.0.0250 so I am wondering if this same problem is still around in 4.2.1.0255. edkulus, what build of FortiClient were you experiencing this on?

[laf]

I had the same issue on large scale deployment: more than 100 laptops which all came to the HO, got FortiClient installed then got spread all over the country. Imagine the next day, the phone ringing continuously with complaints. Disaster. Then I moved to v3.0 MR7. Pity I didn' t know about reinstalling the NIC drivers.