Strange network setup, i must say... why would you need mutiple networks for that purpose?

Anyway:
Normally, a slave has a public and/or a private IP. If both are present, the public IP takes precedence over the private IP. So do you mean you have multiple private IPs or what?
Please specify a real life-example so I can understand what you mean.

BTW: There is no jclouds-jenkins 2.19.3. The latest is 2.11?!

Another remark/question: In jclouds, you can specify network Ids, but AFAIK, the ordering of the actual IPs of a spawned node, reported by openstack is unspecified.
Is it that what you mean by 75% of the time it "picks" the wrong IP?

Sorry yes, 2.11 (corrected). Got confused on my versions since we have been upgrading quite a few things.

I agree our network setup is a bit non-standard. It's this way so we have a clear distinction between an actual private network that we use to communicate with other servers, and a "public" network for all non-LAN access. It is less important for Jenkins but for production, it means we are not mixing any customer traffic with private support services and, thus, we can more easily trust the private network. The other reason it is like this is, in part, because we don't have enough IPv4 address to give every VM a public IP but want to avoid most of the trainwreck that is NATing to one network (the "public"). Our private cloud provider does not yet support IPv6 addresses directly to VMs. If we could do that, we would likely have a true public network (with actual public IPs assigned to VMs) and a true private network (with a private v4 and unique-local v6).

From the standpoint of JClouds, it's seeing two networks which look to be private since that's true in the specific sense. But in practice, the Jenkins master can only see these servers over the network we consider as actually private.

For some concrete numbers, we have two networks, "inside" and "outside" that both have private IPs (again, the NAT monster for IPv4). Sometimes Jenkins tries to SSH to the "outside" network when it should always SSH into the inside. I had thought I could beat this with cloud-init but wasn't really able to come up with much there. The networks should always be the same (eth0 = outside, eth1 = inside) though.

Finally, yes 75% of the time it seemed to pick the wrong IP. Although more recent test show it's more like 50/50. If Jenkins tried all IPs that would eventually fix it but it didn't seem like it was doing that (if it can't connect to the outside IP, it will continue to try the outside IP rather than trying the other IP).

Ok, so since this is your own setup, you do know the expected IP ranges in Advance, right? E.g. lets say "internal" is 192.168.0.0/24 and "external" is 10.1.1.0/24 and when you display a machine's Details, you see it's Addresses sometimes like

Private:
192.168.0.123 10.1.1.19
Public:
none

and sometimes like

Private:
10.1.1.19 192.168.0.123
Public:
none

Since Jenkins always chooses the first of multiple Addresses in the same class it would choose 192.168.1.0.123 in the first case and 10.1.1.19 in the second case.

Spec

1. For you, It would be sufficient, if you could specify the correct network by it's IP/prefix and Jenkins would then match that against the multiple Addresses of a newly created Node.
2. You do not use any initScript functionality and do use a preconfigured jenkins account on the individual nodes. (because that would be done by a different ssh from within jclouds - which I'm afraid can not be influenced from within the jclouds plugin)

Is that correct?

On last question:
Did you specify the two ID's of the networks in the advanced settings of the template or are those networks specified as defaults in your openstack installation?
I'm asking, because there might be a chance, that if the IDs are specified in the template, the order of the assigned IP addresses might be constant and in the same order as the specified network IDs.