In addition to running in a swarm configuration, this too is an unusual configuration for openHAB because openHAB advertises itself on the network to it can be discovered and it depends on network broadcasts for automatic discovery of a number of APIs and technologies. So most people run OH using net=host to allow the full range of support for networking capabilities.
All things considered, this is likely going to be a networking problem that is very specific to your particular setup. The number of users here who run OH in Docker is relatively small. The number who run OH in any sort of swarm/kubernetes/openshift type environment can probably be counted on one’s fingers.
The DHCP/DNS problems are completely outside of openHAB and even outside the openHAB Image. That’s all managed by Docker and the arguments you pass to the container when you start it. So I recommend fixing that problem fist as nothing else you mess with will work until you get that fixed. And the solution to that is likely going to be found outside of this forum.
There should be logs, particular logs captured by Docker which is the stdout/stderr from the container starting up which might have some useful information. You haven’t mentioned anything beyond the one warning which, now that you’ve provided some details, at worst is a symptom of other problems and not the root cause of these problems. As far as I’ve followed, and I tend to read at least the subject of all the issues, there has been no changes to anything related to networking in the OH container in quite some time.
That’s not going to fix anything except to make that warning message in openhab.log go away.
I don’t understand this at all.
Either you are using the openHAB Cloud connector or you are not.
If you are using the openHAB Cloud Connector and myopenhab.org then there is nothing your proxies can do to prevent data from leaking to myopenhab.org. It’s the openHAB server itself that initiates the connection to myopenhab.org. And unless you have a really sophisticated firewall that inspects each message exchanged to block only those messages that contain data you don’t want leaked, it’s either going to be all or nothing. Either myopenhab.org will have authenticated access to all your REST API or no access what so ever.
If you are not using the Cloud Connector addon, OH doesn’t communicate with anything on the Internet except to download add-ons (but various addons do, I’m just talking about openHAB core). And if you manually download the addons.kar file and drop it into a folder mounted to addons folder in the container it won’t even connect to the internet for that.
So I don’t see the point here. If you don’t want to leak data to the openHAB Cloud, don’t use it. Problem solved. No need for proxies or fancy network isolation or anything like that. Just don’t install the add-on. If you do want to connect to the openHAB Cloud for remote access, then these intermediate proxies are just going to break that, assuming that OH isn’t already bypassing them entirely.
As far as I can tell you are going to great lengths to solve a problem that doesn’t need to be solved.