Closed viktor-sedov-gcx closed 5 months ago
This is intended. As long as the STUNner dataplane is deployed into ordinary Kubernetes pods and runs on private IPs (which is The Way For Deploying STUNner), it will return a fairly random private IP in STUN responses (unless you use some ugly Kubernetes [hacks]()).
This is exactly why we do not encourage people to use STUNner as a STUN service. If you really insist on using STUN though, deploy the STUNner dataplane into the host-network namespace. But you'd better not do that, as it fails in many cloud providers' service.
The good news is that it does not matter: STUNner is intended to be used as a TURN Gateway and luckily TURN does not care about the client IP at all.
thank you very much for your quick response and already implementing this feature!
we're using stunner as the backbone for a peer-to-peer networking solution and the docs implied that the headless deployment did exactly what I stated above ( at least for me)
do you have a schedule for when this feature will be available in a release?
We plan to release an RC-3 this or early next month, but there are still some outstanding issues we need to close first. Until then, you can test the latest goodies from the dev
release channel.
Description
When deploying stunner in headless mode (following the example provided) stun resolves the client ip address to some internal kubernetes IP address instead of it's public ip address. Therefore STUN/TURN won't work.
Steps to Reproduce
Expected behavior: The clients IP address would be resolved correctly
Actual behavior: Internal kubernetes IP is being returned
Versions
Helm chart 0.18.0
Info
The issue seems to be the LoadBalancers externalTrafficPolicy. However when switching to "local", it works fine.
Is there any way of configuring the externalTrafficPolicy for the helm chart installation?
Gateway API status
Operator logs