April 7, 20251 yr Author 6 minutes ago, MrTroll said: Using Firefox private window or not it will not connect if I use Chrome it will connect but will flag the connection as experiencing performance issues. I can connect it via my phone however using the app. From memory this only kicked in around network server 8.xx. I have yet to try a full reinstall of the container but I've been trying to fix this on and off for a while. What are you typing into the private browser window as the address? also please disable the port forward on your firewall. It is not required at all. Edited April 7, 20251 yr by PeteAsking
April 7, 20251 yr 2 minutes ago, PeteAsking said: What are you typing into the private browser window as the address? I may not have been clear from the start this is via https://unifi.ui.com. Here is some slightly different logs. I'll also specify that the error I get when attempting to connect via Firefox is "Connecting to Site is taking longer than expected" I've also got the container set to bridge mode. logs.txt
April 7, 20251 yr Author Just now, MrTroll said: I may not have been clear from the start this is via https://unifi.ui.com. Here is some slightly different logs. I'll also specify that the error I get when attempting to connect via Firefox is "Connecting to Site is taking longer than expected" I've also got the container set to bridge mode. logs.txt 2.09 kB · 0 downloads Is the docker in Bridge mode? If so please use the ip of your unraid server eg: https://192.168.2.4:8443/ where 192.168.2.4 would be replaced with your unraid server ip address.
April 7, 20251 yr Author For that unifi.ui.com site - thats a unifi site hosted by unifi who owns the domain. To access that site it should load if you have a normal internet connection. once logged in you can access your controllers if you have sso turned on in the controller and also remote management here (as you are logging into their website you have to be using a username/password that is synced from the controller to their website): Edited April 7, 20251 yr by PeteAsking
April 7, 20251 yr I have remote acess configured on the server container and had been using it for sometime without issue but around version 8.xx it wouldn't connect via Firefox and would give that connection warning on chrome. Using the mobile app it's always been able to remote access connect. I cannot connect using 8443 with my internal Lan address due to it being using by another container on my server so I since changed it to be 8445. Using that port I can connect without issue. Just to be completely clear my issues have been with connecting using only the unifi.ui remote access method, I've not had any issues connecting from within my network. The soul issue is using Firefox at all and more broadly the slow connection tag in chrome.
April 7, 20251 yr Author 8 minutes ago, MrTroll said: I have remote acess configured on the server container and had been using it for sometime without issue but around version 8.xx it wouldn't connect via Firefox and would give that connection warning on chrome. Using the mobile app it's always been able to remote access connect. I cannot connect using 8443 with my internal Lan address due to it being using by another container on my server so I since changed it to be 8445. Using that port I can connect without issue. Just to be completely clear my issues have been with connecting using only the unifi.ui remote access method, I've not had any issues connecting from within my network. The soul issue is using Firefox at all and more broadly the slow connection tag in chrome. This is why it does not work. You cannot change the port because the stun is hardwired to connect back to that port. for this setup you must change from bridge to macvlan and assign the container its own ip on the lan and allow it to use the native ports. This should resolve your issues. remember as far as the container knows it is using 8443 so if it informs the external website via stun it will inform it to connect back on 8443. This cant be solved without you making sure that this is reachable somehow. another option is to use nat rewrite rules on your firewall. I do not recommend exposing the container to the internet however. Edited April 7, 20251 yr by PeteAsking
April 7, 20251 yr Author @MrTroll to test this without making too many changes you could stop the container running on 8443 and then let the unifi controller use that port again, make sure you didnt have any firewall rules on that port etc. then check if its working. If this test solves it you can decide how best to change things internally to accommodate. Edited April 7, 20251 yr by PeteAsking
April 7, 20251 yr Author Also check you dont have any super complex firewall setup interfering in addition.
April 7, 20251 yr 1 hour ago, PeteAsking said: This is why it does not work. You cannot change the port because the stun is hardwired to connect back to that port. for this setup you must change from bridge to macvlan and assign the container its own ip on the lan and allow it to use the native ports. This should resolve your issues. remember as far as the container knows it is using 8443 so if it informs the external website via stun it will inform it to connect back on 8443. This cant be solved without you making sure that this is reachable somehow. another option is to use nat rewrite rules on your firewall. I do not recommend exposing the container to the internet however. So i've just changed it back it seems like whatever was using 8443 is no longer around. However the issue remains. The log has this from the point of the first attempted remote connection through unifi.ui :0 TCP candidates not supported yet :0 Permanent error code on allocate request: 420 - . This was after receiving a valid nonce :0 TURN instance failed: TURN id: 3; fd: 228 0.0.0.0:46014 -> 141.101.90.1:3478 (all_interfaces) DTLS id: :0 TCP candidates not supported yet :0 Permanent error code on allocate request: 420 - . This was after receiving a valid nonce :0 TURN instance failed: TURN id: 3; fd: 239 0.0.0.0:56798 -> 141.101.90.1:3478 (all_interfaces) DTLS id: :0 STUN id: 4; fd: 225 172.17.0.2:52113 -> 159.196.184.248:55577 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 5; fd: 225 172.17.0.2:52113 -> 104.30.144.186:28642 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 6; fd: 225 172.17.0.2:52113 -> 104.30.144.186:65045 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 7; fd: 225 172.17.0.2:52113 -> 104.30.144.186:14763 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 8; fd: 225 172.17.0.2:52113 -> 104.30.144.187:26968 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 9; fd: 225 172.17.0.2:52113 -> 104.30.144.187:35572 (eth0) DTLS id: 0 () (PEER) timed out :0 TCP candidates not supported yet :0 Permanent error code on allocate request: 420 - . This was after receiving a valid nonce :0 TURN instance failed: TURN id: 3; fd: 236 0.0.0.0:50746 -> 141.101.90.1:3478 (all_interfaces) DTLS id: :0 TCP candidates not supported yet :0 Permanent error code on allocate request: 420 - . This was after receiving a valid nonce :0 TURN instance failed: TURN id: 3; fd: 256 0.0.0.0:55003 -> 141.101.90.1:3478 (all_interfaces) DTLS id: :0 STUN id: 4; fd: 229 172.17.0.2:44891 -> 159.196.184.248:54395 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 5; fd: 229 172.17.0.2:44891 -> 104.30.144.187:9342 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 6; fd: 229 172.17.0.2:44891 -> 104.30.144.186:23964 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 7; fd: 229 172.17.0.2:44891 -> 104.30.144.187:16098 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 8; fd: 229 172.17.0.2:44891 -> 104.30.144.187:42590 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 9; fd: 229 172.17.0.2:44891 -> 104.30.144.186:47654 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 4; fd: 233 172.17.0.2:54538 -> 159.196.184.248:59810 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 5; fd: 233 172.17.0.2:54538 -> 104.30.144.186:52553 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 6; fd: 233 172.17.0.2:54538 -> 104.30.144.187:21379 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 7; fd: 233 172.17.0.2:54538 -> 104.30.144.187:9317 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 8; fd: 233 172.17.0.2:54538 -> 104.30.144.187:20994 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 9; fd: 233 172.17.0.2:54538 -> 104.30.144.186:17971 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 4; fd: 253 172.17.0.2:45682 -> 159.196.184.248:56050 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 5; fd: 253 172.17.0.2:45682 -> 104.30.144.186:11716 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 6; fd: 253 172.17.0.2:45682 -> 104.30.144.187:45432 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 7; fd: 253 172.17.0.2:45682 -> 104.30.144.187:45504 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 8; fd: 253 172.17.0.2:45682 -> 104.30.144.187:31482 (eth0) DTLS id: 0 () (PEER) timed out :0 STUN id: 9; fd: 253 172.17.0.2:45682 -> 104.30.144.187:51779 (eth0) DTLS id: 0 () (PEER) timed out
April 7, 20251 yr Author I think something in your firewall is interfering. What is your firewall setup and is it complex? @MrTroll Edited April 7, 20251 yr by PeteAsking
April 7, 20251 yr 7 minutes ago, PeteAsking said: I think something in your firewall is interfering. What is your firewall setup and is it complex? @MrTroll I used to have a region block on everywhere that's outside of my home country but I removed that ages ago. Apart from that a bunch of port forwarding for game servers and that's about it.
April 7, 20251 yr Author 2 hours ago, MrTroll said: I used to have a region block on everywhere that's outside of my home country but I removed that ages ago. Apart from that a bunch of port forwarding for game servers and that's about it. Can you check your docker has internet? Open the console of the reborn docker and do this:
April 7, 20251 yr 43 minutes ago, PeteAsking said: Can you check your docker has internet? Open the console of the reborn docker and do this: As requested
April 7, 20251 yr Author @MrTroll I agree I am running out of ideas here. Is the date correct (type date in the console and check not out more than 5 minutes).
April 7, 20251 yr Sorry, quick qusetion. Will this allow control of USG devices? or is it only for AP's & Switches? Thanks
April 7, 20251 yr Author 17 minutes ago, tcshavasu said: Sorry, quick qusetion. Will this allow control of USG devices? or is it only for AP's & Switches? Thanks Only ap and switches
April 7, 20251 yr 3 hours ago, tcshavasu said: Sorry, quick question. Will this allow control of USG devices? or is it only for AP's & Switches? Thanks I had a usg for a short time and yes the controller docker will work will all unifi equipment As long as you have the correct tag and unifi min version running for that hardware. On unifi product page tech spec min unifi version is the tag you need to be at least running. https://dl.ubnt.com/datasheets/unifi/UniFi_Security_Gateway_DS.pdf also FYI unifi has dropped USG due to hardware software constraints. https://community.ui.com/questions/USG-3P-End-of-Life/f0f57d71-c852-439d-8be7-d61b92f7905a They will still work and function, but it would be a known security risk or attack vector.
April 7, 20251 yr Check and check. I'm considering the nuclear option here brother. Will deleting my container, it's app data and starting again from scratch orphan my unifi devices requiring a reset for them to be able to enroll them.
April 7, 20251 yr 11 minutes ago, MrTroll said: Check and check. I'm considering the nuclear option here brother. Will deleting my container, it's app data and starting again from scratch orphan my unifi devices requiring a reset for them to be able to enroll them. what is your docker network for the unfi application? I would 2 3 things... 1. Move off ipvlan and use macvlan setting unraid docker setting to -Macvlan is needed to give the container a random mac to be used latter... Ip vlan use teh unraid host interface mac address causing problems when mutiple dockers use the same mac address... 2. edit the unfi controller template and use custom bro (bond0, br0, eth0 depending on other unraid settings) 3. add a host name and extra dns option for the docker to have dns routes out... --hostname unifi --dns=192.168.0.1 --dns=8.8.8.8 add and make these changes will 1 separate the unfi docker off the docker bride given it its own ip at 192.168.0.228 and all port open and accessible to that docker instance. this will also give the docker its own mac address for later networking use of arp cache and accesses and helps the inform host as unfi calls the dns name unifi across the network and if running a dns service like adguard / pihole it is recommended to add a host option to unfi to the ip address of the controller... when stun issue arise its always port and network cross talk issues... https://community.ui.com/questions/STUN-Communication-Failed/226fb3e1-26ac-43d0-b265-714d9e45f161
April 7, 20251 yr 3 hours ago, bmartino1 said: what is your docker network for the unfi application? I would 2 3 things... 1. Move off ipvlan and use macvlan setting unraid docker setting to -Macvlan is needed to give the container a random mac to be used latter... Ip vlan use teh unraid host interface mac address causing problems when mutiple dockers use the same mac address... 2. edit the unfi controller template and use custom bro (bond0, br0, eth0 depending on other unraid settings) 3. add a host name and extra dns option for the docker to have dns routes out... --hostname unifi --dns=192.168.0.1 --dns=8.8.8.8 add and make these changes will 1 separate the unfi docker off the docker bride given it its own ip at 192.168.0.228 and all port open and accessible to that docker instance. this will also give the docker its own mac address for later networking use of arp cache and accesses and helps the inform host as unfi calls the dns name unifi across the network and if running a dns service like adguard / pihole it is recommended to add a host option to unfi to the ip address of the controller... when stun issue arise its always port and network cross talk issues... https://community.ui.com/questions/STUN-Communication-Failed/226fb3e1-26ac-43d0-b265-714d9e45f161 After following all your recommendations I have to report that the issue remains. I really want to focus on the fact it works with Chrome and the app but not with Firefox.
April 8, 20251 yr Author 2 hours ago, MrTroll said: After following all your recommendations I have to report that the issue remains. I really want to focus on the fact it works with Chrome and the app but not with Firefox. Do you use static ip addressing on any of the ap’s or switches? Please check you have dns assigned to the devices and or normal dhcp. If you use dns filter eg pihole please disable for an hour while you test. Edited April 8, 20251 yr by PeteAsking
April 8, 20251 yr 3 hours ago, PeteAsking said: Do you use static ip addressing on any of the ap’s or switches? Please check you have dns assigned to the devices and or normal dhcp. If you use dns filter eg pihole please disable for an hour while you test. Yup they're all set to a normal DHCP server. Its all and all a very standard network setup with a pihole set and even after I tried turning off the error remained.
April 8, 20251 yr 5 hours ago, MrTroll said: After following all your recommendations I have to report that the issue remains. I really want to focus on the fact it works with Chrome and the app but not with Firefox. did the stun issues lesson or stop? Are you using vlans? ? what works with chrome / app but not firefox? Adaption for equipment? Usauly if i see different behavior in one browser vs another its a issue with the web browser and how the engine decided to read the web page... You mentioned running pihole. Did you set a custom dns host name of unifi to the inform ip and ip of the controller? I would also Highly recomend clearing firefox cached data and coookies... Also make sure your using the lattest firefox version and/or try the esr version... Different webkit engine... https://support.mozilla.org/en-US/kb/switch-to-firefox-extended-support-release-esr https://www.mozilla.org/en-US/firefox/all/desktop-esr/ and try again...
April 8, 20251 yr 17 minutes ago, bmartino1 said: did the stun issues lesson or stop? Are you using vlans? ? what works with chrome / app but not firefox? Adaption for equipment? Usauly if i see different behavior in one browser vs another its a issue with the web browser and how the engine decided to read the web page... You mentioned running pihole. Did you set a custom dns host name of unifi to the inform ip and ip of the controller? I would also Highly recomend clearing firefox cached data and coookies... Also make sure your using the lattest firefox version and/or try the esr version... Different webkit engine... https://support.mozilla.org/en-US/kb/switch-to-firefox-extended-support-release-esr https://www.mozilla.org/en-US/firefox/all/desktop-esr/ and try again... Stun issues looked to remain the same. I am not using Vlans. I added the custom hostname to the extra parameters field as suggested. Pihole is running on a custom Br0 network itself. I cannot access my Unifi Network through the Unifi.UI when I select it in the site manager it never loads, but only in firefox. In Chrome it will load with the globe icon in the top left being orange giving a speed warning. The Unifi app works fine aswell. Some of the digging I did on my own point to how firefox handles Stun vs chrome. I've cleared firefox data and cookies many times, i've turned off enhanced protection which is on be default everything nothing changes. Yes I have the latest version. My network is very simple, I use a single Unifi router, switch, ap. I am not running behind a NAT as I've asked my ISP to disable it ages ago. Edited April 8, 20251 yr by MrTroll Clarity
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.