We’re changing the IP address range on the firewalls so we’re adding in the new NAT rules in addition to the old ones for a smooth transition.
We started with a web server. The site uses DotNetNuke. We tested the new IP and the server wouldn’t load the page on clients. Luckily we’d kept the old IP and could confirm the site was OK on that. I ran Network Monitor 3.3 on the server (NetMon part of my standard server installation package) and on my client to check things out. Our network engineer started looking at router and firewall traces. I could see traffic coming into TCP 80 but the conversation was short. On the client end I could see the same. I compared with a working conversation on the old IP address and saw that there was a different HTTP status code at the start. The failing server was giving me a 302. In fact, my client was loading localhost instead of the site on the new IP address; that was the 302 code redirect.
I swapped in a default IIS7 site and tested. It worked perfectly. The site bindings were the default norms on the hosted site so it wasn’t that.
I decided to google (I cannot bring my self to say I binged or bonged something, Microsoft) for DotNetNuke redirecting to localhost. Badda-bing! It appears DotNetNuke has it’s own site binding configuration in a SQL table called PortAlias. I added in a row and added in the new IP address to test. That worked perfectly.
I now need to have a long shower after doing developer work 😉