Help with rules to block UniFi Cloudkey Gen2+
-
Hello everyone,
I need your advice so that I can block all communication from my "UniFi Cloudkey Gen2+" to the Internet, so that I can open the gateway only when an update is proposed.
However, it must still be able to communicate on my LAN and on my VLAN_200 (where my cameras are located).
I've "invented" these two rules, but I'm not really sure I've got it right!
Another question: do I need another rule to block the "https://account.ui.com/login" that allows access from anywhere on "UniFi Cloudkes Gen2 +"?
What do you think?
Thanks in advance for your help and advice
-
@SwissSteph those rules are not going to work.. For starters the wan subnet is not the internet, its just the network your wan is connected to. The isp network that is a transit network to the internet - your clouldkey is never going to want to go to this network in the first place - its going to go to some IP out on the internet, ie 5.6.7.8 while your wan subnet is say 1.2.3.0/21 or whatever..
And the bottom rule there is not going to ever do anything ever because rules are evaluated as traffic enters an interface from the network its attached too.. There is no scenario where traffic entering your lan interface from your lan network would ever have a source IP of your wan address.
If you want to stop your cloudkey from going to the internet create rule(s) that allows what you want it to go to either on the internet or your other local networks. Then below that create a any rule that blocks its ip from going anywhere else, ie the internet.
Rules are evaluated as the traffic enters the interface, first rule to trigger wins, no other rules are evaluated.
Out of curiosity - where do you think your clouldkey is going that you want to prevent? You can turn off remote management in the controller settings. If you don't want to be able to control it that way.
Either by just not allowing it, or you could click the remove remote access.
edit: notice my controller is not listed anywhere on the site manager
-
Thanks for your explanation and screenshot. I searched my UCK Gen2 + online, but I couldn't find the same parameter.
But I still think it's great to be able to access it in the event of a local problem and check things out.
That's why I wanted to block this specific address from leaving my local network, while letting it go on my LAN (because I have my WiFi antennas) and on my VLAN_200 (where my cameras are).I'm sorry to bother you, but would you have an example of rules on Pfsense to be able to do exactly what you're explaining, i.e. blocking access to the Internet and only internal access.
Right now, I'm a bit lost...
EDIT :
Another attempt to play by the rules and be OK! -
@SwissSteph so the cloudkey doesn't have an administration tab? Are you logged in with an admin account? Look under your advanced tab there might be this
As to allowing local access.. So if you don't want your controller to have internet access, create a rule with its IP as source and blocking any..
So here is my lan for example - it allows all outbound and to my other networks.
If I wanted to allow say my controller on 192.168.9.42, my lan network is 192.168.9.0/24 to only go to local stuff, and not go to the internet I would say use rules like this.
Where I allow it to go to any rfc1918 network (alias you can create)..
But then below that before the any any rule I say hey 192.168.9.42 trying to go anywhere would be blocked.. Rules are evaluated top down, first rule to trigger wins, no other rules are evaluated.
So going to pfsense IP on say 192.168.1.1 would be allowed this is rfc1918.. 192.168.4.98 or 172.16.3.2 all allowed by the rfc1918 rule..
But now say 192.168.9.42 was trying to go to 1.2.3.4 on the internet.. Well it doesn't trigger the anti-lock out rule, so next rule - well it doesn't match the any to rfc1918 because the destination is not rfc1918 so next rule. Oh hey 192.168.9.42 you trying to go anywhere - sorry buddy, blocked.
There are many different ways to write rules to accomplish something.. By default if its not allowed the default deny would block it.. So all depends on what rule you currently have in place on how to add to either block or allow specific access. Just remember top down.. First rule to match wins..
-
Yes-yes I'm admin (I have a local login and another through https://account.ui.com/login"
... but then, I feel like crap
-
@SwissSteph said in Help with rules to block UniFi Cloudkey Gen2+:
another through https://account.ui.com/login"
Well turn off the remote ability on your cloudkey - look under advanced for what I posted... I don't have a cloudkey to test with..
Your best bet is to check on the unifi docs or forums.. While there are many here that use unifi AP, even switches and prob some that have the cloudkey.. There are way more users on their forums ;)
-
Thanks, I'll keep digging into this "problem"
-
According to your explanations (THANK YOU!) I've created these rules, I think I'm "right"... do you think it's actually OK?
EDIT :
In any case, I have "activity" on these rules
-
@SwissSteph yeah those rules would allow that 1.49 IP to go to any rfc1918 address (or whatever networks you have in that alias) and anywhere else would be blocked. Ie the internet..
-
YES YES YES!!!
Thank you so much for your help and patience
Now all I have to do is try to block entry into my UniFi Cloudkey Gen2+ from the outside, then it would be perfect. Because I could give or not this access ONLY when I want.
But I don't really understand how it works and how to block the Unify site from reaching my Cloudkey.
Now I can still do it...
If anyone has the "magic rule", I'd love to hear from you.
-
@SwissSteph said in Help with rules to block UniFi Cloudkey Gen2+:
how to block the Unify site from reaching my Cloudkey.
unfi is not "reaching" your cloudkey, your cloudkey is creating a connection to them. Unless you setup a port forward on pfsense, or something with a reverse proxy there is no way for unifi to create an unsolicited inbound traffic to talk to your cloudkey..
If you block its access to the internet, at some point their site will show your cloudkey offline.. Might take a bit before they reflect they are no longer talking to your clouldkey.. Make sure you kill any states as well once you created the block rule.
-
I agree.
Thanks for these clarifications, I'll keep an eye on it and if there's still a connection, then I'm the one who authorized it directly in my "Cloudkey". This is possible because I'm not sure I've done everything "right" as soon as it's installed, so I'm going "step by step".
"Unless you setup a port forward on pfsense, or something with a reverse proxy there is no way for unifi to create an unsolicited inbound traffic to talk to your cloudkey"
I don't have a "reverse proxy" or "port specific redirection for unify" ... but I'll keep an eye on it.
Thanks again!
-
@johnpoz
A little feedback ... these two rules work perfectly. Thanks again for your help and happy new year! -
My new feedback, is that by not changing anything to the two rules explained in this topic, in 2024 and using the same applications (only the version is changed) on my phone it is impossible for me to connect as it worked perfectly with OpenVPN ... now nothing works anymore.
Of course, if I remove the two blocking rules above, it works again (probably Unify's "cloud").
In short, the blocking that was perfect in 2023, blocks so well that in 2024 and the changes made by Unify I can no longer connect remotely with my phone (while not at home) and with my OpenVPN on my Pfsense.
As I don't want to let Unify "see all my configurations", do you have a solution?
- keep the rules above that block the "Unify sew".
- find a solution so that Unify Android applications work as before (in 2023).
I find it very hard to understand why everything is blocked when I'm not at home using my Android phone + OpenVPN.
This same phone, on my WiFi at home, works very well with the applications installed on my phone.
If I test (still at home) with OpenVPN -> it no longer works ... so logically with the same OpenVPN from elsewhere it doesn't work.Help!
-
@SwissSteph said in Help with rules to block UniFi Cloudkey Gen2+:
As I don't want to let Unify "see all my configurations", do you have a solution?
Huh? Just disable the Cloudkey from connecting to Unifis Cloud for their remote admin stuff. That's a controller option. Done. Ubiquiti doesn't "read" your configuration. That's nonsense. Also blocking the cloud key from the internet won't show you any updates of your devices and the cloudkey itself, so it's a bit of strange move when you want the stuff to work and get updates but at the same time disabling it's ability to download updates from the official servers?
I simply disabled the remote connection stuff and don't have the option to connect to my cloudkey even when I log into their online portal thingy as it just doesn't connect there. That's more then enough for me.
As for your problem with your OpenVPN - those two things are simply not connected to each other. As we can't predict what rules and stuff you configured, there's no way we could see why your Android via OVPN wouldn't work anymore.
Cheers
-
Thank you for your message and your advice.
"Protect" doesn't work anymore, and this without any configuration change on my Pfsense, it's actually a new version of the "Protect" application that broke this.
On the Ubiquiti forum, there are other messages from members who have exactly the same problem. And no help from official Ubiquiti support.
I'm talking about my configuration where my Pfsense blocks all connections from my "Cloudkey" to the outside and where I used to connect to it without any problem with my OpenVPN and the "Protect" application, now it's impossible (including while on my WiFi)
Yes, updates are no longer offered. If I want them, I disable my two rules on my Pfsense and they come. The latest update https://community.ui.com/releases/UniFi-Switch-6-6-61/8f96bd97-d43b-4387-9b5e-6273f5db54bf seems to break a lot of things, and I'm glad I didn't put this new version on my appliances (anyway I don't leave the updates in "automatic mode" for security reasons ... which not everyone does, as several have had problems waking up).