S h o r t S t o r i e s

// Tales from software development

The answer isn't always obvious until you know what it is

leave a comment »

“It is perfectly true, as philosophers say, that life must be understood backwards. But they forget the other proposition, that it must be lived forwards. And if one thinks over that proposition it becomes more and more evident that life can never really understood in time simply because at no particular moment can I find the necessary resting place from which to understand it—backwards.”

Søren Kierkegaard

Once you know the cause of a problem it’s often so obvious that you can’t understand why you didn’t see it immediately. Hindsight is a wonderful thing and here’s a good example…

Having given up on WebDAV to transfer the backups from the desktop PC I use at work to a remote WAN location, I wrote a WCF service to provide FTP-like functionality using HTTP on port 80. I installed and configured the service on a server running at home and then tested the client application on various machines to ensure that I could connect to the service from any environment. This is what I found:

  • Computers on my home LAN – all connected and authenticated successfully.
  • Desktop at work (WAN) – connected and authenticated successfully
  • Laptop connected to the internet via 3G mobile data service – connected but failed authentication.

I investigated the problem with the laptop and found that if I established a VPN connection to my employer’s domain (I was using a domain login) then I could successfully connect to my WCF service and authenticate. If I dropped the VPN connection then the laptop would fail to connect and authenticate.

I should explain at this point that I work for a services company. So I connect to my employer’s network via VPN from time to time but I’m actually based at a client site most of the time using a desktop workstation, that they provide, on their LAN with internet access.

I spent a couple of days researching the problem having convinced myself that authentication was failing because a I was using a domain login on a machine that was disconnected from the domain. Maybe this was some type of anti-spoofing mechanism in Windows ? I asked a few friends and colleagues but no one had come across this problem.

A few days later I logged into the management UI of my home router/modem to tighten up the security on the HTTP/80 forwarding that I’d configured for the WCF service and saw that I’d already implemented what I was about to configure – the forwarding rule was already configured to filter on a WAN address range. I’d entered a range that would cover the block of addresses used at my workplace so that the service could only be called from my desktop at work.

However, because I didn’t know the exact range of addresses, I’d made the range a bit wider than what was probably required. Just wide enough, in fact, to also include my employer’s internet address range too. So, the reason I could connect to the WCF service when I was connected to the VPN was nothing to do with authentication succeeding when I was connected to the domain, it was simply that the VPN was acting as a gateway and this address was not being blocked by my router/modem.

As soon as I saw the WAN address range on the HTTP/80 forwarding rule it was obvious why I hadn’t been able to connect from my laptop. It’s a shame it wasn’t obvious when I first experienced the symptoms.


Written by Sea Monkey

November 14, 2008 at 8:00 pm

Posted in Debugging

Tagged with

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: