On vacation, so I have a few seconds to post!
WARNING: Dirty hack ahead.
Here’s a little annoyance that’s been biting at my heels the past few days—how to connect to Team Foundation Server 2010 Source Control over a virtual private network (VPN).
I think it might be a common enough occurrence; people leave the office domain and still need to connect to source control. So they fire up a VPN connection and try to access the server.
In my case, I would experience timeouts. Whether I tried to connect through Visual Studio, or to the “server/tfs/web” website, whatever I tried would simply hang until the operation times out. I wasn’t able to locate any errors in the event log, in the firewall dropped packet log, or in IIS.
While attempting various solutions, I stumbled upon a dirty hack which can help you if you’re suffering the same issue.
What I did was I added a new binding to the Team Foundation Server for port 80. I had to delete the default website in IIS first, since it was already bound to port 80; I could have changed its binding to something other than 80 or specified a domain, but its useless and so into the recycle bin it went. I also didn’t change the default binding for TFS (port 8080) so I didn’t have to tell anybody to update their settings.
So, why did this work?
I. Don’t. Know.
That’s why (at this point) it’s a dirty hack. I guess I could spend an hour or so tracing through the settings within the firewall and IIS to find exactly what is different between a website bound to port 80 and the rules set up for TFS, but I decided to post the hack up instead.
Hope this helped!
