Service optimization question

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

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

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.

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

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.

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

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?

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

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

1 Like

This dial by $dst_ip is working great! Thanks!

3 Likes