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: th-cam.com/video/3ZxnCtQ31ew/w-d-xo.html
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.
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
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!
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).
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
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.
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?
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
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.
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?
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.
@@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.
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.
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.
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.
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: th-cam.com/video/3ZxnCtQ31ew/w-d-xo.html
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.
You're an exceptional orator, sir! Cleared up a lot of confusion concisely and with great examples. Much appreciated!
Thank you very much! Appreciate you watching!
Spot on Frank! the allow return traffic checkbox implementation is definitely a greatly welcomed addition!
Thanks, Avi! Totally agree, happy to see it added!
But do you need this when you have a separate rule for allow established and related? Perhaps it depends on rule order.
@@jonnyzeeee No, if you have a separate rule, you don't need it (but yes, the order matters).
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
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!
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).
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
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.
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
Great video! Thank you!
Great one! Just save the video! Thank you so much!
So useful thank you
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?
Did you allow return traffic on the untrusted zone?
@@WunderTechTutorials I did.
Is the allow rule above any block rules you created? The allow return traffic rule should be created on the untrusted zone.
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
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.
Thank you.
I'd like to request video about USW-EnterpriseXG-24. Thank you.
I wish I had one!
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?
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.
Correction, when you tag Vlan, you are blocking the traffic in layer 2, aka same broadcast domain.
Agreed, traffic still flows through layer 3 if allowed.
@@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.
Agreed, the vlan section felt incredibly confusing and inaccurate to what I know.
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.
i've learned very nice tips in this video, appreciate it , keep up w the good work !
same. cheers!
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
Fair point. Always forget there are people who have a UDR or UX. My apologies - I'll try and be clearer next time.
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.
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.
Doesn't this guy have the manliest man voice ever. God damn he should be in hollywood.
😂! No better way to start off the day. I wish I felt the same though 😂
You ain’t wrong.