Unifi Diagnosis: the troubles with github threat protection and mysterious iOS incompatibilities

OK, I thought I had beat this one, but now it looks like there are more issues, but in tuning our Unifi network I was working on two issues:

  1. Apple devices sometimes will not connect. If you turn on all the goodies with Wifi, then iOS clients will suddenly report that they can’t connect to the network or that the password (which I know is good) is suddenly invalid. I’ve tried setting DTIM to 3 seconds and like many folks that does not work. So I tried an experiment, have a “test” network with all the goodies turned on and switch each setting off in turn. I learned last week that WPA3 only does not work for Apple devices, they are supposed to support WPA3, but it does not work, you have to select WPA2/WPA3 so that they can connect with WPA2.
  2. Github pulls and pushes do not work. I had this before where pulls and pushes and other GitHub Actions didn’t work. It was getting caught by the ESCAN errors because GitHub has lots of IP addresses. I whitelisted GitHub, but the errors are still happening. It works if you just have intrusion detection, but I would really like intrusion prevention.

So for those of you with similar problems, here are the debugging steps (at least for this week). The nice thing about Unifi is that they let you create lots of Wifi SSID so testing is simply creating a different SSID and then seeing what is failing when connecting to that.

For this test network, here were the special features in Unifi.ui.com that I turned on. Go to your Unifi Dashboard and then Settings > Wifi and then click on the vertical eclipses on your test network and click Advanced, here I enabled these options. I know that if I disable them all, then I get reliable connection with iPhone and iPad, but one of these settings is giving iOS a heart attack. This settings by the way seem to work for a while and then after a day or two they fail:

  1. Security Protocol. WPA2/WPA3
  2. UAPSD. Unschedule Automatic Power Save Delivery
  3. Multicast Enhancement. Permit devices to send multicast traffic to registered clients at higher data rates
  4. BSS Transition. Allow BSS Transition to WNM (I have no idea what that means)
  5. SAE Anticlogging. WPA 3 only. Set to 5
  6. SAE Sync Time. WPA 3. Set to 5
  7. PMF. Protected Management frames required
  8. Group Rekey Interval. Set to 3600.
  9. Override DTIM Period. 3 seconds for both 2G and 5G

One or more of these setting is giving IOS a problem, so this is a great example of debugging. What’s the most efficient thing to do. Well, if there is only one setting that is the problem, then a binary search works. That is turn off half and see what happens. if it works, the add back the rest and so forth. But if there are multiple problems, then it is unclear. So what I decided to do is to go the other way. Turn them all off and turn them on one at a time and see what’s stable. So here goes. I’ll keep you updated, but for now, I’m just leaving on the easiest one which is the DTIM override, then I’ll add others on as I go, so for this coming week I’m only leaving on:

  1. WPA2/WPA3 Security which implies SAE Anti-clogging and SAE Sync Time
  2. Override DTIM period. 3 seconds
  3. Protected Management Frames. Optional
  4. Group Rekey Interval. Off

A note on changing Wifi network setting: wait a bit

As soon as I enabled it, suddenly my Mac lost connection to the test network and would not reconnect, although the iPhone worked fine. I think this is probably related to changing these parameters dynamically, so when the APs updated, the Mac became very unhappy and it required some time to work again. I just turned off the wifi for a bit and waited.

Unifi Threat Protection and Github and white listing

OK, the next issue is that my various requests to Github keep hanging if I turn on threat protection. I thought I had whitelisted everything, but apparently not enough. So I turn on Threat Detection and it all works again, so time to dive into the logs and alerts and see what the problems are:

One of the big issues with Unifi is that the logging is all over the place. In the Dashboard, there is an alert section but this is pretty useless, it mainly has client disconnect messages. I used to get all kinds of Security alerts, but I had forgotten how that all works. There is a separate button called Threat management which is a different kind of logging and that is where to look to see all those scary alerts, there are literally thousands of these things.

So here is the process, it doesn’t look like you can whitelist an IP address, but you basically white list an attack. So that means:

  1. Run the GitHub request like git pull then look in the Unifi Dashboard > Threat Management > Traffic Log one confusing thing is that list is *not* sorted by Last Recorded Threat which is pretty confusing, so make sure to click that to see the latest threats. also note, it takes about 10 seconds for anything to appear in the log, so be patient while you wait for the list to propagate
  2. Figure out the IP address of your machine, the easiest way is to hold the Option key down and then click on the network icon or ifconfig | grep inet will give it to you.
  3. Now run the command that seems to be blocked, in my case, git push and see what happens on the list. A new log entry should appear and that is the one you want to whitelist. You should see the source as within your network and then the destination is outbound
  4. In this case I could see that the message was again ET SCAN Potential SSH Scan Outbound and then in the ASN field, I could see that it was going to GitHub, so a quick Allow List and I was back in action
  5. As a quick aside, the Internet Threat Management is turned on pretty high with only P2P and TOR turned off since I do use TOR sometimes.

I’m Rich & Co.

Welcome to Tongfamily, our cozy corner of the internet dedicated to all things technology and interesting. Here, we invite you to join us on a journey of tips, tricks, and traps. Let’s get geeky!

Let’s connect