Configuring a ziti network with a completely private router controlplane

Support General Questions
1

We are looking to configure a ziti network with the following constraints:

  • the edge-management API is hosted on a private IP.
  • all controller-router and router-router traffic is always routed over a private network.
  • edge-clients can connect to the controller and edge-routers over public IPs.

I can see that this is mostly possible by using the:

  • web.edge-management section of the controller yaml
  • ctrl section of the controller and router yaml files and the link.listener section of the router yaml
  • edge.api section of the controller yaml and the listeners.binding.edge section of the router yaml.

However, there is one piece that is unclear: the edge.api section of the controller requires a unique address. It also seems that this address is used for the enrollment of both edge-clients and routers. This seems to suggest that routers need to be able to access the edge.api.address to enroll and therefore need to reach the public IP of the controller.

https://openziti.io/docs/reference/configuration/controller#edge

The address setting is unique as it must match the address in a bindPoint for the edge-client API. This is to ensure that responses and data persisted outside the system can reach the controller. An example of this is enrollment JWTs that contain the URL that is used to complete enrollment via the edge client API.

Is this reasoning correct? If so, is there a way around this that would allow us to enroll routers without having to open routes from the routers to the public IP of the controller?

2

Hi @plakdawa, I think I understand your deployment architecture and what you're doing and what you're asking. I must admit, this is not a situation I've ever actually tested myself, so I don't know the answer off the top of my head.

I wouldn't expect routers to use the HTTP client API to enroll, but they might. I could understand why they do that, if they do. At the end of the day, that's what I think the real question is here. Can routers be enrolled without the need to access the client api.

If you can test this easily (because you have the network topology setup), I'd just test it out. I expect you did that already? :slight_smile:

I can think of two ways that should work:

  • open the router to outbound public access only to enroll the router, then close the outbound access
  • enroll the router "somewhere else", then scp the files to the router (the pki and the config file)

I'm 95% sure both of these methods will work but again -- without testing it myself, I do have some room for doubt! :slight_smile:

I'll see if I can either setup a whole test environment myself (which will probably take me a while) or I'll see if i can point someone else here to either test it out or answer definitively. In the meantime, if it were me, I'd probably try to enroll the routers then scp the files since that seems easier to do.

3

Thank you @TheLumberjack.
We will try to test this on our side as well.

4

I confirmed today with @andrew.martinez that the routers do require access to the client API to enroll, but once enrolled don't need access any longer, so both of these options should work for your situation.