Solved Understanding STUN???
-
I am trying to understand what STUN does. I have some UniFi APs out in the wild behind a NAT device, and I have a Network Controller in an office behind a NAT device.
I am getting STUN errors on the APs, but I'm not sure if I need to worry about it.
when I look at this statement in the UI documentation:
In simple terms, STUN provides a way for devices to securely communicate with other devices when they're located behind a router.
It's unclear if they are discussion my scenario, where the APs and the Controller are not behind the same NAT device. Also, is STUN so APs behind NAT can talk to other APs behind the SAME NAT?
The problem is I have a configuration they do not specifically address, and I don't know if their statements apply to my secenario.
Thanks.
-
@jasgot said in Understanding STUN???:
@travisdh1 said in Understanding STUN???:
@jasgot said in Understanding STUN???:
@travisdh1 said in Understanding STUN???:
You'll need to open network ports to the UniFi controller on the firewall it sits behind.
Except I'm not certain I even want STUN. If it does not provide a required component for these APS to work (they are working without it now) , I'll likely to leave those ports closed on the controller side.
That's the thing, they'll work in the current configuration, but you can't update any settings.
How so? I can make all kinds of changes and even open a debug terminal to it without STUN working.
Right, because the APs reach out to the controller. They are not audio/visual equipment so they can't use STUN. They have single communications channels to their controller. It's just HTTPS, nothing more. HTTPS can't use STUN and has no need for it.
STUN Is used with SIP + RDP because it is three connections that have to act as one. STUN helps to coordinate them.
-
@jasgot said in Understanding STUN???:
I am trying to understand what STUN does. I have some UniFi APs out in the wild behind a NAT device, and I have a Network Controller in an office behind a NAT device.
I am getting STUN errors on the APs, but I'm not sure if I need to worry about it.
when I look at this statement in the UI documentation:
In simple terms, STUN provides a way for devices to securely communicate with other devices when they're located behind a router.
It's unclear if they are discussion my scenario, where the APs and the Controller are not behind the same NAT device. Also, is STUN so APs behind NAT can talk to other APs behind the SAME NAT?
If they're behind the same NAT, nothing additional is needed for the APs to communicate between each other.
The problem is I have a configuration they do not specifically address, and I don't know if their statements apply to my secenario.
Thanks.
STUN allows a device to reach outside of it's local network. It does not allow devices behind two disparate networks to communicate.
You'll need to open network ports to the UniFi controller on the firewall it sits behind. See https://help.ui.com/hc/en-us/articles/218506997-UniFi-Ports-Used
I think you only need 8080/3478 if you are only managing devices remotely, been a while so I'm not 100% sure on that.
-
@travisdh1 said in Understanding STUN???:
You'll need to open network ports to the UniFi controller on the firewall it sits behind.
Except I'm not certain I even want STUN. If it does not provide a required component for these APS to work (they are working without it now) , I'll likely to leave those ports closed on the controller side.
-
@jasgot said in Understanding STUN???:
@travisdh1 said in Understanding STUN???:
You'll need to open network ports to the UniFi controller on the firewall it sits behind.
Except I'm not certain I even want STUN. If it does not provide a required component for these APS to work (they are working without it now) , I'll likely to leave those ports closed on the controller side.
That's the thing, they'll work in the current configuration, but you can't update any settings.
-
@travisdh1 said in Understanding STUN???:
@jasgot said in Understanding STUN???:
@travisdh1 said in Understanding STUN???:
You'll need to open network ports to the UniFi controller on the firewall it sits behind.
Except I'm not certain I even want STUN. If it does not provide a required component for these APS to work (they are working without it now) , I'll likely to leave those ports closed on the controller side.
That's the thing, they'll work in the current configuration, but you can't update any settings.
How so? I can make all kinds of changes and even open a debug terminal to it without STUN working.
-
@jasgot said in Understanding STUN???:
@travisdh1 said in Understanding STUN???:
@jasgot said in Understanding STUN???:
@travisdh1 said in Understanding STUN???:
You'll need to open network ports to the UniFi controller on the firewall it sits behind.
Except I'm not certain I even want STUN. If it does not provide a required component for these APS to work (they are working without it now) , I'll likely to leave those ports closed on the controller side.
That's the thing, they'll work in the current configuration, but you can't update any settings.
How so? I can make all kinds of changes and even open a debug terminal to it without STUN working.
Then that makes no sense to me. If the setup is as you describe in your initial post, then there has to be some way they are communicating through both firewalls.
-
@travisdh1 said in Understanding STUN???:
Then that makes no sense to me. If the setup is as you describe in your initial post, then there has to be some way they are communicating through both firewalls.
Four APs -> Comcast Cable Modem -> Internet -> Comcast Cable Modem -> Firewall/Router -> Network Controller
The Four APs have a 10.1.10.x address behind the cable modem
The Network Controller has a 192.168.1.x address behind a router with a public IP. -
@jasgot said in Understanding STUN???:
Also, is STUN so APs behind NAT can talk to other APs behind the SAME NAT?
No, they don't communicate with each other at all. If they did, it would be LAN communications.
-
@jasgot said in Understanding STUN???:
I am getting STUN errors on the APs, but I'm not sure if I need to worry about it.
The APs themselves have STUN errors? I've never seen that. Can you show the error?
-
@jasgot said in Understanding STUN???:
I am trying to understand what STUN does.
STUN is used to coordinate exposed services that lack open, forwarded ports, behind NAT and/or public IP addresses assigned to them. The most common examples are for things like SIP phones to be able to coordinate their UDP ports with the server as they cannot connect directly.
STUN is only for communications protocols in theory (but anything COULD use it.) It's used with SIP phones, WebRTC, etc.
-
@jasgot said in Understanding STUN???:
I have some UniFi APs out in the wild behind a NAT device, and I have a Network Controller in an office behind a NAT device.
You have a Unifi controller that does not have ports forwarded to it? I don't think that that is even possible. STUN won't help there. STUN doesn't bypass the firewall, it just moves port info around where it is needed. Unifi Controllers have to be published.
-
@jasgot said in Understanding STUN???:
Except I'm not certain I even want STUN. If it does not provide a required component for these APS to work (they are working without it now) , I'll likely to leave those ports closed on the controller side.
It does nothing with APs or networking gear in general. If you are putting STUN on the APs, it is likely something that they publish as a service rather than use themselves.
The use of STUN does not have anything to do with which ports get opened.
-
@scottalanmiller said in Understanding STUN???:
The APs themselves have STUN errors? I've never seen that. Can you show the error?
The errors are listed in the controller.
-
@scottalanmiller said in Understanding STUN???:
You have a Unifi controller that does not have ports forwarded to it?
It does, just not the STUN port.
-
@jasgot said in Understanding STUN???:
@travisdh1 said in Understanding STUN???:
@jasgot said in Understanding STUN???:
@travisdh1 said in Understanding STUN???:
You'll need to open network ports to the UniFi controller on the firewall it sits behind.
Except I'm not certain I even want STUN. If it does not provide a required component for these APS to work (they are working without it now) , I'll likely to leave those ports closed on the controller side.
That's the thing, they'll work in the current configuration, but you can't update any settings.
How so? I can make all kinds of changes and even open a debug terminal to it without STUN working.
Right, because the APs reach out to the controller. They are not audio/visual equipment so they can't use STUN. They have single communications channels to their controller. It's just HTTPS, nothing more. HTTPS can't use STUN and has no need for it.
STUN Is used with SIP + RDP because it is three connections that have to act as one. STUN helps to coordinate them.
-
@jasgot said in Understanding STUN???:
@scottalanmiller said in Understanding STUN???:
You have a Unifi controller that does not have ports forwarded to it?
It does, just not the STUN port.
I don't think Unifi offers STUN services anyway.
-
@jasgot said in Understanding STUN???:
@scottalanmiller said in Understanding STUN???:
The APs themselves have STUN errors? I've never seen that. Can you show the error?
The errors are listed in the controller.
Can you show them?
-
@scottalanmiller said in Understanding STUN???:
I don't think Unifi offers STUN services anyway.
-
@jasgot apparently Unifi uses STUN for some UDP traffic stuff in some cases. None of the normal stuff, must be log shipping which is a communications channel. They recommend having the port opened and forwarded. But it shouldn't cause problems. They noted that they only added the warning recently so it might have always had the issue without reporting it previously.
-
@scottalanmiller said in Understanding STUN???:
They noted that they only added the warning recently so it might have always had the issue without reporting it previously.
Okay. Sounds like I can just ignore it. I would like to be able to turn off the warning, though!