Service optimization question

Tunneler Apps Ziti Edge Tunnel
1

Hello, I have a Ziti service optimization question.

Let’s consider a dual cloud scenario where we’d like an overlay between cloud A and cloud B

  • Cloud A will support a ZTNA (Ziti Tunneler Network Access) ziti-edge-tunnel (ZET), and so all traffic destined for Cloud B can be routed to the ZET and tunneled to Cloud B

  • Cloud B, will not easily support a ZTNA model due to some convoluted networking constraints of that particular cloud. In this case, we’d instead consider applying a ZET to each host machine in Cloud B for a ZTHA model

Connectivity would look something like:

ZTNA_CLOUD_A_ZET   <->  ZTHA_CLOUD_B_MACHINE_1_ZET (ipv4: 10.10.1.1)
                   <->  ZTHA_CLOUD_B_MACHINE_2_ZET (ipv4: 10.10.1.2)
                   ...
                   <->  ZTHA_CLOUD_B_MACHINE_N_ZET (ipv4: 10.10.x.y)

With the scenario above, for the intercept service configuration on the Cloud A ZTNA ziti-edge-tunnel machine, I believe if we wanted to do DNS interception, a single Ziti service could handle DNS interception for all N ZTHA machines of Cloud B with some smart use of the dialOptions.identity field.

However, in our case, we want to use purely IP based interception at this time.

It’s clear that we could create N IP interception services for the Cloud A ZTNA ziti-edge-tunnel, with each service intercepting a single IP and forwarding it to the appropriate ZTHA ZET machine identity.

Would there be a better way to do that? Hopefully some way to set up a single intercept service that would accomplish this, analogous to the ability to accomplish this with a single service for the DNS intercept case?

1 Like
2

At first, I was thinking that this was a simple CIDR situation but it’s more complex than that. Maybe @scareything or @dariuszSki have a better idea for this situation. They often have good ideas on how to accomplish things with tunnelers I don’t think of.

1 Like
3

Thanks!

I should also mention the networking CIDRs of Cloud A and Cloud B are non-overlapping, so there is no issue there.

I was thinking that if I could match the intercept IP against a declared identity attribute or tag, for example a key of “ip” with a value which would be populated with a unique static IP of the corresponding machine, then it could be done… But I don’t think that capability exists yet, and maybe isn’t even possible.

4

Currently, you can not dial Cloud A by domain/subdomain or subnet. There is an open issue for ZET to add this capability

1 Like
5

Hi @dariuszSki. Thanks for the feedback. The proposed variables in that ticket are all DNS based, and since we are looking at Ziti services with IP interception only, I’m not seeing how they might help in this case.

For Cloud B machines dialing Cloud A machines:

  • I don’t think there is a problem there for what we’d like to do. We already have this working, at least in a ZTNA to ZTNA bidirectional cloud to cloud model. The dial service is pretty simple and is just a few CIDR intercept ranges that forward into Cloud A’s ZTNA ZET gateway.

For Cloud A machines dialing Cloud B machines:

  • I think we can make this work too, but not with anything less than 1 Ziti intercept service per Cloud B ZTHA host machine, which obviously would have some scalability and management issues if the number of machines in Cloud B grows large.

It would be great if there was a way to make a single Ziti service route to a target identity by matching intercepted IP packets against the IP (or tag containing an IP) of available ZET terminators.

6

It is best practice that you set up 2 separate services and service policies to avoid any possibility of loops especially when you use ZTNA to ZNTA with subnets not so much with dns names.

Yes, right now from B to A you configured what is best option right now.

From A to B, you could set up one service with dialOptions by IP address. but are these IP addresses dynamic or static? The IP address can not change. If you use DHCP, you would need to bind MAC Address to IP for each host

1 Like
7

Oh! So based on your comment, it looks like what I’d like to do is probably possible and I just missed noticing it when looking through various docs.

Yes, the IPs in Cloud B for ZTHA would be static and mac binding shouldn’t be an issue either if I needed to do something like that.

Would you happen to have a code or doc link for a service setup doing dialOptions by IP?

8

Not sure if we have described this in details in our docs yet, but here are sample intercept and host configs with dial and listen options respectively. The ZET identity name in Cloud B would need to match IP Address of the host for this option.

host.v1
{
    "allowedAddresses": [
        "10.10.1.0/24"
    ],
    "allowedPortRanges": [
        {
            "high": 443,
            "low": 443
        }
    ],
    "allowedProtocols": [
        "tcp"
    ],
    "forwardAddress": true,
    "forwardPort": true,
    "forwardProtocol": true,
    "listenOptions": {
        "identity": "$tunneler_id.name"
    }
}

intercept.v1
{
    "addresses": [
        "10.10.1.0/24"
    ],
    "dialOptions": {
        "identity": "$dst_ip"
    },
    "portRanges": [
        {
            "high": 443,
            "low": 443
        }
    ],
    "protocols": [
        "tcp"
    ]
}
3 Likes
9

Thank you very much! I’ll likely play around with this a bit later this week.

1 Like
10

This dial by $dst_ip is working great! Thanks!

3 Likes
11

Hi @johnalotoski,

I am glad it is working for you. I have a follow-up question on your architecture. Currently, it sounds like your test set-up is a simple point to point connection between 2 sites/clouds. I see potential roadblock if you ever expand to multipoint to multipoint service, i.e. A1, A2, B1,B2, etc. If you had more than one site with convoluted networking and can not run ZET on each host, then you would not be able use one service and dial a site by its subnet, i.e. "dialOptions": {"identity": "$dst_subnet"} like you can with using destination ip, i.e. "$dst_ip". You cloud still create a service per site. Potentially, that would not be an issue, since the number of sites could be manageable. I am just trying to a get a feel if that is the case and you would want be championing for a dial by subnet feature. We have already created an issue as indicated earlier in this thread to add ability to dial by "$dst_domain", "$dst_subdomain", etc.

12

Hi @dariuszSki. I don’t think I fully understand what you are proposing. I’m trying to think through what you described above and I get a little stuck. Here’s a few thoughts in response:

  • Our current setup is ZTNA to ZTHA, so I would consider this point to multipoint
  • The currently used dial by $dst_ip is a service for ZTNA point egress to ZTHA multipoint ingress
  • Yes, at some point in the future we may also consider multiple multipoint to multipoint services (ie: ZTHA to ZTHA cloud connectivity, among multiple small clouds, forming a multipoint mesh), or a mix of single (ZTNA) to multipoint connections. But to the extent possible, we’d try to leave it simple and avoid unnecessary complexity.

For consideration of $dst_subnet, I’m not sure how that would work. I’m thinking that would only be applicable to ZTNA gateway machines on ingress, one per subnet. Is that correct? Is there some example service config or pseudo-code that you could share so I better understand what you mean?

13

Yes, I wanted to find out if you would have more sites like Cloud A, i.e. ZTNA. If machines in Cloud B (ZTHA) needed to talk to machines in Clouds A (ZTNA) and C (ZTNA) using one service, the service config would need to have a dial option $dst_subnet.

1 Like
14

For our current use, I think dial by subnet may not work for us because the ZTNA in cloud A is actually receiving traffic for multiple CIDR ranges to forward into cloud A, rather than just receiving traffic for a single subnet.

So while I don’t think we need a dial by dst_subnet feature now, if it becomes available, we might refactor the set up we have to utilize it, or perhaps utilize it in another deployment elsewhere going forward.

Thank you for asking!

15

It makes a lot of sense that it would be list of subnets and not just one for ZTNA. Thank you for a great feedback!

1 Like