Turncat does not include SNI header when using TURN/TLS
Closed this issue · 5 comments
Description
I am trying to use Stunner (and test it with provided Turncat tool) via a standard ingress controller using a TLS passthrough config.
In particular, I setup a Stunner gateway with a TURN/TLS listener. Then I setup my ingress (I am using contour) on a subdomain to do TLS passthrough. The ingress controller will then examine the SNI header on the TLS Client Hello Package to choose the target service and then forwards all packets there. No termination or decryption is occuring at the ingress controller.
Thus, I am thinking I should be able to use this to establish a turn connection.
However, testing with Turncat (iperf-example from the docs), it does not work, but rather give this EOF error:
turncat --verbose udp://127.0.0.1:5034 "turn://user:pass@turn.my.domain:443?transport=tls" udp://10.34.207.214:5001
08:41:08.280854 main.go:81: turncat-cli DEBUG: Reading STUNner config from URI "turn://user:pass@turn.my.domain:443?transport=tls"
08:41:12.095143 main.go:88: turncat-cli DEBUG: Generating STUNner authentication client
08:41:12.095182 main.go:95: turncat-cli DEBUG: Generating STUNner URI
08:41:12.095210 main.go:102: turncat-cli DEBUG: Starting turncat with STUNner URI: turns://turn.my.domain:443?transport=tcp
08:41:12.095369 turncat.go:186: turncat INFO: Turncat client listening on udp://127.0.0.1:5034, TURN server: turns://turn.my.domain:443?transport=tcp, peer: udp:10.34.207.214:5001
08:41:12.095385 main.go:118: turncat-cli DEBUG: Entering main loop
08:41:12.096109 turncat.go:227: turncat DEBUG: new connection from client 127.0.0.1:60463
08:41:12.248694 turncat.go:463: turncat WARNING: relay setup failed for client udp:127.0.0.1:60463: cannot allocate TURN/TLS socket for client udp:127.0.0.1:60463: EOF
^C09:01:45.683520 turncat.go:196: turncat INFO: closing Turncat
When I do the same, but instead target directly the public IP of the stunner gateway loadbalancer, it does work as expected.
I then tried to trace the problem by captureing the relevant packetes and it seems to me that turncat fails to include a SNI header in its TLS packets. Therefor the ingresscontroller has no info as to where the packets should be forwarded and just drops the connection resulting in the observed error. Could this be possible?
I appreciate any hints.
Steps to Reproduce
- setup a stunnergatway with TURN/TSL listener
- setup ingress to do TLS passthrough
- Test with Turncat using the subdomain name configured in the ingress controller
Expected behavior: [What you expected to happen]
- estalish the connection via turn
Actual behavior: [What actually happened]
- connection is dropped and a EOF error is shown
Versions
[Which version of STUNner you are using]
0.18.0
Info
[Please copy-paste the output of the below commands and make sure to remove all sensitive information, like usernames, passwords, IP addresses, etc.]
Gateway API status
[Output of kubectl get gateways,gatewayconfigs,gatewayclasses,udproutes.stunner.l7mp.io --all-namespaces -o yaml]
Operator logs
[Output of kubectl -n stunner-system logs $(kubectl get pods -l control-plane=stunner-gateway-operator-controller-manager --all-namespaces -o jsonpath='{.items[0].metadata.name}')]
We have ended up taking this as a feature request and implemented it right away. You can now use --sni=my-server-name on the turncat command line to set the SNI. This should be useful for testing.
Closing this as fixed now in cleaning up open issues for the imminent release of v1, but I'd like to ask you to answer a quick question before abandoning this issue: are you planning to set the SNI for testing only, or do you actually intend to use turncat in production?
wow thanks will check that out!.
I currently want to test with turncat as the most simple scenario and to see wether routing packets through a standard reverse proxy is feasible.
production workload would be webrtc, and I know this is far from ideal. onlyunfortunately it seems very difficult to open up even a single udp port in our firewalls. with turn/tls I would be able to reuse existing pathways.
I also tested with your fork of the mediasoup-demo. this does not currently support the TLS transport at all as it seems.
would you be able to add the option for tls transport (while SNI would be required as well) to the demo?
I also tested with your fork of the mediasoup-demo. this does not currently support the TLS transport at all as it seems.
would you be able to add the option for tls transport (while SNI would be required as well) to the demo?
Currently no resources, but we're accepting PRs!
Currently no resources, but we're accepting PRs!
fair enough!
would it be as simple as constructing a turns:// url instead of a turn://? I might be able to add that.