Managing Active Directory can get complicated. Often, the native tools for managing AD are just not up to the task. The largest Active Directory installations in the world have relied on one tool to manage their day-to-day administration tasks: Hyena. Start your trial today.
Course Of The Month
10 days, 19 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
Multiple audit failure events 5152 and 5157 recently flooding event log.
Posted on 2016-10-14
My SBS 2008 server security event log is showing about 10 audit failure pairs per second - events 5152 and 5157. One pair of the log entries is shown at the bottom of this post. I don't see any external symptoms, but I expect that there is an undue load on the server and a possible security gap. I don't think it is a firewall problem because I don't think there should be traffic between the server and this external IP address. This is a somewhat recent phenomenon. What is happening and how do I get rid of it without turning off auditing?
Comcast is providing both ISP and VOIP services through separate channels. The Internet access comes through a router and a Dell PC2824 switch to the server and the rest of the network. The Comcast VOIP is fairly new and comes through their box and the same PC2824 switch. The PC2824 is configured to keep the data on the default VLAN 1 and the voice on VLAN 20. The VOIP phones and user computer share Ethernet cables to the switch. The VOIP phones are configured to keep to VLAN 20 while letting VLAN 1 and untagged packets pass through. The user computers and SBS2008 server do not know about the VLAN usage. The port for the SBS server is forbidden for VLAN 20 packets.
The log entries show svchost.exe as process ID 532 which relates to the following services: Windows Audio, DHCP client, Windows Event Log, and TCP/IP NETBIOS Helper.
50.143.170.64 is unknown and owned by Comcast. It is not the public IP for the network. It may be related to the VOIP service. 192.168.11.2 is the local IP address for the SBS2008 server. 192.168.11.1 is the gateway. I don't understand how a packet could have the server as a source and still be inbound.
Thanks,
Joe
================ Event Log pairs ================
Log Name: Security
Source: Microsoft-Windows-Security
Date: 10/11/2016 9:29:12 AM
Event ID: 5152
Task Category: Filtering Platform Packet Drop
Level: Information
Keywords: Audit Failure
User: N/A
Computer: SBS2008.domain.local
Description:
The Windows Filtering Platform blocked a packet.
Application Information:
Process ID: 532
Application Name: \device\harddiskvolume1\wi
Network Information:
Direction: Inbound
Source Address: 192.168.11.2
Source Port: 0
Destination Address: 50.143.170.64
Destination Port: 0
Protocol: 47
Filter Information:
Filter Run-Time ID: 0
Layer Name: Receive/Accept
Layer Run-Time ID: 44
--------------------- and -------------------------
Log Name: Security
Source: Microsoft-Windows-Security
Date: 10/11/2016 9:29:12 AM
Event ID: 5157
Task Category: Filtering Platform Connection
Level: Information
Keywords: Audit Failure
User: N/A
Computer: SBS2008.domain.local
Description:
The Windows Filtering Platform has blocked a connection.
Application Information:
Process ID: 532
Application Name: \device\harddiskvolume1\wi
Network Information:
Direction: Inbound
Source Address: 192.168.11.2
Source Port: 0
Destination Address: 50.143.170.64
Destination Port: 0
Protocol: 0
Filter Information:
Filter Run-Time ID: 0
Layer Name: Receive/Accept
Layer Run-Time ID: 44
and
Log Name: Security
Source: Microsoft-Windows-Security
Date: 10/11/2016 9:29:12 AM
Event ID: 5152
Task Category: Filtering Platform Packet Drop
Level: Information
Keywords: Audit Failure
User: N/A
Computer: SBS2008.domain.local
Description:
The Windows Filtering Platform blocked a packet.
Application Information:
Process ID: 532
Application Name: \device\harddiskvolume1\wi
Network Information:
Direction: Inbound
Source Address: 192.168.11.2
Source Port: 0
Destination Address: 50.143.170.64
Destination Port: 0
Protocol: 47
Filter Information:
Filter Run-Time ID: 0
Layer Name: Receive/Accept
Layer Run-Time ID: 44
==========================
Comcast is providing both ISP and VOIP services through separate channels. The Internet access comes through a router and a Dell PC2824 switch to the server and the rest of the network. The Comcast VOIP is fairly new and comes through their box and the same PC2824 switch. The PC2824 is configured to keep the data on the default VLAN 1 and the voice on VLAN 20. The VOIP phones and user computer share Ethernet cables to the switch. The VOIP phones are configured to keep to VLAN 20 while letting VLAN 1 and untagged packets pass through. The user computers and SBS2008 server do not know about the VLAN usage. The port for the SBS server is forbidden for VLAN 20 packets.
The log entries show svchost.exe as process ID 532 which relates to the following services: Windows Audio, DHCP client, Windows Event Log, and TCP/IP NETBIOS Helper.
50.143.170.64 is unknown and owned by Comcast. It is not the public IP for the network. It may be related to the VOIP service. 192.168.11.2 is the local IP address for the SBS2008 server. 192.168.11.1 is the gateway. I don't understand how a packet could have the server as a source and still be inbound.
Thanks,
Joe
================ Event Log pairs ================
Log Name: Security
Source: Microsoft-Windows-Security
Date: 10/11/2016 9:29:12 AM
Event ID: 5152
Task Category: Filtering Platform Packet Drop
Level: Information
Keywords: Audit Failure
User: N/A
Computer: SBS2008.domain.local
Description:
The Windows Filtering Platform blocked a packet.
Application Information:
Process ID: 532
Application Name: \device\harddiskvolume1\wi
Network Information:
Direction: Inbound
Source Address: 192.168.11.2
Source Port: 0
Destination Address: 50.143.170.64
Destination Port: 0
Protocol: 47
Filter Information:
Filter Run-Time ID: 0
Layer Name: Receive/Accept
Layer Run-Time ID: 44
--------------------- and -------------------------
Log Name: Security
Source: Microsoft-Windows-Security
Date: 10/11/2016 9:29:12 AM
Event ID: 5157
Task Category: Filtering Platform Connection
Level: Information
Keywords: Audit Failure
User: N/A
Computer: SBS2008.domain.local
Description:
The Windows Filtering Platform has blocked a connection.
Application Information:
Process ID: 532
Application Name: \device\harddiskvolume1\wi
Network Information:
Direction: Inbound
Source Address: 192.168.11.2
Source Port: 0
Destination Address: 50.143.170.64
Destination Port: 0
Protocol: 0
Filter Information:
Filter Run-Time ID: 0
Layer Name: Receive/Accept
Layer Run-Time ID: 44
and
Log Name: Security
Source: Microsoft-Windows-Security
Date: 10/11/2016 9:29:12 AM
Event ID: 5152
Task Category: Filtering Platform Packet Drop
Level: Information
Keywords: Audit Failure
User: N/A
Computer: SBS2008.domain.local
Description:
The Windows Filtering Platform blocked a packet.
Application Information:
Process ID: 532
Application Name: \device\harddiskvolume1\wi
Network Information:
Direction: Inbound
Source Address: 192.168.11.2
Source Port: 0
Destination Address: 50.143.170.64
Destination Port: 0
Protocol: 47
Filter Information:
Filter Run-Time ID: 0
Layer Name: Receive/Accept
Layer Run-Time ID: 44
==========================
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
-
10
6
4
21 Comments
Active 2 days ago
So your server is NOT "192.168.11.2"
It appears someone has placed a rouge device on your network.
It appears someone has placed a rouge device on your network.
loftyworm,
My server is at 192.168.11.2 as I stated. I don't understand your comment or why you would think it was not.
I presume the rogue device comment stems from you thinking that the server was not at 192.168.11.2.
My server is at 192.168.11.2 as I stated. I don't understand your comment or why you would think it was not.
I presume the rogue device comment stems from you thinking that the server was not at 192.168.11.2.
Active 2 days ago
My apologies, I did not see the last paragraph;
I agree, this is a bit confusing. Is there server firewall On? This may indicate that it is blocking outbound traffic. There is a specific Firewall log as well. You can find it here if it is on;
<sys32>\LogFiles\Firewall\
This link may be helpful
http://www.howtogeek.com/220204/how-to-track-firewall-activity-with-the-windows-firewall-log/
I agree, this is a bit confusing. Is there server firewall On? This may indicate that it is blocking outbound traffic. There is a specific Firewall log as well. You can find it here if it is on;
<sys32>\LogFiles\Firewall\
This link may be helpful
http://www.howtogeek.com/220204/how-to-track-firewall-activity-with-the-windows-firewall-log/
I have made progress, but I am still chasing things down. My first concern is what the dropped/rejected packets are and why they are coming in rather than adjusting the firewall to accommodate them.
The entries in the event log appear to be poorly worded. According to pfirewall.log all of the dropped packets are RECEIVE with the destination IP being 192.168.11.2. The term "Inbound" in the event log entries agrees, but the event log entry seems to use "source address" when it means "local address" and "destination address" when it means "remote address". If I make that translation the event log agrees with pfirewall.log.
The timing also seems to coincide with VPN connections to the LAN. Protocol 47 is GRE which relates to packet encapsulation for a VPN, but I can't understand why the packets would be dropped with no noticeable effect on the VPN.
The entries in the event log appear to be poorly worded. According to pfirewall.log all of the dropped packets are RECEIVE with the destination IP being 192.168.11.2. The term "Inbound" in the event log entries agrees, but the event log entry seems to use "source address" when it means "local address" and "destination address" when it means "remote address". If I make that translation the event log agrees with pfirewall.log.
The timing also seems to coincide with VPN connections to the LAN. Protocol 47 is GRE which relates to packet encapsulation for a VPN, but I can't understand why the packets would be dropped with no noticeable effect on the VPN.
Active 2 days ago
Can you post some of the pfirewall log? Any other logs you are looking at.
Is the firewall on the server blocking outbound traffic at all? or is it permit all?
Is the firewall on the server blocking outbound traffic at all? or is it permit all?
I have not seen any outbound packets blocked in the log. The Windows firewall on the server is set to pass packets that do not match a rule and there are no outbound rules defined.
The only relevant log I have checked is the pfirewall.log (see snippet at end of this post). All dropped packets are RECEIVE. The VPN is from a laptop to the server. The source IP in the log snippet lines is the public IP of my laptop at one end of the VPN -- Laptop <-> VPN (private IP) <-> router <-> Internet (public IP 50.143.170.64) <-> router at server <-> VPN (private IP 192.168.11.2) <-> Server.
--------------------------
#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 77 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 77 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 77 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 269 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 77 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 77 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
--------------------------
The only relevant log I have checked is the pfirewall.log (see snippet at end of this post). All dropped packets are RECEIVE. The VPN is from a laptop to the server. The source IP in the log snippet lines is the public IP of my laptop at one end of the VPN -- Laptop <-> VPN (private IP) <-> router <-> Internet (public IP 50.143.170.64) <-> router at server <-> VPN (private IP 192.168.11.2) <-> Server.
--------------------------
#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 77 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 77 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 77 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 269 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 77 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 77 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
2016-10-17 14:37:50 DROP 47 50.143.170.64 192.168.11.2 - - 81 - - - - - - - RECEIVE
--------------------------
Active 2 days ago
I am not sure, you have exhausted my brain. I suggest requesting attention, a link at the top
Sorry I could not be more helpful :(
Sorry I could not be more helpful :(
Active today
It appears to be a bug in the Filtering System.
Here is a Microsoft Hotfix for it: https://support.microsoft.com/en-us/kb/2654852
Here is an alternate method: http://nmsiam.blogspot.com/2013/02/resolve-issue-with-multiple-event-id.html
As a technical note, while I did not research that part of the issue, the loopback ip should always be 127.0.0.1 so traffic from 192.168.11.2 is foreign (inbound).
Here is a Microsoft Hotfix for it: https://support.microsoft.com/en-us/kb/2654852
Here is an alternate method: http://nmsiam.blogspot.com/2013/02/resolve-issue-with-multiple-event-id.html
As a technical note, while I did not research that part of the issue, the loopback ip should always be 127.0.0.1 so traffic from 192.168.11.2 is foreign (inbound).
I don't think that the hotfix applies. The KB 2654852 (12/23/2011) hotfix is for Windows Server 2008 R2. SBS 2008 is based on Windows Server 2008 SP2, not the later R2. The hotfix shows the file versions of 6.1.760x.xxxxx. The existing version of tcpip.sys is 6.0.6002.19080 (KB 2957189, 6/10/2014).
I don't understand your comment about the loopback IP. This is probably my lack of knowledge. Do you think the dropped packets really originate from 192.168.11.2? I know the event log entries say that is the source, but the pfirewall log entries show it as the destination IP.
I don't understand your comment about the loopback IP. This is probably my lack of knowledge. Do you think the dropped packets really originate from 192.168.11.2? I know the event log entries say that is the source, but the pfirewall log entries show it as the destination IP.
Active today
The article I linked to says to disable the auditing using an elevated CMD window:
auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:disable /failure:disable
auditpol /set /subcategory:"Filtering Platform Connection" /success:disable /failure:disable
TCP/IP traffic which is internal to a PC (antivirus email scanning, for example) uses the 127.0.0.1 address to route that traffic to internal handlers so any valid traffic would be using that ip address, not the external 192.168.11.2.
auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:disable /failure:disable
auditpol /set /subcategory:"Filtering Platform Connection" /success:disable /failure:disable
TCP/IP traffic which is internal to a PC (antivirus email scanning, for example) uses the 127.0.0.1 address to route that traffic to internal handlers so any valid traffic would be using that ip address, not the external 192.168.11.2.
Thanks for your help. I may just be obtuse, but there are three things that I still do not understand:
1) Why do you talk about IP 120.0.0.1? Is there any loopback traffic involved here?
2) Why do you talk about traffic FROM IP 192.168.11.2? Is it based on the event log entry? The verbiage in the event log entries makes no sense to me. The computer at 192.168.11.2 says there is inbound traffic sourced from 192.168.11.2 (itself) and destined to a foreign address 50.143.170.64. How can this be inbound? Wouldn't "inbound" imply that the entry has the two addresses transposed?The firewall log just shows "RECEIVE" traffic to 192.168.11.2. As far as I can tell the two logs are contradictory, the event log makes no sense to me, and neither is talking about traffic internal to a PC. Does the event log entry make sense to you? Is the firewall log wrong? What am I missing?
3) I understand what the auditpol commands do, but I do not understand why it is a safe solution. It sounds similar to disabling a CO detector because the alarms are bothersome. Are these alarms (log entries) known to be meaningless or false for a windows server firewall at default settings?
Thanks for your patience.
1) Why do you talk about IP 120.0.0.1? Is there any loopback traffic involved here?
2) Why do you talk about traffic FROM IP 192.168.11.2? Is it based on the event log entry? The verbiage in the event log entries makes no sense to me. The computer at 192.168.11.2 says there is inbound traffic sourced from 192.168.11.2 (itself) and destined to a foreign address 50.143.170.64. How can this be inbound? Wouldn't "inbound" imply that the entry has the two addresses transposed?The firewall log just shows "RECEIVE" traffic to 192.168.11.2. As far as I can tell the two logs are contradictory, the event log makes no sense to me, and neither is talking about traffic internal to a PC. Does the event log entry make sense to you? Is the firewall log wrong? What am I missing?
3) I understand what the auditpol commands do, but I do not understand why it is a safe solution. It sounds similar to disabling a CO detector because the alarms are bothersome. Are these alarms (log entries) known to be meaningless or false for a windows server firewall at default settings?
Thanks for your patience.
Active today
Read this: http://www.tech-faq.com/127-0-0-1.html
If you are using IIS or just about anybody's "internet security suite" ( Norton, McAfee, CA, etc. ), they create a "handler" (software routine) which uses the loopback adapter on localhost (127.0.0.1) to processes requests made from the server back to the server. As such, any properly installed software making requests to that handler then requests the traffic be from "localhost" or 127.0.0.1. The usage is up to the software specifics and they are interchangeable. The mechanism also works on workstations and is part of the TCP/IP protocol standards.
Using those same standards, having 192.168.11.2 request traffic from 192.168.11.2 is an illegal request as there is no defined mechanism for the network adapter to make requests from itself.
Your problem is not so much a problem; but, rather a bug in server 2008 (and R2) which is causing the events. As such, you can safely ignore them because they are a bug rather than a real problem.
Having done my own homework on the same issue, I would probably ignore the events as being due to a software bug and I, too, have concerns about globally disabling the auditing.
If you are using IIS or just about anybody's "internet security suite" ( Norton, McAfee, CA, etc. ), they create a "handler" (software routine) which uses the loopback adapter on localhost (127.0.0.1) to processes requests made from the server back to the server. As such, any properly installed software making requests to that handler then requests the traffic be from "localhost" or 127.0.0.1. The usage is up to the software specifics and they are interchangeable. The mechanism also works on workstations and is part of the TCP/IP protocol standards.
Using those same standards, having 192.168.11.2 request traffic from 192.168.11.2 is an illegal request as there is no defined mechanism for the network adapter to make requests from itself.
Your problem is not so much a problem; but, rather a bug in server 2008 (and R2) which is causing the events. As such, you can safely ignore them because they are a bug rather than a real problem.
Having done my own homework on the same issue, I would probably ignore the events as being due to a software bug and I, too, have concerns about globally disabling the auditing.
Davis,
Thank you for your help. I have disabled the auditing and marked this at the solution.
I still do not understand the inclusion of the 127.0.0.1 loopback mechanism. Why do you think that there is anything here originating from 192.168.11.2? Why do you think that "192.168.11.2 request(s) traffic from 192.168.11.2"? Is there some inference of other traffic from what is shown in the logs?
Thank you for your help. I have disabled the auditing and marked this at the solution.
I still do not understand the inclusion of the 127.0.0.1 loopback mechanism. Why do you think that there is anything here originating from 192.168.11.2? Why do you think that "192.168.11.2 request(s) traffic from 192.168.11.2"? Is there some inference of other traffic from what is shown in the logs?
Active today
If, for example, you install Norton antivirus with email scanning, it will change all of the ip's used by Outlook to 127.0.0.1 and move the real send/receive details to its own handler which runs as the localhost. Afterwards, every Outlook account setup on that PC will use the localhost handler to actually send and receive email.
Numerous other software packages use the same mechanism to route various types of network traffic to their handler for the data they handle.
Numerous other software packages use the same mechanism to route various types of network traffic to their handler for the data they handle.
I think I understand the use of 127.0.0.1. I have no clue why it might relate to my problem.
What does that have to do with the 5152 and 5157 events posted in the original question? What does that have to do with the pfirewall entries I posted? Am I missing something?
Thanks again.
What does that have to do with the 5152 and 5157 events posted in the original question? What does that have to do with the pfirewall entries I posted? Am I missing something?
Thanks again.
Active today
In TCP/IP networking, there should be no traffic from the NIC's ip address to the same ip. Its against the rules.
True. Bit relevant?
I don't see any "traffic from the NIC's ip address to the same ip". Where do you see it?
I don't see any "traffic from the NIC's ip address to the same ip". Where do you see it?
I must be really dense. I understand that 192.168.11.2 is the NIC. You seem to be talking about traffic from 192.168.11.2 to 192.168.11.2. I don't see any evidence of it. Would you please point it out in this thread. The only traffic I see is between 47 50.143.170.64 and 192.168.11.2.
If traffic from 192.168.11.2 to 192.168.11.2 is not explicitly shown, but can be inferred from what is shown, could you help me make the jump from the shown traffic from 47 50.143.170.64 to 192.168.11.2 to the traffic of which you speak.
This is getting "above and beyond" so please feel free to drop out with my thanks for the auditpol workaround.
Thanks
If traffic from 192.168.11.2 to 192.168.11.2 is not explicitly shown, but can be inferred from what is shown, could you help me make the jump from the shown traffic from 47 50.143.170.64 to 192.168.11.2 to the traffic of which you speak.
This is getting "above and beyond" so please feel free to drop out with my thanks for the auditpol workaround.
Thanks
Featured Post
What's in the eBook?
- Full list of reasons for poor performance
- Ultimate measures to speed things up
- Primary web monitoring types
- KPIs you should be monitoring in order to increase your ROI
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
WARNING:
 If you follow the instructions here, you will wipe out your VTP and VLAN configurations.  Make sure you have backed up your switch!!!
I recently had some issues with a few low-end Cisco routers (RV325) and I opened a case with Cisco TA…
After seeing many questions for JRNL_WRAP_ERROR for replication failure, I thought it would be useful to write this article.
There's a multitude of different network monitoring solutions out there, and you're probably wondering what makes NetCrunch so special.
It's completely agentless, but does let you create an agent, if you desire.
It offers powerful scalability …
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…
Suggested Courses
Earn Certification
HTML5 Specialist - Certification
Free withPremium
Course of the Month10 days, 19 hours left to enroll
Earn Certification
MCSA Configuring Windows 7 Exam 70-680
$49.00$44.10
628 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.