Edge router behavior with ziti-edge-tunnel

Support General Questions
1

Hi community,

In my lab, where I’m setting up a Ziti overlay network, I ran into an issue with the connection between the ziti-edge-tunnels and the edge routers. I think I fixed it? but I’d like to confirm whether my understanding of what happened is correct, so that’s why I’m posting here.

I have the ziti-router package installed in a Debian 12 container. I followed the Linux Deployment guide, connected it to the controller successfully, and created a simple service to test the Ziti network. Everything was working fine.

Later, I decided to rename the containers running my Ziti routers. I just wanted a 1:1 relationship between the container name and the router identity. For example, since the container was named something like “sv-cloud”, I wanted to rename it to something like “edge-router-1”.

After renaming the containers and running ziti-edge-tunnel, I started seeing log entries like “edge-router-1 connected” followed by “edge-router-1 disconnected”, along with EOF and “bad file descriptor” errors. It kept trying to reconnect and failing over and over again. Everything had worked the day before, and the only thing I changed was the container names. So I thought: maybe somewhere in the configuration the old hostname is still being used, and now there’s a mismatch?

I rolled back the changes and restored the original container names, and everything worked again.

Looking at the edge router config, under the “edge” section, specifically in “sans”, I saw the container’s hostname listed. It looked something like this:

  • localhost

  • dns domain of the edge router

  • sv-cloud

So my question is: could the issue have been caused by changing the container hostname while the router was configured with the old one in the SANs? Would that cause the connection to be closed due to a TLS/authentication mismatch? Or am I missing something else, and now it works just because I restated everything and somehow I haven’t run into the same error again?

Thanks! :slight_smile:

2

Hi @martoAs, it's no coincidence that changing the container's hostname could cause problems but realistically that sounds to me like a separate problem. That sounds to me the 'advertised' addresses is no longer valid because the hostname changed.

OpenZiti controllers and routers will inform other components of the location of the component via an "advertised address". If that's misconfigured (which is my guess) the behavior you explain would make sense.

I would check the configuration files looking for "advertise". In the controller it's probably "advertisedAddress" and in the router it'll be "advertise" in both the link and edge sections but also look out for the control plane endpoint in there.

I suspect that'll be your issue.

If you use a FQDN instead of 'the hostname' you should be able to change that underlying IP or hostname without any issues.