G
Greg Stewart
For at least an hour a day, I have been unable to make new outgoing TCP/IP
connections (e.g. web browser, Outlook/Exchange, file shares). Existing
sockets would continue to work (e.g. file shares which were still
connected). This would happen for about an hour a day, after which time
TCP/IP would start working again. A reboot would fix the problem as well.
Needless to say, this has been making things very difficult, especially when
running virtual machines.
Possible culprits such as NIC (changed out) and VPN (ran with and without)
were ruled out. Finally, by scanning the Security log (which is flooded with
Windows Filtering Platform messages!), I was able to find the problem.
In Vista, something called "NatAlePortFilter" running in the System process
installs a port filter with Windows Filtering Platform to block all traffic
on ports 62879 through 64854. Who knows why. Every time an ephemeral port is
used, the port counter is bumped by one. When the ephemeral port counter ran
into this range, TCP/IP applications were unable to bind to any ports. This
was true until the ephemeral port counter eventually incremented out of the
filtered range (around 2000 attempts).
When stopping the Base Filtering Engine service, the following event
appeared in the Security log:
-----
A Windows Filtering Platform filter has been changed.
Subject:
Security ID: SYSTEM
Account Name: NT AUTHORITY\SYSTEM
Process Information:
Process ID: 4
Provider Information:
ID: {00000000-0000-0000-0000-000000000000}
Name: -
Change Information:
Change Type: Delete
Filter Information:
ID: {1CCB4B78-E439-41A4-84BC-C850B2CE71C3}
Name: NatAlePortFilter
Type: Not persistent
Run-Time ID: 65541
Layer Information:
ID: {1247D66D-0B60-4A15-8D44-7155D0F53A0C}
Name: ALE Resource Assignment v4 Layer
Run-Time ID: 36
Callout Information:
ID: {00000000-0000-0000-0000-000000000000}
Name: -
Additional Information:
Weight: 18446744073709551613
Conditions:
Condition ID: {0c1ba1af-5765-453f-af22-a8f791ac775b}
Match value: In range
Condition value: 0xf59f - 0xfd56
-----
0xf59f = 62879
0xfd56 = 64854
The run-time ID of 65541 matched other events indicating that socket bind
operations had been blocked:
-----
The Windows Filtering Platform has blocked a bind to a local port.
Application Information:
Process ID: 5448
Application Name: \device\harddiskvolume1\program files\vmware\vmware
workstation\vmware.exe
Network Information:
Source Address: 127.0.0.1
Source Port: 63179
Protocol: 6
Filter Information:
Filter Run-Time ID: 65541
Layer Name: Resource Assignment
Layer Run-Time ID: 36
-----
This problem affected me because I had been using the MaxUserPort setting in
the Registry to use the widest possible range, up to 65534. This is
documented in several places, e.g.:
http://www.microsoft.com/technet/community/columns/cableguy/cg1205.mspx
This setting carried over from my Windows XP installation on upgrade. I had
originally made the entry long ago because I was developing a TCP/IP
application which allowed the user to set the listening port, and I needed
to make sure the application worked on across the full range. Didn't need it
anymore.
The solution was to delete the Registry value
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\MaxUserPort.
If you need to use the MaxUserPort setting on Vista, be sure to use a
maximum value of 62878.
connections (e.g. web browser, Outlook/Exchange, file shares). Existing
sockets would continue to work (e.g. file shares which were still
connected). This would happen for about an hour a day, after which time
TCP/IP would start working again. A reboot would fix the problem as well.
Needless to say, this has been making things very difficult, especially when
running virtual machines.
Possible culprits such as NIC (changed out) and VPN (ran with and without)
were ruled out. Finally, by scanning the Security log (which is flooded with
Windows Filtering Platform messages!), I was able to find the problem.
In Vista, something called "NatAlePortFilter" running in the System process
installs a port filter with Windows Filtering Platform to block all traffic
on ports 62879 through 64854. Who knows why. Every time an ephemeral port is
used, the port counter is bumped by one. When the ephemeral port counter ran
into this range, TCP/IP applications were unable to bind to any ports. This
was true until the ephemeral port counter eventually incremented out of the
filtered range (around 2000 attempts).
When stopping the Base Filtering Engine service, the following event
appeared in the Security log:
-----
A Windows Filtering Platform filter has been changed.
Subject:
Security ID: SYSTEM
Account Name: NT AUTHORITY\SYSTEM
Process Information:
Process ID: 4
Provider Information:
ID: {00000000-0000-0000-0000-000000000000}
Name: -
Change Information:
Change Type: Delete
Filter Information:
ID: {1CCB4B78-E439-41A4-84BC-C850B2CE71C3}
Name: NatAlePortFilter
Type: Not persistent
Run-Time ID: 65541
Layer Information:
ID: {1247D66D-0B60-4A15-8D44-7155D0F53A0C}
Name: ALE Resource Assignment v4 Layer
Run-Time ID: 36
Callout Information:
ID: {00000000-0000-0000-0000-000000000000}
Name: -
Additional Information:
Weight: 18446744073709551613
Conditions:
Condition ID: {0c1ba1af-5765-453f-af22-a8f791ac775b}
Match value: In range
Condition value: 0xf59f - 0xfd56
-----
0xf59f = 62879
0xfd56 = 64854
The run-time ID of 65541 matched other events indicating that socket bind
operations had been blocked:
-----
The Windows Filtering Platform has blocked a bind to a local port.
Application Information:
Process ID: 5448
Application Name: \device\harddiskvolume1\program files\vmware\vmware
workstation\vmware.exe
Network Information:
Source Address: 127.0.0.1
Source Port: 63179
Protocol: 6
Filter Information:
Filter Run-Time ID: 65541
Layer Name: Resource Assignment
Layer Run-Time ID: 36
-----
This problem affected me because I had been using the MaxUserPort setting in
the Registry to use the widest possible range, up to 65534. This is
documented in several places, e.g.:
http://www.microsoft.com/technet/community/columns/cableguy/cg1205.mspx
This setting carried over from my Windows XP installation on upgrade. I had
originally made the entry long ago because I was developing a TCP/IP
application which allowed the user to set the listening port, and I needed
to make sure the application worked on across the full range. Didn't need it
anymore.
The solution was to delete the Registry value
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\MaxUserPort.
If you need to use the MaxUserPort setting on Vista, be sure to use a
maximum value of 62878.