We are having this problem, too.  Since the defs have been updated, Symantec reports auto-protect found risk, Backdoor.Delf.  :  C:\Windows\Downloaded Program Files\TunnelServer.exe.

Users are unable to work remotely if they've received r5 defs.  This is a big problem on a Monday.

An update quick would be helpful, having to rollback many users.

Yep, problem here too.... can we get symantec to issue a statement on this to find out what they are doing to resolve this?

Download the latest rapid release.  It fixes this issue.

http://www.symantec.com/business/security_response/definitions/download/detail.jsp?gid=rr

Once the users are disconnected, how are you guys fixing them?  I've implemented an exclusion for now, but too late for a lot of our folks, and the people who are already disconnected won't be able to connect to get the policy update.

Of course I disabled the ability for users to set their own exceptions...

Have the users download the rapid release file for their system and run it.  It fixed our clients who are remote.

Our users don't have admin rights, and I can't seem to get the RR defs to install properly unless they are run with admin rights.

This is what I've had to do to get it to work:

1)  Download the RR defs from the site called out above.
2)  As an admin, run the EXE for the RR defs.
3)  Verify that all connections to the FirePass server are closed (close IE).
4)  As an admin, delete c:\windows\downloaded program files\tunnelserverx.dll.
5)  Log back in to FP and try to connect to the VPN.  Let it download and replace the Tunnel Server file.

Steps 3 - 5 could be necessary because I previously tried to restore the file out of quarantine and it was re-quarantined.  Is it my understanding that installing the RR defs should automatically take the file out of quarantine and put it back?

Hi All,

This is the fix I've used as a temp option:

I logged into the SEPM console,

1. Go to policy / Centralized Exceptions / (Your PC Exceptions List)
2. Highlight the policy / Edit Policy
3. Click on "Centralized Exceptions"
4. Click Add / Security Risk Exceptions / File
5. Type "C:\WINDOWS\Downloaded Program Files\TunnelServer.exe" in "File (Include Full Path):
6. Click OK, then exit
7. Right Click on SEP Icon by clock on the effected PC, Update Policy (This works if PC is in the office)
8. Double Click SEP Icon and click "View Quarantine"
9. Right Click on "TunnelServer.exe" in list and click Restore.

This will fix this issue on a temp basis pending a Symantec release, we are still working on a remote fix for users offsite, will publish more results as I get them.

Cheers

Thought i would throw my hat into the ring for this one...

We have encountered the same problem with Firepass software 6.1.0. As above, installing the Rapid Release definitions v5r32 (or similar) for SEP 11.0.4 and above resolves the issue. Havent tested with older clients.

Symantec - please hurry up and get full-release definitions out ASAP. I note that we are now 6 hours into the problem and still no new definitions have been released. It is not reasonable to expect us to manually deploy RR definitions, into a managed environment for large numbers of clients. They are great for a quick fix, but should never be a solution.

We have around 700 clients which are affected with this.
Risk name is : backdoor.delf which is causing the  users to connect remotely as they are getting the proxy server error .

Same problem here as well. How can Symantec manage to do this so many times? 

Go to http://www.symantec.com/business/security_response/definitions/download/detail.jsp?gid=rr  download the defintions and run a scan

and if the file is still detected then submitt the file to symantec

Have the full release definitions been put out yet?  After a few yesterday, we got slammed this morning.   

I have followed the instructions given by Prachand and ran the .exe, full system scan and reboot nothing found no issues to report, but when my wife tries to log into her Citrix system at her work, from here at home, the firepass she is going through says cannot connect. IT support still seem to be suggesting its a backdoor.delf issue, any advice anyone?

We have been able to run the Rapid Release definitions from an earlier post, then either "restore" or "undo" depending on the client version the quarantined backdoor.delf file and they are back in business.

I JUST HOPE THEY GET THE FULL DEF VERSION RELEASE WITH THIS FIX SOON.

To All I Found to Fix the Issue you do need to Update the AVsoftware with the Update provided by Prachand. After that you must navigate back to the file location C:\Windows\Downloaded Program Files\  and delete any files that are damaged such as this one in the screenshot:

Then Attempt to Reconnect it should reinstall the file and users will be up and running.

Make sure you have atleast virus defintion dated 2009--11--23 rev.025

Many of the users who were broken yesterday have come into the office this morning and we have found that the following steps will fix them:

1) As stated in the post above from Prachand, verify that their definitions have been updated to at least 2009-11-23 rev.025 (ours are currently showing r37).
2) On the client PC, open the Symantec agent and click on the 'View quarantine' tab (hopefully your policies quarantine infected files rather than delete them).
3) Highlight the quarantined file and click the Restore button.

On three laptops so far this morning, this has fixed the connection problem without having to worry about users having admin rights.

I have had problems with the process when someone had already tried to restore the quarantined file.  In those circumstances, deleting the tunnelserverx.dll file has fixed them, but that step requires admin rights in our environment.

I had an excellent discussion with a Symantec engineer today that helped shed some light on why the fix for this problem was more difficult for us than it was for other companies.  I hope this explanation helps someone else.

Problem #1:  The earliest answer to fix the problem was to download the Rapid Release definitions.  Our users don't have admin rights, so they could download the RR defs, but they could not successfully install them.  Because their access to our network had been broken, we could not push the updates to them.

Problem #2:  We were told that the problem will fix itself once the user installs the RR defs.  What was not clear was that it was assumed our AV policy was set to resotore files from quarantine when a fix came available.  We had intentionally set our configuration to not restore anything out of Quarantine.  We figured that once something was quarantined it should stay there.

Problem #3:  Once our remote users were broken, they could not connect back to our server to download updated definitions.  We had intentionally configured our clients to only download their definitions from our corporate server, so they were stuck in a perpetual state of broken-ness until they could physically connect to our network.

We've made changes to the policies described above.  We've now enabled automatic fixes for quarantined files, and we're now enabling the client to go out to the Internet to download definitions.  We are also now allowing our users to execute a LiveUpdate if they need to.

Painful lessons.

Have tried going into IE and Manage Add-Ons but still can't see damaged file to delete it.  Have also tried thru Explorer and command line but says I don't have permissions.  Anyone got any more ideas?