I’ve set up OpenZiti locally and it’s working well for most users. However, we’ve noticed that clients on a specific ISP here in Botswana are unable to connect to the overlay network.
Has anyone else run into ISP-related blocking issues like this? Are there recommended steps to work around this—such as changing ports or tweaking how Ziti attempts to traverse the network?
Hi @katlegomoilwa welcome to the community and to OpenZiti!
This isn't something I've encountered myself but some countries are more restrictive than others for sure. A very, very common pattern is to use different ports like @timnis is hinting at.
One VERY common problem is local anti-virus software thinking that strange ports are data exfiltration/attack attempts. We've seen anti-virus software terminate connections on machines in the past. It's also a problem if they have OTHER vpn software install as those can conflict with OpenZiti.
You could try deploying the controller to port 443 and the router to port 80 since those ports generally are allowed.
It's also quite possible that those clients are on an IPv6 only network and maybe there's some misconfiguration where it'll work great on IPv4 but IPv6 fails for "whatever" reason. (probably DNS but it'd be hard to figure out)
Unfortunately in a case like this the only thing you can do is ask that user to look at their logs from their tunneler (or ask them to send you the logs and you look at them). The logs are generally quite useful to figure out 'why' something is goign wrong.
The only other option after that is a packet capture to understand if the traffic is actually getting blocked or sniped by network gear etc.
As a solution you can find a small vps near user location and set up a secondary (slave) controller node and a router.
In some countries ISPs do not allow external tcp connections from home.
Before going there, I would start by trying it just to see if it'd work. But yes, if it works you would use newAddress and migrate users over. They wouldn't need to reenroll if you allow the newAddress functionality to work.
We're encountering an issue with a user in South Africa who is unable to use the OpenZiti network. They are able to enroll their identity successfully, but the connection to the controller only happens once — after that, it fails to reconnect.
The user has multiple VPN clients installed. I assume OpenZiti should work as long as those VPNs are not running — is that correct?
Would appreciate any insights or suggestions on what else could be causing this.
That is generally correct, but it's hard to know for sure to be honest. Often it's necessary for VPN/zero trust overlays to create a network interface. If the address overlaps it definitely can cause problems with intercepted addresses but it wouldn't block controller communications.
From the log snippets you posted I don't see any errors and I see the user successfully enrolled. My guess is that the user is not able to connect to the routers? You need to scan through for errors in the log.
I don't know if I'll be able to give you any good support here on this one, it seems like a tricky problem that is probalby going to be hard to do via internet support forums. It feels like a deeply network-related issue most likely.
No I don't believe it would. zrok at this time expects to own and operate the OpenZiti overlay on its own and really is quite independant from zrok. I don't belive this feature was considered for zrok yet
Will comb through those logs. Is there anything specific that I could look out for when combing through the logs.
On another note, what are the best steps to follow when setting the newAddress? Do we need to have multiple routers setup? The reason I ask is because I'd hate to find users unable to connect because they were offline.
newAddress is a controller setting. You won’t need multiple routers. After "a while", (you need to wait long enough for all your identities to have been online and checked back in with the controller) the identities will all update their identity file with the new address from the controller.
Generally the best way to work around the issue is to probably use port 443 and possibly keep it in the same country but really, that question is probably not one this forum really has much experience with. Hope that helps