About Me · Send mail to the author(s) E-mail · Twitter

At GROSSWEBER we practice what we preach. We offer trainings for modern software technologies like Behavior Driven Development, Clean Code and Git. Our staff is fluent in a variety of languages, including English.

Feed Icon


Open Source Projects


Blogs of friends

Now playing [?]

Error retrieving information from external service.
Previous Page Page 2 of 3 in the Networking category Next Page

The Web Proxy Auto-Discovery Protocol (WPAD)

Posted in ASP.NET | Networking at Thursday, 01 March 2007 18:01 W. Europe Standard Time

The Web Proxy Auto Discovery Protocol, WPAD for short, simply does what its name implies. An application connecting to the internet may search the local network to find information about proxies and rules which proxy to use when connecting to specific (i.e. local or remote) servers. WPAD leverages a JavaScript file called wpad.dat that is located on a WPAD server. The file itself is retrieved using HTTP. WPAD has been implemented by Netscape in 1996 has not changed much since then.

Publishing WPAD Information

Basically there are two ways for an application to detect the URL to the WPAD server:

  • There is a DHCP option that tells DHCP clients where wpad.dat can be found on a network. By virtue of DHCP this information is only available to DHCP clients. The DHCP option 252 can be used to return an URL to the wpad.dat file, e.g. http://wpad/wpad.dat. Note that URLs specifying non-standard ports are also possible: http://wpad:79/wpad.dat.
  • The other way to retrieve the wpad.dat script is to do a DNS lookup for a host named WPAD and do a HTTP GET for /wpad.dat on this host. The DNS option, however, provides less information to the client application because it only specifies the server and has no way of transmitting information about the HTTP port to the client.

Different Clients

Although WPAD has not become an internet standard yet, both Internet Explorer and Firefox try to acquire the WPAD script if you configure automatic proxy configuration, but in a slightly different way. Internet Explorer prefers DHCP information over DNS whereas Firefox only uses DNS.

Also, Window's built-in WinHTTP Web Proxy Auto-Discovery Service uses either DHCP or DNS to obtain WPAD information.

Possible Problems

Typically, the wpad.dat script is generated and served served by firewalls and proxy servers like Microsoft ISA Server based on the network configuration (you could also write your own custom WPAD script). The WPAD HTTP server, like any other HTTP server,  listens on port 80 for incoming requests. Because this would lead to conflicting ports if you're running another ("workhorse") HTTP server on port 80 of the firewall/proxy, WPAD-enabled firewalls and proxies typically let you choose an alternative port to listen for WPAD requests. All you need to do is to change the DHCP URL accordingly.

But what about the DNS case? As stated above, DNS does not carry port information. A successful DNS lookup for the WPAD host is all to justify a subsequent HTTP request to the server on port 80. But there's not the WPAD server answering, it's the workhorse HTTP server not knowing about a file called wpad.dat: HTTP/404. Bummer.


Of course, you could copy wpad.dat to your "real" workhorse web server. But if the firewall/proxy configuration changes, you would need to copy the file over and over again. Certainly nothing a good network administrator strives for.

  1. One solution I tried was enabling URL rewriting on the workhorse web server and redirect requests for /wpad.dat to the WPAD HTTP server running on the alternative port 79. Although Firefox understands HTTP redirects, they were ignored, presumably for security reasons. Does not work.
  2. proxiing redirect on the server would come in handy, but I couldn't find free ISAPI components doing this. If you like to spend some money, ISAPI_Rewrite may be your choice as it has the RewriteProxy directive. Works, if you are willing to spend money.

Wanting a free solution, I a proxy web site on the workhorse IIS with an ASP.NET IHttpHandler.

  1. Set up your WPAD configuration so that the WPAD HTTP server listens on a port that is not used by other applications.
  2. Create a host (A) DNS entry for the WPAD host, pointing to the IP address of your proxy/firewall that also hosts IIS.
  3. Set up option 252 on your DHCP server giving it a value of http://wpad/wpad.dat. The port can be omitted as we're proxiing requests to the real WPAD server.
  4. Create a new IIS web site on port 80, specify host headers wpad and wpad.your-domain. The web site should run as an ASP.NET 2.0 application.
  5. Add a script mapping for .dat files so that they are processed by %windir%\\framework\v2.0.50727\aspnet_isapi.dll. Be sure to uncheck the "Check that file exists" option.
  6. Put these files in the web site's root folder, allow NTFS read access for IUSR_<Machine Name> and NETWORK SERVICE.
  7. Open web.config with a text editor and adjust the URL to the real WPAD server in the only key of /configuration/appSettings.
  8. Test your WPAD configuration with wget:
    rem Test the real WPAD server, this is what the proxy web site uses.
    wget http://wpad:<alternative port>/wpad.dat
    rem Test the proxy WPAD server, this is what clients use.
    wget http://wpad/wpad.dat
  9. Test with Internet Explorer, Firefox and other clients. Take a look at the IIS log files if requests were served with HTTP status code 200.

Now Playing [?]: Fujiya & Miyagi – Cassettesingle

Copying And Pasting Files Over A Remote Desktop Connection

Posted in Networking at Tuesday, 12 December 2006 20:52 W. Europe Standard Time

Ever wondered why Ctrl+C of a file on the Terminal Server and a subsequent Ctrl+V on the local machine does not work? Torsten and I had a little chat some weeks ago discussing this particular feature. It worked for me on several servers, but not for him. I was a little clueless why this happened, but some days ago Torsten provided a solution: You need to check the "connect local drives" checkbox. This should have been obvious, but I didn't think of this feature being used by the clipboard to copy files over the RDP connection.

Remote Desktop Connection Settings

By the way, Microsoft released a new version of Microsoft's Remote Desktop Client that supports Terminal Services Gateways, 32-bit color, Clear Type font smoothing and a whole lot of other stuff. Unfortunately it's only available in English and thus won't install on my German Windows XP.

Supporting Users Over The Internet: Overcoming Firewalled Networks

Posted in Networking at Tuesday, 21 November 2006 16:37 W. Europe Standard Time

I'm doing quite a bit of computer support for a couple of friends. Some of them come over to my place when they need my help with some installation, driver or have a software problem. Recently, Silke, one of my bigger support "customers" moved to the United States and bought a new laptop because they're way cheaper there. We needed a whole day installing Windows XP, drivers and software. IM and Skype on a second machine were used for communication and obviously it's been quite onerous.

Unfortunately it's not possible to dial in to our home network over VPN because some router between Silke's and our server doesn't route GRE packets. I suspect it's the WLAN access point Silke has no control over. Because she's not allowed to administer it, creating a port mapping for Remote Desktop is also not an option. Windows' own Remote Assistance doesn't work over firewalled/NATed networks either.

I came up with a much simpler solution leveraging the power of SSH. SSH supports tunneling TCP connections and is very likely to be allowed by a corporate firewall. If a user logs on remotely via SSH and sets up port tunneling, he/she is either able to access a previously blocked remote port over a local connection (local → remote, my term) or the user's machine can be contacted from the SSH server over a remote → local tunnel (again, my term). The image below depicts both types of tunnels. There's a third tunnel type, namely dynamic SOCKS forwarding comparable to local → remote tunnels, but it's of no interest here.

SSH Tunnels

As the "support engineer" all you need to do is set up a SSH server either on your local machine (and create a port mapping on your firewall/router) or on the firewall/router itself. There are couple of free SSH servers like freeSSHd. It has some limitations, but is perfectly suitable for the given task. After you've set up the server, created users and enabled tunneling, point your "support customer" to the PuTTY download page and let him download the Plink executable. Direct him to start Plink as follows (command line reference):

plink -ssh -C -R 50000: <username>@<SSH server address>

This will establish an encrypted SSH connection to your SSH server and set up a remote → local tunnel. The server will listen on port 50000 and forward all traffic to port 3389 (Remote Desktop) on the user's machine. You can then create a new Remote Desktop session on the server connecting to

Unfortunately this cannot be used to work around the aforementioned problems with Remote Assistance, but in the end will provide a way of accessing otherwise protected machines over the internet. Of course, this will not only work with RDP connections but with all other types of servers.

DirectUpdate and Windows Security Policy

Posted in Tools and Software | Networking at Saturday, 05 August 2006 14:32 W. Europe Daylight Time

We are working with a DSL connection here and offer some services to the outside world, for example Remote Desktop login to each roommate's workstation. This web site is also served through this DSL connection. That's what Bill Gates must have meant when he talked about the vision of "information on your fingertips"¹.

Simple consumer DSL line like ours have an annoying "feature": The provider disconnects the line every 24 hours to force redialing the connection and thus allowing him to assign a new public IP address. This prevents offering large scale services and forces businesses to buy a more expensive connection package with static public IPs. Because nobody on the internet knowns our current IP address (as it changes every day) we use a Dynamic DNS service to update the IP addresses of our domains ( and some others).

There are Dynamic DNS clients that monitor the connection and issue an IP update to Dynamic DNS service like DynDNS. Current routers even come with such a client. I was trying the demo version of DirectUpdate to see how it works.


