5 Mistakes New UniFi Users Make (don't make these)

[@WunderTechTutorials]

Since this has come up a few times in the comments, if you set your hardware to use a static IP address, you should modify the DHCP range to ensure the DHCP server doesn't attempt to give out those IP addresses. I go over it in this video if you'd like to see it: kzbin.info/www/bejne/aYvbn3aqhphkm9k

[@sbccave4015]

Can't you just go to client and click fixed ip address?

[@TechMeOut5]

Spot on Frank! the allow return traffic checkbox implementation is definitely a greatly welcomed addition!

[@WunderTechTutorials]

Thanks, Avi! Totally agree, happy to see it added!

[@jonnyzeeee]

But do you need this when you have a separate rule for allow established and related? Perhaps it depends on rule order.

[@WunderTechTutorials]

@@jonnyzeeee No, if you have a separate rule, you don't need it (but yes, the order matters).

[@comptvlee]

You're an exceptional orator, sir! Cleared up a lot of confusion concisely and with great examples. Much appreciated!

[@WunderTechTutorials]

Thank you very much! Appreciate you watching!

[@purmll1762]

Quick question on the static IP tip. I always configure static IPs on the HW but when it comes to DNS, if you’re running something like a PiHole or AdGuard Home config locally on LAN, wouldn’t you want to point the UI HW DNS to that IP so that all traffic traverses the internal PiHole / AdGuard server (which also has pointers to upstream DNS) rather than external ? Thanks

[@WunderTechTutorials]

In my opinion, no. The benefits that Pi-hole/AdGuard provide don't really benefit the hardware. I can understand wanting to monitor them and their DNS requests, but the downside is that they'll lose DNS resolution the same way the rest of your network will in the event of an issue. With this approach, you'd still be able to use the Site Manager because the hardware wouldn't be impacted...assuming it was a DNS issue. With all of that said, this is just my opinion!

[@MacGyver0]

It's correct way IMO, just don't forget to set alternative (second) DNS that points to cloudflare (or what you like). In case of local DNS failure, router will use second fallback address. But don't use local dns (such as ADGuard or PiHole) to specify local dns records, add such records in the router itself. It's kind of a waste of time to manually specify DNS for each local device. Also, ADGuard can provide better DNS resolution speed by resolving from cache (optimistic scheme).

[@Ijaz.s]

Unfortunately, that hasn't been my experience as well as of others online. If you put multiple DNS servers, UDM will split the traffic between both and not do one and then the other. ​@@MacGyver0

[@cejay67]

We always configure to an external provider, never internal. Lose that DNS resolver and you lose connectivity. You’re not doing local lookups anyway, so just point at two external resolvers. Our SOP is to always configure static IP’s, but some of our techs forget.

[@purmll1762]

So use PiHole AdGuard to point the APs and switches to plus DHCP the same to clients /networks BUT UDMP to the externals ? Best of both worlds

[@Taid87]

Should you also set the main router DNS verification from auto to custom? or should this only be set on the switches and access point?

[@nickl8830]

You don't need a fiber cable if they are super far from each other, just get some 10GB SFP RJ45 adapters. Yes, the RJ45 SFP Adapters run hotter than SFP Fiber or a DAC cable, but it would allow you to reach the 10GB bandwidth.

[@WunderTechTutorials]

I'd love to but it's old and very long Cat 5e so I think it needs to be swapped.

[@jonnyzeeee]

Excellent video. Thanks for all your great work. Agree with the need for dynamic dns however unifi’s implementation is lacking IMO. There are no logs to tell you what’s going on. I prefer using a docker container.

[@G8detail]

The uplinks on all your switches should be the default admin VLAN and then just change ports to specific ones or like you said, us profiles? Sorry for the newb question. Great videos!

[@WunderTechTutorials]

From Switches and APs, they should generally be assigned to the management VLAN (if you have one) and allow all (so that you can use them on those switches/APs. There are outlier cases, however, where this might not be the best approach, but in general, that's best.

[@LukeHoersten]

Great video! Thank you!

[@valin0r]

Great information, thanks for this video!

[@wmcomprev]

LAG (Link Aggregation): I haven't yet found where Ubiquiti states what they use for assigning traffic to a particular link. Is it Round Robin, Destination IP, a combination of Source & Destination IP, etc. There are multiple options available. With any of them, except for Round Robin, the problem becomes that the traffic may all be assigned to 1 of the LAG links. This would mean that you're not getting any benefit from the LAG. For example, if only Destination MAC is used to determine which link to place the traffic on, then all traffic going to the Default Gateway would use the same link. (I doubt that Unifi is using only the Destination MAC. This is just being used as an example of how a problem could occur.) It's just that it would be nice to know what Unifi is using to assign traffic to the LAG links. Also, Unifi needs a 3rd DDNS option. They currently allow you to place a DDNS entry of each WAN connection. However, if you have more than one WAN connection and you're trying to VPN back into your network, you will use one of the DDNS entries. Well, what if that WAN link is down? You'd have to change your destination in the VPN to the other DDNS entry. Unifi should have a 3rd DDNS entry. In that 3rd entry, you would tell it which WAN link to consider as Primary. As long as that link is up, then that 3rd DDNS would use the Primary's IP address for DDNS. However, if the Primary link goes down, the 3rd DDNS should update the DDNS entry to show the Secondary WAN's IP Address. When the Primary WAN link returns, this 3rd DDNS would then update the DDNS entry again to point to the Primary WAN's IP Address.

[@brunonovais8801]

I did it of block traffic from my trusted to my cameras. Was awesome!

[@yifeiren8004]

Suggestion, you should not configure DNS that way. Simply go under security and enable HTTPS DNS, that will overwrite whatever the gateway got from for the WANs, and also encrypted

[@WunderTechTutorials]

It's not about the WAN, it's about the LAN. Some people change their default DNS servers to local DNS servers without realizing that it impacts their Switches and APs as well.

[@nicolaslavinicki4029]

Great one! Just save the video! Thank you so much!

[@lammiwinks3775]

8:12 Theres an auto allow return traffic rule you can select on allow rules that does this for you!

[@WunderTechTutorials]

Yep! Very happy they did that.

[@kevinhughes9801]

So useful thank you

[@ronm6585]

Thank you.

[@NoneBusiness-cf1dx]

Having issues with pinging devices in my IoT (UnTrusted) zone from my default (Trusted) zone. Any ideas on how to set up the polices with the new zone based setup?

[@WunderTechTutorials]

Did you allow return traffic on the untrusted zone?

[@NoneBusiness-cf1dx]

@@WunderTechTutorials I did.

[@WunderTechTutorials]

Is the allow rule above any block rules you created? The allow return traffic rule should be created on the untrusted zone.

[@agglad2230]

I'd like to request video about USW-EnterpriseXG-24. Thank you.

[@WunderTechTutorials]

I wish I had one!

[@nicolaslavinicki4029]

I'm looking to buy a U7 Pro, but I've read in the unifi community that many users have and continue to have problems with it. Have you had any problems with the U7 lineup? Could you share your experience?

[@WunderTechTutorials]

So funny enough, I was a little concerned about that too from what I was reading, but I haven't had any problems at all. Nothing from IoT devices to WiFi 7 devices. The WiFi 7 performance is great if I'm close to the AP, and slowly gets worse as I move away from it, but that's just how the 6 GHz band works so that's expected. Overall, very happy with it all.

[@nicolaslavinicki4029]

@@WunderTechTutorials Thank you!

[@jhonattansouza]

i've learned very nice tips in this video, appreciate it , keep up w the good work !

[@LtsPrty]

same. cheers!

[@yifeiren8004]

Correction, when you tag Vlan, you are blocking the traffic in layer 2, aka same broadcast domain.

[@WunderTechTutorials]

Agreed, traffic still flows through layer 3 if allowed.

[@diabilliq]

@@WunderTechTutorials indeed but note it will only flow on whatever is natively tagged on the port aka the untagged VLAN. anything tagged on the port will get dropped.

[@PrymalInstynct]

Agreed, the vlan section felt incredibly confusing and inaccurate to what I know.

[@WunderTechTutorials]

I tried to simplify it because the average user doesn't understand tagged, untagged, layer 2, layer 3, etc. I'll try and explain it better and more technically in a future video.

[@yifeiren8004]

Correction again, when you select Lan In, you are only blocking a device from the source VLAN to the destination. Because that's LAN in from the perspective of the router. So even when you have that rule, the destination VLAN device can still reach to the source VLAN. Because it will be a LAN out traffic.

[@WunderTechTutorials]

If you explicitly allow return traffic, then you're not blocking it in both directions. If you don't, traffic will be blocked in both directions even with only one rule blocking the source from accessing the destination. You can get around it by having a separate rule that allows return traffic, but if you only have one and you don't allow return traffic, it will be blocked.

[@rct6]

The title doesn't really fit the content. The first topic really feels like it is aimed at.intermediate users who have bought a the whole unifia stack

[@WunderTechTutorials]

Fair point. Always forget there are people who have a UDR or UX. My apologies - I'll try and be clearer next time.

[@pablosskates7067]

Doesn't this guy have the manliest man voice ever. God damn he should be in hollywood.

[@WunderTechTutorials]

😂! No better way to start off the day. I wish I felt the same though 😂

[@RoyalFlushFan]

You ain’t wrong.

[@OsmanEden-t3z]

Clickbait