We run several instances of GeoServer on Windows servers, using the Jetty web server included in the GeoServer for Windows installer. By default this results in a service running on an address like http://123.345.67.321:8080/geoserver

Recently we have found that some external users cannot see the mapping, and it appears something at their end is blocking requests to our address. We are not sure exactly what is being blocked, but a solution was needed. We need to run these services over port 80, and with a friendly domain name instead of an i.p. address.

However we also run IIS web sites on the same servers, and while it is possible to reconfigure the port used for Jetty, I’m pretty sure it would not be possible to have both IIS and Jetty handling requests on the same port.

The solution was to configure an IIS web site to route traffic through to GeoServer on its old address. I thought it worth making some notes of the procedure.

1. This required installing two extensions to IIS 7.5:
   URL Rewrite: http://www.iis.net/download/URLRewrite
   Application Request Routing: http://www.iis.net/download/ApplicationRequestRouting
2. I created a new web site in IIS, on the same server as the GeoServer instance. I added a new subdomain, that I had created earlier, as a binding (host header) for the site; this will be the new external address for our GeoServer service. Let’s say it’s mygeoserver.exegesis.com or something.
3. In IIS, select the site, and double-click the “URL Rewrite” icon which should be visible in the IIS section of the Features View.
4. Right-click in the “Inbound rules” area, and “Add Rule(s)…”.
5. Choose “Reverse Proxy” and click OK.
6. Enter the address of the GeoServer instance. Using my hypothetical server above, I would enter 123.345.67.321:8080/geoserver. Click OK.  The “geoserver” bit was not strictly necessary, but including this shortens the final addresses a bit.
7. Test.  For any original request to GeoServer, simply replace http://123.345.67.321:8080/geoserver with mygeoserver.exegesis.com (or whatever), and you should get the same response. For external users, traffic is now going over port 80, and there are no server i.p. addresses to get grumpy about.

For us, it means our clients can now see their map of fly-tipping incidents in the Valleys again:

This also has a number of other benefits that I’ve not fully thought through yet… for example, it means we can use IIS i.p. filtering to restrict access to our GeoServer mapping where needed, we can analyze IIS logs, etc.