Recently I received a call from a customer who was trying to resolve an issue where all web proxy clients that were configured to use Web Proxy Auto Discovery (WPAD) with DNS suddenly stopped working. We began troubleshooting by confirming that the hostname WPAD resolved to the internal IP address of the Forefront TMG firewall, which it did correctly. Next we used a telnet client to confirm that the TMG firewall was listening on TCP port 80 (used by TMG for DNS WPAD clients) and indeed it was responsive. A scan of the event logs on the firewall turned up the following warning message:
“The Web Proxy filter failed to bind its socket to 172.16.1.253 port 80. This may have been caused by another service that is already using the same port or by a network adapter that is not functional. To resolve this issue, restart the Microsoft Firewall service. The error code specified in the data area of the event properties indicates the cause of the failure.”
Something was listening on TCP port 80, so we opened a command prompt and entered the following command in order to determine which process was listening on this port:
netstat –ano | findstr :80
Netstat was reporting that TCP port 80 was in a listening state and bound to the IP address 172.16.1.253. The process using this port was the System process (PID 4). This is unexpected, because the Forefront TMG web proxy service (wspsrv.exe) should be bound and listening on this port. Clearly this was a web service hijacking this port, so to find out more we entered the following command at a command prompt:
netsh http show servicestate
The output of this command revealed a valuable clue. Notice the registered URL below…
As it turns out, this customer had attempted to change the SQL Reporting Services Web Service URL. By assigning the Forefront TMG firewall’s internal IP address and changing the port to 80 in the Reporting Service Configuration Manager, this caused a conflict with the Forefront TMG web proxy filter, which requires TCP port 80 to provide WPAD for DNS.
To resolve the issue, the administrator chose a TCP port other than 80 and restarted the system.
On a Forefront Threat Management Gateway (TMG) 2010 firewall you may encounter a Configuration Error alert like this:
The alert description states:
“The routing table for the network adapter Internal includes IP address ranges that are not defined in the array-level network Internal, to which it is bound. As a result, packets arriving at this network adapter from the IP address ranges listed below or sent to these IP address ranges via this network adapter will be dropped as spoofed. To resolve this issue, add the missing IP address ranges to the array network.
The following IP address ranges will be dropped as spoofed:
This alert is the result of the Forefront TMG firewall’s routing table and network definition being out of sync with each other. In this example, the routing table looks like this:
However, the Forefront TMG Internal network definition looks like this:
As you can see, the Forefront TMG firewall is configured with an Internal network IP address range of 172.16.1.0/24. However, the routing table contains additional static routes that also make the 172.16.2.0/24 and 172.16.3.0/24 networks reachable.
To resolve this issue, highlight the Networking node in the navigation tree, select the Networks tab in the center window, then highlight the network that corresponds to the IP address range contained in the alert. In our example the address range 172.16.2.0-172.16.3.255 also belongs to the Internal network. Right-click the Internal network and choose properties, choose the Addresses tab, then remove all address ranges previously configured. Next, choose Add Adapter and choose the network adapter for this network.
Using this method the IP address range for this network is built using the routing table for the network interface. This is the preferred method for defining IP address ranges for Forefront TMG networks. Save the changes and apply the configuration.
For more information on configuring network interfaces for Forefront TMG 2010 firewalls, please refer to Jason Jones’ excellent documentation on the subject here: