(this post was originally started here, http://answers.microsoft.com/en-us/office/forum/office_2010-outlook/windows-7-built-in-firewall-filtering-platform/7312a367-3a9f-470a-b6c7-56c041630af1, but recommended to move to this forum)

I first encountered this problem on a Windows 7 computer running Outlook 2007 a couple of weeks ago. The system kept asking the primary user for a password to connect to our Exchange Service. The user kept typing in the correct password, but it would never connect. Using Outlook Web Access from the same computer with the same user and password was successful, so the credentials and network connection seemed good.

After checking the Security Logs, I found pairs of Event 5152 and 5157 whenever the user tried to enter a password. Example events are listed below (although they are from the most recent incidence). I found out that the Filtering Platform is supposed to be part of Windows Firewall, but couldn't find much other information about it. However, the Windows Firewall is turned off by Group Policy (verified by looking in the Control Panel for Window Firewall), so I didn't think it should be blocking anything. Oddly enough, the Windows Firewall service was running on this computer, but it was running on all computers, even if they didn't have this problem.

I found that I could make the problem go away by stopping the Windows Firewall service. However, it seems odd that would be necessary. It seems a bit of a kludgy fix.

I hoped that the problem would only by on one system and could let it go for a bit. Unfortunately, I just had the problem crop up on a new Windows 7 system with Outlook 2010 installed.

At this point, I'm concerned about what might be causing it and that it might start happening on all our systems. I could stop the Windows Firewall service on all of them, but I'd like to understand what might be happening more before taking that action.

For reference, both systems have received all Automatic Updates and are running the McAfee Total Protection Service anti-virus and firewall services.

Any thoughts or suggestions would be appreciated.

Thanks in advance,

indyvql

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          3/9/2015 9:05:38 AM
Event ID:      5152
Task Category: Filtering Platform Packet Drop
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      usercomputer.domain.com
Description:
The Windows Filtering Platform has blocked a packet.

Application Information:
 Process ID:  10712
 Application Name: \device\harddiskvolume3\program files\microsoft office\office14\outlook.exe

Network Information:
 Direction:  Outbound
 Source Address:  <IP Address of User Computer>
 Source Port:  55279
 Destination Address: <Unknown IP Address in 192.168 Subnet, Which is Not Used By Us>
 Destination Port:  443
 Protocol:  6

Filter Information:
 Filter Run-Time ID: 67045
 Layer Name:  Connect
 Layer Run-Time ID: 48

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          3/9/2015 9:05:38 AM
Event ID:      5157
Task Category: Filtering Platform Connection
Level:         Information
Keywords:      Audit Failure
User:          N/A
Computer:      usercomputer.domain.com
Description:
The Windows Filtering Platform has blocked a connection.

Application Information:
 Process ID:  10712
 Application Name: \device\harddiskvolume3\program files\microsoft office\office14\outlook.exe

Network Information:
 Direction:  Outbound
 Source Address:  <IP Address of User Computer>
 Source Port:  55279
 Destination Address: <Unknown IP Address in 192.168 Subnet, Which is Not Used By Us>
 Destination Port:  443
 Protocol:  6

Filter Information:
 Filter Run-Time ID: 67045
 Layer Name:  Connect
 Layer Run-Time ID: 48

(follow-up post by myself from original forum)

As an update, I just had another computer that was Windows 7 with Outlook 2007 that had this problem. The fix that I am using is to restart the computer, run the update on the McAfee console, then stop the Windows Firewall service. After doing all of that, Outlook runs without asking for a password at all (which is the expected behavior). Simply restarting the computer definitely does not solve the problem. It doesn't seem that just updating McAfee solves the problem either, although I am not as sure of this.

As an additional piece of information that may or may not be related, every 5152 and 5157 message seems to include a destination address of 192.168.56.1. I am not sure why that would be referenced as it does not represent a subnet in our network or any known device for our company. All of our subnets start with a number other than 192.

Hi indyvql,

"..are running the McAfee Total Protection Service anti-virus and firewall services."

- So you've enabled McAfee firewall? If you have McAfee firewall turned on, then everything is managed by McAfee Personal Firewall which might cause the issue.

To troubleshoot the issue, I would suggest we first disable McAfee temporarily, then try again.

Also, as you've mentioned, please go ahead to have a test with just updating McAfee but not stopping the Windows Firewall service, then verify result.

Regards,

Ethan Hua
TechNet Community Support

Personally, I think this issue should be addressed in Windows client forum as you've already located that it's actually blocked on Windows level. Office client is not involved here.

Ethan,

I ran into another computer with this problem late yesterday. In that case, simply updating the McAfee client allowed Outlook to start working again.

I'm guessing that McAfee was the problem here and not Outlook, but that only makes sense if McAfee actually makes use of the built-in Windows Filtering Platform (since that is what is throwing the events in the audit log).

I will restart the Windows Firewall service and see if everything is still operational on the systems.

Thanks,

indyvql

Outlook still seems to be operational after the Windows Firewall service was restarted on all computers. I guess it was an odd interaction with McAfee. The problem is resolved.

Thanks,

indyvql

Hi indyvql,

Thank you for the confirmation. And good to see the issue has been resolved.

Regards,

Ethan Hua
TechNet Community Support