Unraid and Ubiquiti Unifi: STUN Communication failed
-
is your controller on a different vlan/network than your AP? If not then pfsense has zero to do with it.. IE are you using L3 adoption on your AP?
If your AP and controller are on the same network they do not talk to pfsense to talk to each other.. Yes there where many a thread on unifi forums about the stun problems.. What version of the controller are you running as asked?
-
i started receiving this message as well. BUT it only started after upgrading to UniFi 5.6.22 Controller.
what controller version are you using? i also find that when the controller stops working, if i then reopen the controller wait about 5 minutes the messages go away..
I am on version 5.6.22 and you are right, it started for me about a month ago when the update came. Though my STUN error never goes away at any times…
is your controller on a different vlan/network than your AP? If not then pfsense has zero to do with it.. IE are you using L3 adoption on your AP?
If your AP and controller are on the same network they do not talk to pfsense to talk to each other.. Yes there where many a thread on unifi forums about the stun problems.. What version of the controller are you running as asked?
Yes, my Unifi-controller is installed as Docker on my unraid server which is running on LAN 192.168.1.1. Not quite sure what layer 3 adoption means, so I guess I am not using it! :P
The AP is on WLAN 192.168.2.1 and static mapped to 192.168.2.2 since I didn't know how to set it up with the Wireless Interface in pfSense. Everything works really as I see it, so I guess I could just ignore the STUN error (?) but I rather not have any errors. ;D -
If your AP is on 192.168.2 and your Controller is on 192.168.2 then they are on the same network and pfsense has ZERO to do with them talking to each other..
WLAN 192.168.2.1 is not a network, that is a host address 192.168.2.0 would be the network..
If your Controller is on 192.168.1 then that is a different network - if you did not setup L3 adoption sounds like you might just be running your 192.168.1 and 2 on the same layer 2 network??
I would suggest you follow the threads over on unifi to fix their stun problem… What does your AP show in the mgmt config ssh over to your AP and run
BZ.v3.9.15# cat /etc/persistent/cfg/mgmt
mgmt.is_default=false
mgmt.led_enabled=true
mgmt.cfgversion=5444ebeb511f2e74
mgmt.authkey=C4366D6<snipped>8A5
mgmt.selfrun_guest_mode=pass
mgmt.capability=notif
mgmt.servers.1.url=http://192.168.2.11:8080/inform
mgmt.servers.2.url=http://unifi:8080/inform
stun_url=stun://192.168.2.11/
mgmt_url=https://192.168.2.11:8443/manage/site/defaultValidate your controller is even listening on 3478 for stun
On your controller make sure java is even running stun on 3748
Its quite possible your AP has wrong stun url, pointing to wrong IP, etc..
So do you have your AP directly connect to that pfsense interface? Or is there a switch involved? What is the inform url from the AP pointing too, etc..</snipped>
-
You may want to read this link.
http://www.dickson.me.uk/2017/09/07/pfsense-firewall-rules-for-ubiquiti-cloud-key/
-
Stun outbound is not how the AP talk to the controller… Here is sniff of stun traffic on controller... There is no outbound to the internet stun traffic that I see
root@uc:/home/user# tcpdump -n udp port 3478
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
03:24:52.742764 IP 192.168.2.3.57837 > 192.168.2.11.3478: UDP, length 28
03:24:52.743415 IP 192.168.2.11.3478 > 192.168.2.3.57837: UDP, length 56
03:24:57.524449 IP 192.168.2.4.60981 > 192.168.2.11.3478: UDP, length 28
03:24:57.524904 IP 192.168.2.11.3478 > 192.168.2.4.60981: UDP, length 56
03:24:57.886911 IP 192.168.2.2.59428 > 192.168.2.11.3478: UDP, length 28
03:24:57.887887 IP 192.168.2.11.3478 > 192.168.2.2.59428: UDP, length 56But you can clearly see all 3 of my AP talking to the controller via the stun url that is in the config of the AP.. Left the dump running for 5 minutes.. No outbound traffic on stun...
-
If your AP is on 192.168.2 and your Controller is on 192.168.2 then they are on the same network and pfsense has ZERO to do with them talking to each other..
WLAN 192.168.2.1 is not a network, that is a host address 192.168.2.0 would be the network..
If your Controller is on 192.168.1 then that is a different network - if you did not setup L3 adoption sounds like you might just be running your 192.168.1 and 2 on the same layer 2 network??
I would suggest you follow the threads over on unifi to fix their stun problem… What does your AP show in the mgmt config ssh over to your AP and run
BZ.v3.9.15# cat /etc/persistent/cfg/mgmt
mgmt.is_default=false
mgmt.led_enabled=true
mgmt.cfgversion=5444ebeb511f2e74
mgmt.authkey=C4366D6<snipped>8A5
mgmt.selfrun_guest_mode=pass
mgmt.capability=notif
mgmt.servers.1.url=http://192.168.2.11:8080/inform
mgmt.servers.2.url=http://unifi:8080/inform
stun_url=stun://192.168.2.11/
mgmt_url=https://192.168.2.11:8443/manage/site/defaultValidate your controller is even listening on 3478 for stun
On your controller make sure java is even running stun on 3748
Its quite possible your AP has wrong stun url, pointing to wrong IP, etc..
So do you have your AP directly connect to that pfsense interface? Or is there a switch involved? What is the inform url from the AP pointing too, etc..</snipped>
I'm sorry that I was unclear. The answer is yes, the AP is on WLAN (192.168.2.2) and my controller is on LAN (192.168.1.8 ). The AP is directly connected to pfSense.
How could I make sure java is running on 3478 or that the controller is listening on that port?
The commands gives me this:
BZ.v3.9.3# cat /etc/persistent/cfg/mgmt
mgmt.is_default=false
mgmt.led_enabled=true
mgmt.cfgversion=b6d677876d1d3f61
mgmt.authkey=523BB<snipped>360
mgmt.selfrun_guest_mode=pass
mgmt.capability=notif
mgmt.servers.1.url=http://192.168.1.8:8080/inform
mgmt.servers.2.url=http://unifi:8080/inform
stun_url=stun://192.168.2.2/
mgmt_url=https://192.168.2.2:8443/manage/site/defaultYou may want to read this link.
http://www.dickson.me.uk/2017/09/07/pfsense-firewall-rules-for-ubiquiti-cloud-key/
I will try this! :)</snipped>
-
That link has NOTHING to do with your problem
Look at your URL..
mgmt.servers.1.url=http://192.168.1.8:8080/inform
mgmt.servers.2.url=http://unifi:8080/inform
stun_url=stun://192.168.2.2/Your AP is trying to point to its own IP for stun - so yeah the controller is going to say its not seeing stun from the AP…
This URL is wrong too
mgmt_url=https://192.168.2.2:8443/manage/site/defaultI would reprovision the AP.. forget it and adopt it again. Your going to need to do L3 adoptions since your controller is not on the same L2 as your AP..
https://help.ubnt.com/hc/en-us/articles/204909754-UniFi-Device-Adoption-Methods-for-Remote-UniFi-Controllers
Since your AP is not even pointing to the controller for stun, doesn't matter if controller is listening or not... But you can check on the controller with simple netstat.. that 3478 is listening and that java opened it
root@uc:/home/user# netstat -tulpn | grep 3478
udp6 0 0 :::3478 :::* 7248/javaThen you can see from that PID 7248
root@uc:/home/user# ls -l /proc/7248/exe
lrwxrwxrwx 1 unifi unifi 0 Dec 12 13:29 /proc/7248/exe -> /usr/lib/jvm/java-8-oracle/jre/bin/java -
That link has NOTHING to do with your problem
Look at your URL..
mgmt.servers.1.url=http://192.168.1.8:8080/inform
mgmt.servers.2.url=http://unifi:8080/inform
stun_url=stun://192.168.2.2/Your AP is trying to point to its own IP for stun - so yeah the controller is going to say its not seeing stun from the AP…
This URL is wrong too
mgmt_url=https://192.168.2.2:8443/manage/site/defaultI would reprovision the AP.. forget it and adopt it again. Your going to need to do L3 adoptions since your controller is not on the same L2 as your AP..
https://help.ubnt.com/hc/en-us/articles/204909754-UniFi-Device-Adoption-Methods-for-Remote-UniFi-Controllers
Since your AP is not even pointing to the controller for stun, doesn't matter if controller is listening or not... But you can check on the controller with simple netstat.. that 3478 is listening and that java opened it
root@uc:/home/user# netstat -tulpn | grep 3478
udp6 0 0 :::3478 :::* 7248/javaThen you can see from that PID 7248
root@uc:/home/user# ls -l /proc/7248/exe
lrwxrwxrwx 1 unifi unifi 0 Dec 12 13:29 /proc/7248/exe -> /usr/lib/jvm/java-8-oracle/jre/bin/javajohnpoz, you are exactly right. I just noticed this before I saw your post. It is me that have been stupid all the way…... :-X >:(
As you noticed I've used the IP to the AP all the time and not to the Controller... I believed I've tried that before, but obviously not since it's working now.
So all I did was to change the settings like the - attached printscreen - restart Unifi and Access point and it's working without errors. Doesn't seem to need L3 adoption either.
At least I hope this will help others.
EDIT I also needed to add a Host Port (UDP 3478) in the docker file for Unifi in Unraid as this was not in the standard template.
 -
If your AP is already adopted.. you must of moved the controller at some point from the L2 of the AP… Then yes setting that inform is L3 adoption.. Its when your AP is not already adopted would you have to use the methods listed int he article I linked too.. Like ssh to the AP and set your inform url from there, etc.
You setting that would allow for provision to fix the urls on the AP so now if you look at the conf cmd you did before you will see the stun is pointing to your controller IP now ;)
Glad you got it sorted. Where you will have problems is if you add another AP on that other L2 where the controller will not be able to see it.. That is the reason for the different methods of adopting new AP when controller is not on the same L2 as the APs..
It would be easier if you just ran your controller on the same network as your AP... Why exactly do you have them on different networks? If you have your AP directly connected to pfsense interface.. Just use a smart switch (vlan support) So you can put any device you want on any network you want.. Smart switches can be as cheap as $35 for a 8 port gig smart switch.. Got one on sale for $25, etc..
-
If your AP is already adopted.. you must of moved the controller at some point from the L2 of the AP… Then yes setting that inform is L3 adoption.. Its when your AP is not already adopted would you have to use the methods listed int he article I linked too.. Like ssh to the AP and set your inform url from there, etc.
You setting that would allow for provision to fix the urls on the AP so now if you look at the conf cmd you did before you will see the stun is pointing to your controller IP now ;)
Glad you got it sorted. Where you will have problems is if you add another AP on that other L2 where the controller will not be able to see it.. That is the reason for the different methods of adopting new AP when controller is not on the same L2 as the APs..
It would be easier if you just ran your controller on the same network as your AP... Why exactly do you have them on different networks? If you have your AP directly connected to pfsense interface.. Just use a smart switch (vlan support) So you can put any device you want on any network you want.. Smart switches can be as cheap as $35 for a 8 port gig smart switch.. Got one on sale for $25, etc..
Yeah, now the output on the conf cmd is pointing both stun and mgmt to the controller. :)
I can now see why they should be run on the same network.
In my set-up I am using an Unraid server which is connected to a switch (my old 4-port ASUS router now only used as a switch :P) and that is connected to LAN.
Unraid is a Unix server OS based on Slackware, it's developed by Lime-Tech see https://lime-technology.com/.
I have been using it for about 2 years now and it has served for many things, some months ago I bought a newer better server and moved to that and made the old server to a pfSense router instead (now learning while doing).Unraid has Docker built-in, which makes it possible to use many different Docker plugins and I noticed that there was a docker plugin for Unifi so I have been using that.
Now I tried to undo as many settings as possible to find out the exact cause of the fault and I came to a conclusion that it is both the "Override inform host" setting I mentioned in my latest comment here, but also that I had to add another port in Docker for the STUN. So I updated the post now for future reference if someone Googles this. :) So once again, as you said, this has NOTHING to do with pfSense.
I've actually thought of buying a manageable switch since I am completely out of ports right now. All ports are used for something so if I want to wire my main PC I have to unplug something else. :P
Though they are pricey and I live in sweden so I don't have that nice access to Amazon as you do. I've been thinking about buying a chinese one, but I don't know if I can trust them and I doesn't want to try neither. :) -
I think I have the exact same issue.
I had pfsense running as my main router (192.168.1.1/24) and lan.
I created a second lan (192.168.2.1/24).
I had both my Ubiquiti controller and AP on .1 but later I moved it to .2 and now the AP has the STUN Communication failed too!
Do you, or anyone who got to see the screen shots know which settings these are to resolve it?
All i get is
no picture :(
-
Okies nevermind, I found out the issue.
I had put a pass between the two subnets, BUT i forgot and left it at TCP and not any, so UDP was not passed.
Dumb mistake, but I hope it helps someone who googles and finds this.
Check firewall rules!
