How to: access a project via dynamic DNS?

[Mordachai]

This is related to this topic: http://support.sourcegear.com/viewtopic.php?f=5&t=21631

We have a server on our LAN, called 'build-server'

It is inside of a NAT firewall, and has no external address except via dynamic DNS (i.e. [anything].cimex.dns2go.com routes to our NAT router's external IP address, which changes over time).

Our project files name 'build-server' as the host to bind to. However, I don't know how to set my home machine to route 'build-server' to 'build-server.cimex.dns2go.com'?

I can modify \Windows\System32\drivers\etc\hosts file to bind 'build-server' to a specific IP... but this only works for a few hours sometimes (like the first time I tried it). Not adequate.

If there is a bind a name to a fixed name, such as 'build-server' -> 'build-server.cimex.dns2go.com', that would be ideal, since that would actually properly resolve the name.

I cannot possibly bind to that name within our LAN. NAT doesn't work to try to resolve to an external name that routes back again. At least... not in my past experiences.

Is there a utility or suggestion for a mechanism that would accomplish this (or do you know of a way to make build-server.cimex.dns2go.com route properly within the LAN so I can build all of our projects to that?)

[Beth]

I cannot possibly bind to that name within our LAN. NAT doesn't work to try to resolve to an external name that routes back again. At least... not in my past experiences.

I don't think this is necessarily the case. Have a user that is internal pull up a browser and try to go to http://<fully qualified domain name>/vaultservice/vaultweb. For example, if I used the FQDN you gave in your post, the URL would look like http://build-server.cimex.dns2go.com/va ... e/vaultweb. If they can reach that from a browser, then it should work in the bindings.

[Mordachai]

I'll give it a shot....

...Nope. Doesn't work. I've tried this with other services, and trying to make a connection to an external IP doesn't make sense.

Internally, build-server is an unroutable IP - something like 192.168.1.52. Externally, build-server.cimex.dns2go.com is a routable IP - such as 71.127.14.17.

Pinging 71.127.14.17 is routed to the gateway which routes it to the internet which tries to route it back to the gateway which fails. I've never seen this work on any NAT based LAN I've ever worked on. I just tried it, and got failures for a response.

Executing a direct attempt to http://build-server.cimex.dns2go.com in my browser gives me a connection to the router itself, rather than being port-forwarded to the real, internal server. I'm not aware of a way around this?

[NOTE: I am currently just updating my localhost file at home each time the dynamic IP changes (seems to be weekly, on Saturday/Sunday transition). So that's livable, for sure. But it would be nice if the bindings could be externalized (localized to the end-point, rather than stored globally for the project itself), or locally overridden without disturbing the internal generic bindings, such that offsite workers could configure an override binding and in-building workers could leave their workstations as the default project-specified-binding.]

[Beth]

Unfortunately, I don't have an answer for how to do your routing. I've seen other customers be able to use external IPs or external addresses both internally and externally.

I've put in a feature request to allow different server bindings on the same project. I'm not sure if VS would allow this though.


F: 16831

[Mordachai]

I could do a static mapping in localhost for all machines at the office, and assign the vault server a static IP, such that trying to invoke its external name (build-server.cimex.dns2go.com) would, internally at each machine, resolve to an internal, non-routable IP address of the host.

From there, the external clients would be okay, because everyone would be bound to the external name

Just means having to maintain all workstations that want to use Vault within the office, which is less than ideal, but not the worst situation.

I would guess that your other customers who were successful at using the external name w/o having to do the above localhost tricks were able to because their actual server had a mappable IP address - directly accessible from the internet, rather than behind a NAT router...

But if we can get this as a generic feature - where the local machine was in charge of how to map a given server - that would be a useful feature to us.

BR