The problem you've described is an example of the Traveling Salesman Problem. This is a famous problem because it's an example of the kind of problem that can't be solved efficiently with any known algorithm. That is, you can't come up with the absolutely best answer effiently, because the number of possible solutions increases exponentially. The number of possible solutions is n!, which means 5 x 4 x 3 x 2 x 1, where n=5. Not a big deal in this case, when you are trying to solve for 5 cities, (120 combinations) but even getting up only as far as 10 raises the number of possible combos to 3,628,800. Once you get to 100 nodes, you're counting your CPU time in years. This is why the "Fastest Roundtrip Solver" listed above only guarantees "optimal" solutions up to 15 points.
Having said all that, it can't be solved efficiently, (a "solution" in this case means the one correct answer, as Gebweb says, the "optimal" answer) but you can come up with a pretty good answer, as long as you don't get hung up on it being the absolute provably best one. If you look in the code, you'll notice that Gebweb's Fastest Roundtrip page switches to an "Ant Colony Optimization" (not technically an algorithm, but rather a heuristic) once you get past 15 points. No sense in my repeating what he says better, look at his behind-the-scenes page.
Anyway, Daniel is right, this should do what you want, but I couldn't help but spill a bit about the fact this is a more complex problem than it seems.