This is the DirectUpdate management screen. Notice that the window is not resizable by means of the standard minimize, maximize and restore buttons (Minimize, Maximize and Restore Buttons). What happens if you log in with a resolution of 640x480 and the window floats around off-screen? You're lost. One might say that this a very uncommon case today as CRTs with this resolution are pretty much dead, but we had such a display connected to the old server.

After installing DirectUpdate everything worked fine, DynDNS updates were issued and the service ran reliably. However, the security event log filled up with strange "Audit Policy Change" events. These events occurred at random times. Each time the Logon/Logoff and Account Logon audit, which forces Windows to log successful and failed logon attempts to the security event log, was completely disabled. All other audit settings remained untouched.

Event ID: 612
Audit Policy Change:
New Policy:
Success Failure
  -  - Logon/Logoff
  -  - Object Access
  -  - Privilege Use
  -  - Account Management
  -  - Policy Change
  -  + System
  -  - Detailed Tracking
  -  - Directory Service Access
  -  - Account Logon
Changed By:
User Name: ARWEN$
Domain Name: WG
Logon ID: (0x0,0x3E7)

I've reset the Windows Audit Policy to log Logon/Logoff and Account Logon events each time a 612 event was logged but after some hours the policy change would occur again. Tracing the system events using Filemon, Regmon and Process Explorer gave no clue about the source of the error. Time to open a support case using a voucher that Torsten kindly let me use.

The Microsoft support clerk recommended disabling all non-Microsoft services (there were about four) on the system. Lo and behold, the Audit Policy Change events didn't appear again. After gradually re-enabling these services I found that DirectUpdate was the source of the policy changes. The next step was to prevent DirectUpdate from issuing policy change requests. As there's no setting on the UI regarding policy, I had to dig deeper.

DirectUpdate installs as a Windows service. Because it appears easier for the developers if DirectUpdate the service runs under the SYSTEM account, the most powerful account in Windows that's allowed to perform every operation. Why should a service that's sole purpose is to monitor IPs and sending HTTP requests run in such an unrestricted environment? I changed the service to run under the Network Service account, a restricted user for the very purpose of running services under it:

The new Network Service account [...] has a greatly reduced privilege level on the server itself and, therefore, does not have local administrator privileges.
  1. Open the Services MMC Snap-In by running services.msc
  2. Search for the "DirectUpdate engine" service
  3. Right-click, select Properties and open the Logon tab
  4. Enable the This account radio button, then Browse and enter NetworkService or browse for the localized Network Service name
    DirectUpdate Logon Settings
  5. Click OK
  6. Grant the following rights to the Network Service account
    • Change in the DirectUpdate log file folder
    • Change in C:\Program Files\DirectUpdate\Dump\
  7. Restart the service

This did the trick. DirectUpdate runs peacefully and the Security Policy doesn't get changed anymore. So, thanks again Torsten for allowing me to contact Microsoft Support on the issue!

¹ Phew, this is the ugliest Microsoft site I've ever seen.

Now playing: Yonderboi - Splendid Isolation - Motor

Alive and Kicking (Again)

Posted in Geek Mode | Networking | Tools and Software at Friday, 23 June 2006 20:59 W. Europe Daylight Time

Last week, on June 15th at 3 A.M. our server decided that it is time to retire the hard drive carrying the operating system and let it issue nothing more than the well-known sound of crashed heads. Goodbye Gandalf, you modest fellow who served our purposes well since December 2003.

We're currently running on a hastily set up backup system. That is, our WLAN access point has become the primary DSL router and Marci reinstalled the server on a 40 GB hard disk uselessly mounted in an even older server machine. Of course, the interim solution is not as well configured as one might expect: applications and services are missing, shares are non-existent, IIS MIME types are not set, ... the list goes on.

The rest of the hardware we've been running on will be taken out of service as well because a Dual Celeron 466 is just not what we need (anymore). We've already ordered a new server, a Dell PowerEdge SC430. Apparently, it's the smallest server manufactured by Dell, but a Pentium D 820 (Dual Core 2,8 GHz) with 1,5 GB of ECC'd RAM and a 80 GB RAID 1 should be enough for our demands.

Dell PowerEdge SC430

nLite LogoI've already finished preparing and testing the Windows Server 2003 R2 installation CD that was customized using nLite. It's a graphical tool that creates an ISO image based on the original installation media. Speaking of customization, you can create a fully unattended setup including device drivers, service packs and hotfixes. There is a vast amount of other options to pre-configure the user experience, add hidden or remove unwanted functionality. For instance, Windows Media Player is not really needed on a server machine, whereas IIS should be installed by default. Pretty neat!

Let's see if the machine behaves well until the new PowerEdge (named Arwen) comes to life!

Now playing: Air - Moon Safari - Remember

Previous Page Page 2 of 3 in the Networking category Next Page