I am trying to make networking rules explicit, and I previously used a large IP block workaround to allow access for calls in matrix.
Starting from scratch, STUNner fails to connect peers.
In the logs, the IP address 10.0.0.95 tries to connect to the IP address 10.12.143.127.
From the output of kubectl -n ziti get pods -o wide, I determined that 10.0.0.95 belongs to the ziti-router pod.
I have dug through every command I can think of, but I cannot determine where the IP address 10.12.143.127 is being allocated.
Is there something simple I am missing?
Hi @thedarkula,
I'm not personally sure of what STUNner is or how it's being used. My expectation is that the 10.12.143.127 IP is allocated by a kubernetes cluster. You state "in the logs" -- which logs are you referring to? A controller? A router? It seems like you're saying it's the ziti router. Is there some daemonset running on that node? If it's OpenZiti related, is there anything in the router logs that references the ip?
There doesn't seem to be enough OpenZiti-related information here for me to even offer a guess. I also don't use STUNner and don't know which project it is (i found a few different references when searching the internet).
Pardon, this is coming from a portion of the megathread, here: Helm Port Mappings - #129 by thedarkula
STUNner is a STUN/TURN implementation for kubernetes: GitHub - l7mp/stunner: A Kubernetes media gateway for WebRTC. Contact: info@l7mp.io
As far as the logs I mentioned, those are coming from stunner when trying to initiate a matrix video call through element, but the strange IP address also shows up in the ziti router logs.
I was hoping that it was allocated through some ziti magic that I was unfamiliar with.
Sounds to me like a service is setup then that is requesting to offload that ip. It could be a service that is 'forwarding' whatever IP was received which would make it a bit harder to detect from the OpenZiti configuration perspective. That's what I would suspect.