Unifi Switch on 2nd LAN

[Mike McCall]

The objective is to segment my LAN by adding a second Unifi Switch to an existing Untangle box. The Untangle box has 3 available ports. WAN-1, LAN-1, LAN-2 (new). LAN-1 & LAN-2 I want on separate subnets. The Unifi controller runs on a desktop (I know, I know) on LAN-1, so I can't access and adopt it from there.

Just to get it configured I installed another controller on a laptop and got it setup that way. Of course unifi.ubnt.com only sees either network as long as their respective controllers are running. I'm being really cheap about this and don't want to buy cloud keys for each device, nor do I want to spend money on monthly fees to spin something up in the cloud just for this. So, aside from running 2 different controllers on 2 different computers to manage 2 switches on 2 different subnets, what are my (cheap) options?

 

[Sky-Knight]

What do you mean it runs on lan 1 so you can't access it and adopt it from there?

Make the unifi.whatever.local static DNS entry so Untangle can direct all unifi devices at that controller, and make the appropriate firewall rules to allow traffic to get to said controller. Adopt the switch and MOVE ON WITH YOUR LIFE!

You could even... gasp... make the untagged VLAN, your management VLAN, and put everything else on tagged VLANs and have Untangle separate all of that there too!

Stop making this so hard on yourself, Untangle + Unifi = magic! The catch is, you need to understand how Unifi devices use DNS to find their controllers and enable the path. The layer 2 automagic crap is nice, but it's also fragile. You've out grown that path now, and that's 100% if your pain.

 

[Mike McCall]

Well, this is going to hurt. Nevertheless, if I knew how I probably already would have. Instead, my ignorance is on display.

 

[Your PCMD]

The thing I hate is that we still can't utilize both LAN's on the USG's (regular or Pro). If so, I would love to have 2 different networks utilizing existing equipment.

 

[Mike McCall]

It's not the gear, it's the user.

 

[Sky-Knight]

Well, the good news is ignorance can be fixed!

So, for starters I'm assuming two things. 1.) Untangle by default allows all internal networks to communicate with all other internal networks, there are no restrictions. So I assume you know where your restrictions are. 2.) Untangle again by default is the DNS server for all local networks.

Given the two above, the first thing you do is log into Untangle, config -> network -> Hostname. Make a note of the domain name configured at the top. This should be your DNS Suffix for the network. It's example.com by default, but it can be almost anything.



If you have a windows station on the IP network in question, configured via DHCP, you can verify this there with ipconfig /all.



DNS suffix in this case is critical, because all unifi devices will look for unifi.dns.suffix to find their controller. In my case, unifi.intouchtechllc.local

So now back in Untangle, config -> network -> DNS Server

You want to create a Static DNS Entry, for the FQDN discovered above, and feed it the IP address of the machine running the controller. Yes, that machine needs to have a static IP because of this. So kick over to the DHCP Server tab and make a reservation real quick if the platform is DHCP assigned. You can see both in my configuration here:



And again, you want to make sure that IP address is permanent on the device it belongs to, my controller runs on my desktop, so I just kicked over to the DHCP Server tab, and clicked the add static plus next to its reservation to make the static DHCP entry. 10.10.10.125 is my desktop's internal IP all the time now. Also handy for when I use OpenVPN to connect to my home office, I can easily RDP to an easy to remember IP address. Yes, DNS resolution works over the tunnel too, but the IP address is faster to type than either of the DNS names attached to my desktop.

The Unifi Controller uses these ports by default:




Now, for basic functionality there are only two ports up there that matter, TCP 8443 to login to the controller itself, so web access to this needs controlled that's your admin surface PROTECT IT!

The other is TCP 8080, this is known as the "inform port", this is the web service the Unifi devices use to actually communicate with the controller. So, wherever you set the blocks up to prevent LAN 2 from talking to LAN 1, you need to make a pin hole for traffic destined to TCP 8080, and destination address of your Unifi controller.

Once the above is complete, your LAN 2 devices will automatically locate the controller on LAN 1, assuming of course they are actually open and available for adoption. You'll have to reset them to factory if you adopted them on another controller.

And don't ask me about USG's, I HATE USG's, I use Untangle.

P.S. Not sure why I blanked out my public IP address up there, only to leave the 3CX public name, everyone here now has the means to see my public IP address if they are bored and can do a DNS lookup. Perhaps this can be moved to a private thread? I don't want to obfuscate this data any further, it degrades the value, but I don't really want that utterly public either. In theory it shouldn't matter, but my paranoia is acting up.

 

[Mike McCall]

Well, the good news is ignorance can be fixed!

So, for starters I'm assuming two things. 1.) Untangle by default allows all internal networks to communicate with all other internal networks, there are no restrictions. So I assume you know where your restrictions are. 2.) Untangle again by default is the DNS server for all local networks.

Given the two above, the first thing you do is log into Untangle, config -> network -> Hostname. Make a note of the domain name configured at the top. This should be your DNS Suffix for the network. It's example.com by default, but it can be almost anything.

View attachment 11233

If you have a windows station on the IP network in question, configured via DHCP, you can verify this there with ipconfig /all.

View attachment 11234

DNS suffix in this case is critical, because all unifi devices will look for unifi.dns.suffix to find their controller. In my case, unifi.intouchtechllc.local

So now back in Untangle, config -> network -> DNS Server

You want to create a Static DNS Entry, for the FQDN discovered above, and feed it the IP address of the machine running the controller. Yes, that machine needs to have a static IP because of this. So kick over to the DHCP Server tab and make a reservation real quick if the platform is DHCP assigned. You can see both in my configuration here:

View attachment 11235

And again, you want to make sure that IP address is permanent on the device it belongs to, my controller runs on my desktop, so I just kicked over to the DHCP Server tab, and clicked the add static plus next to its reservation to make the static DHCP entry. 10.10.10.125 is my desktop's internal IP all the time now. Also handy for when I use OpenVPN to connect to my home office, I can easily RDP to an easy to remember IP address. Yes, DNS resolution works over the tunnel too, but the IP address is faster to type than either of the DNS names attached to my desktop.

The Unifi Controller uses these ports by default:

View attachment 11236


Now, for basic functionality there are only two ports up there that matter, TCP 8443 to login to the controller itself, so web access to this needs controlled that's your admin surface PROTECT IT!

The other is TCP 8080, this is known as the "inform port", this is the web service the Unifi devices use to actually communicate with the controller. So, wherever you set the blocks up to prevent LAN 2 from talking to LAN 1, you need to make a pin hole for traffic destined to TCP 8080, and destination address of your Unifi controller.

Once the above is complete, your LAN 2 devices will automatically locate the controller on LAN 1, assuming of course they are actually open and available for adoption. You'll have to reset them to factory if you adopted them on another controller.

And don't ask me about USG's, I HATE USG's, I use Untangle.

P.S. Not sure why I blanked out my public IP address up there, only to leave the 3CX public name, everyone here now has the means to see my public IP address if they are bored and can do a DNS lookup. Perhaps this can be moved to a private thread? I don't want to obfuscate this data any further, it degrades the value, but I don't really want that utterly public either. In theory it shouldn't matter, but my paranoia is acting up.

First, thanks for this!

The primary LAN is 10.58.xxx.xxx, and the secondary LAN is 10.25.xxx.xxx. Each is on it's own port on the Untangle box. One cannot see the other. All internal devices look to either 10.58.xxx.xx1 (if that's the LAN they're on), or 10.25.xxx.xx1. Each correlates to their respective LAN ports on the Untangle box.

So, I've set a static DNS entry (SCS.com) and the machine hosting the controller has always been static as well. What do you mean by "...and feed it the IP address of the machine running the controller?"

"Now, for basic functionality there are only two ports up there that matter, TCP 8443 to login to the controller itself, so web access to this needs controlled that's your admin surface PROTECT IT!

The other is TCP 8080, this is known as the "inform port", this is the web service the Unifi devices use to actually communicate with the controller. So, wherever you set the blocks up to prevent LAN 2 from talking to LAN 1, you need to make a pin hole for traffic destined to TCP 8080, and destination address of your Unifi controller."

Ok, so no need to do anything with 8443. To allow traffic from the switch to go to the controller I need to forward TCP8080 to the static ip on the machine running the controller?

I'll have to reset the switch, but not until I have this straight.

BTW, I had been reading where others were talking about making firewall rules, which is what I was initially thinking. Perhaps allowing traffic between the switch IP and the controller IP only. Still want to retain separation.

 

[Mike McCall]

Well, no go yet. Reset the switch and still nothing.

https://help.ubnt.com/hc/en-us/arti...Adoption-Methods-for-Remote-UniFi-Controllers

<whine>Ubiquity recommends spinning up a virtual controller instance on Amazon EC2. Sorry, that sounds like a Rube Goldberg approach to something they could make much easier to do. I realize I'm not the brightest bulb in the box, but this really should be more intuitive. This makes me feel like a complete moron, and that's no fun. This is also why I've drug my feet on segmenting my network, as everything I read suggested it would be convoluted at best.</whine>

 

[Sky-Knight]

We're running face first into assumption 1...

I'll repeat myself, Untangle by default DOES NOT BLOCK anything, from any LAN to any LAN. Which is another way to say 10.58.xxx.xxx can talk to 10.25.xxx.xxx, unless you configured Untangle to stop the communications.

And that is a configuration you did, and you need to make a pin hole in for TCP 8080. If you "blocked" communications by ticking the NAT box on the internal interfaces in Untangle go grab a ruler and slap your own knuckles... bad tech... bad! Use a firewall! This can be either the firewall module, or the filter. Beware, the former only processes TCP and UDP, so you can't test it with ICMP (Ping)! But you get nice logs when it blocks stuff. If you want to stop other protocols back into the filter you go! But the key is, take the shields down, make your stuff work, then lock it down. Work on one thing at a time!

But none of that matters if you don't have a working DNS record to tell devices looking for say unifi.scs.com and having it resolve to the INTERNAL IP address of the controller. You aren't messing with public addresses here, you CAN if you want. But I'm not talking about that, because a publicly exposed port forward for TCP 80 is a security risk with no benefit if all your gear is local. As far as I'm concerned if you're going to publicly forward TCP 8080 to a controller, that controller should be running in a cloud service somewhere. Because at least then in your mind you know... ok... cloud exposed, lock down accordingly, backup accordingly, ect. You CAN forward stuff internally, but why?!? You're adding complexity to things that will break in the future, this is a path to lost hair DON'T DO IT!

And this isn't about you being a bright bulb or not, it's about you missing critical experience with the TCP/IP protocol itself, and DNS, on a very fundamental level. You aren't alone, I've run into many "professionals" in that space. It bugs me personally, because it costs you time and money all over the place and you just don't notice all the pain it brings. That is, until you buy an Untangle from me and wind up on my support line, and I get to take you back to College... or in threads just like this one. But this is also why I love Untangle, something about the product encourages network guys to LEARN how networks actually work. And once you gain that knowledge, everyone else's products come along for the ride too.

And for the record, yes this is how I learned it too... we ALL go through this. And if you're anything like me when the light bulb comes on you WILL feel like a monumental idiot for not understanding this, and so much of your life and the problems you've fixed over the years will shift in your mind and you'll understand just how HUGE this is.

The key thing to note here, this stuff is STUPID SIMPLE. It does exactly what you tell it, and no more. There's no magic, nothing that doesn't directly connect. It's a very literal step by step process. Each dot, connects to a specific other dot, in a continuous line from start to finish. The dots never change... even if the brands on the products that operate the systems represented by the dots do.

And if you're trying to use the same DNS namespace inside your network, as well as outside... well there's some confusion in setting up your first split namespace. Which is a fancy technical term for, if you're on this network, you get these numbers, and if you're on that network you get those. You HAVE to do this if you're using RFC reserved IP ranges, 10.x.x.x, 192.168.x.x, or 172.16.x.x. It's an essential job skill. But you'll notice I use .local internally, .com externally. I can overlap them, but why? To confuse myself?!? Again, you CAN do this, but if you're going to save yourself the headache and do it the new "correct" way. lan.scs.com is your new "domain", for your internal network. Whatever.local as I use it was the "old" way, and it's OK, until Macs show up... .local is a bit of a disputed standard. But as far as DNS is concerned none of this matters, it all can work! What matters is what's easy for YOU to READ, so 10 years from now you see it and go... OK... I know WTF is going on here.

The link you found is good, for clarity I'm describing this path: https://help.ubnt.com/hc/en-us/arti...option-Methods-for-Remote-UniFi-Controllers#6

Because of all the adoption paths, this one path is the one that will ALWAYS work. The devices managed, or the controller can literally be anywhere in the world, if you get that path working, and understand it, you can use it every time with success. Learn this one thing, and Unifi gear opens the floodgates of possibility. Or, confuse yourself with all the other paths they've made that only work in specific circumstances... Personally, I keep more of my hair when I simplify my life by throwing away half completed implementations.

 

[Mike McCall]

We're running face first into assumption 1...

I'll repeat myself, Untangle by default DOES NOT BLOCK anything, from any LAN to any LAN. Which is another way to say 10.58.xxx.xxx can talk to 10.25.xxx.xxx, unless you configured Untangle to stop the communications.

And that is a configuration you did, and you need to make a pin hole in for TCP 8080. If you "blocked" communications by ticking the NAT box on the internal interfaces in Untangle go grab a ruler and slap your own knuckles... bad tech... bad! Use a firewall! This can be either the firewall module, or the filter. Beware, the former only processes TCP and UDP, so you can't test it with ICMP (Ping)! But you get nice logs when it blocks stuff. If you want to stop other protocols back into the filter you go! But the key is, take the shields down, make your stuff work, then lock it down. Work on one thing at a time!

Ok, so here's what I've got:










The IP address is Untangle on the 10.58.xxx.xx LAN


Yes, static IP.



No firewall rules in place to block traffic. It may be stupid simple, but I'm not seeing the obvious then.

 

[Mike McCall]

And this isn't about you being a bright bulb or not, it's about you missing critical experience with the TCP/IP protocol itself, and DNS, on a very fundamental level. You aren't alone, I've run into many "professionals" in that space. It bugs me personally, because it costs you time and money all over the place and you just don't notice all the pain it brings. That is, until you buy an Untangle from me and wind up on my support line, and I get to take you back to College... or in threads just like this one. But this is also why I love Untangle, something about the product encourages network guys to LEARN how networks actually work. And once you gain that knowledge, everyone else's products come along for the ride too.

And for the record, yes this is how I learned it too... we ALL go through this. And if you're anything like me when the light bulb comes on you WILL feel like a monumental idiot for not understanding this, and so much of your life and the problems you've fixed over the years will shift in your mind and you'll understand just how HUGE this is.

The key thing to note here, this stuff is STUPID SIMPLE. It does exactly what you tell it, and no more. There's no magic, nothing that doesn't directly connect. It's a very literal step by step process. Each dot, connects to a specific other dot, in a continuous line from start to finish. The dots never change... even if the brands on the products that operate the systems represented by the dots do.

Don't get me wrong. I appreciate your help! Part of my frustration comes from the recognition I SHOULD have a better grasp of this. I don't expect to be on a par with folks who have been doing large segmented networks fo 20-years, but I agree I should have a better grasp of these more mundane tasks.

FWIW, this is exactly why I consider my Network+ certification utterly useless and let it expire. It's like getting a certificate for graduating kindergarten, yet remaining unprepared for 1st grade.

So, I have an opportunity to upgrade my light bulb, and I'm going to take it.

 

[Sky-Knight]

Your static DNS entry is incorrect, it should be unifi.scs.com And the value of that record should be the LAN IP address that runs the controller.

That's why I pointed you at the hostname field, not to get the full name, but to get the suffix handed out via DHCP! unifi.whateverthatsuffixis.com is the name that all Unifi gear will attempt to resolve to find the controller!

The port forward rule is NOT required, port forwards are for when you've got traffic impacting on Untangle somewhere, and you want to push it elsewhere. The IP address you attached to unifi.scs.com should NOT be on Untangle, therefore this port forward isn't going to fire when you need it to and is instead, opening a hole in your network to your controller from the world that isn't used, isn't required, and isn't secured as a result. Delete the forward rule, it's just confusing you. You need a forward rule for TCP 8080 if and only if you have Unifi devices on the Internet somewhere you want to adopt with this controller!

I see both NAT boxes on your LAN interfaces are NOT checked, GOOD! And I don't see any firewall rules stopping traffic between segments. Which means you're left with filter rules. Config -> network -> filter rules If you have no filter rules, then there is nothing Untangle is doing to stop any device on either of those VLANs from talking to the other. Which means if you can't fire up a laptop on the .25 network, and punch in https://unifi.scs.com:8443 and get the web UI for the controller... you've got issues with something else. Assuming I have this straight, you've obfuscating interior IP addresses, which does you no benefit from a security standpoint, and makes my life harder trying to help you.

Is the controller running on a Windows box? If so, go make sure you have exceptions for all networks and zones for the Unifi controller, or failing that make universal exceptions for any network to connect to 8080 and 8443 on that box. If you don't, the Windows firewall by default will prevent anything from connecting that isn't on the local IP range, this includes ping!

If you have an Active Directory domain this is easy, because you just add both IP ranges to AD Sites and Services and poof, everyone's on the domain profile. But if you don't have a domain, beating the Windows Firewall into submission can be a bit of a chore.

And I hear you on the network+ cert... I took a TCP/IP class in college TWICE. Once for Windows NT 4.0, and again for Windows 2000. I then took several more software development courses, which specifically taught concepts of how software interacted with TCP/IP. And even after all of that as a portion of my BS Degree in SWE... it was still Untangle, and some OpenVPN issues around 12 years ago now when my brain finally connected the dots, saw IP in binary... and I just sat down in a daze for an hour. No joke... and when I started moving again I couldn't help but scream.

The way these concepts are taught is fundamentally incorrect. I really should make a video on this... because I can explain this via voice in a way that will have you dancing in a half hour. But via forum post?!? Not so easy... and I've done the forum post thing HUNDREDS of times.

P.S. Unifi devices that aren't adopted and looking for a controller may need to be restarted to force them to get on the controller. You can also SSH into the things, default login ubnt, ubnt, and use the set-inform command, but honestly... reboots are easier. (Knowing how to use that set-inform is handy though, if you want to get a device on the controller that doesn't have DNS available to automate it! Or, you want to get a device you're staging onto a client's controller that's remote in advance.

 

[Mike McCall]

Your static DNS entry is incorrect, it should be unifi.scs.com And the value of that record should be the LAN IP address that runs the controller.

That's why I pointed you at the hostname field, not to get the full name, but to get the suffix handed out via DHCP! unifi.whateverthatsuffixis.com is the name that all Unifi gear will attempt to resolve to find the controller!

Didn't see that one at all. Changed it to unifi.scs.com, although no actual domain exists. The IP address is the static address of the machine the controller is on.

The port forward rule is NOT required, port forwards are for when you've got traffic impacting on Untangle somewhere, and you want to push it elsewhere. The IP address you attached to unifi.scs.com should NOT be on Untangle, therefore this port forward isn't going to fire when you need it to and is instead, opening a hole in your network to your controller from the world that isn't used, isn't required, and isn't secured as a result. Delete the forward rule, it's just confusing you. You need a forward rule for TCP 8080 if and only if you have Unifi devices on the Internet somewhere you want to adopt with this controller!

Yeah, don't want that, so deleted.

I see both NAT boxes on your LAN interfaces are NOT checked, GOOD! And I don't see any firewall rules stopping traffic between segments. Which means you're left with filter rules. Config -> network -> filter rules If you have no filter rules, then there is nothing Untangle is doing to stop any device on either of those VLANs from talking to the other. Which means if you can't fire up a laptop on the .25 network, and punch in https://unifi.scs.com:8443 and get the web UI for the controller... you've got issues with something else. Assuming I have this straight, you've obfuscating interior IP addresses, which does you no benefit from a security standpoint, and makes my life harder trying to help you.

Is the controller running on a Windows box? If so, go make sure you have exceptions for all networks and zones for the Unifi controller, or failing that make universal exceptions for any network to connect to 8080 and 8443 on that box. If you don't, the Windows firewall by default will prevent anything from connecting that isn't on the local IP range, this includes ping!

There are no filter rules. I can connect a laptop to the the additional LAN and ping https://unifi.scs.com:8443 and it shows the IP address of the machine the controller is on. However, it times out when trying to access the web UI. I restarted the switch as you suggest below and find no difference.

Ok, so the primary LAN is 10.58.58.1/24, and the additional LAN is 10.25.25.1/24. The static IP for the Windows machine with the controller is 10.58.58.183. Netmask for both is 255.255.255.0

If you have an Active Directory domain this is easy, because you just add both IP ranges to AD Sites and Services and poof, everyone's on the domain profile. But if you don't have a domain, beating the Windows Firewall into submission can be a bit of a chore.

No AD domain.

And I hear you on the network+ cert... I took a TCP/IP class in college TWICE. Once for Windows NT 4.0, and again for Windows 2000. I then took several more software development courses, which specifically taught concepts of how software interacted with TCP/IP. And even after all of that as a portion of my BS Degree in SWE... it was still Untangle, and some OpenVPN issues around 12 years ago now when my brain finally connected the dots, saw IP in binary... and I just sat down in a daze for an hour. No joke... and when I started moving again I couldn't help but scream.

The way these concepts are taught is fundamentally incorrect. I really should make a video on this... because I can explain this via voice in a way that will have you dancing in a half hour. But via forum post?!? Not so easy... and I've done the forum post thing HUNDREDS of times.

P.S. Unifi devices that aren't adopted and looking for a controller may need to be restarted to force them to get on the controller. You can also SSH into the things, default login ubnt, ubnt, and use the set-inform command, but honestly... reboots are easier. (Knowing how to use that set-inform is handy though, if you want to get a device on the controller that doesn't have DNS available to automate it! Or, you want to get a device you're staging onto a client's controller that's remote in advance.

It's not my not knowing something that gets me frustrated. There's far too much I don't know. It's being let to believe I have a rudimentary grasp of something (a lame certification for example and what others have taught me here st TN), only to find out I don't just have missing pieces, there's holes the size of the Grand Canyon! One has to consider themselves reasonably proficient at figuring stuff out to be in this business, but that goes out the window at times like this. What should be a simple task on a very small network turns into something that makes me feel like little more than an end user. Once I settle down I stay after it until I learn it, though.

So, I've made the corrections above and can ping https://unifi.scs.com from a laptop on the 10.25.25.1/24 network, but am unable to reach the web UI. Checked the firewall, even checked the settings on Bitdefender to see if it was blocking but didn't see anything. The ping comes back as 10.58.58.1, which is the Untangle interface on the primary LAN...wait, that's wrong! You said it should point to the IP of the controller!

Okay, fixed that and magically able to see and adopt the switch. Very cool, thank you!

Since I want to ensure the branches are unable to talk to each other, is there anything else I need to do? They appear to be blind to each other.

It appears I had the hostname incorrect, and set the static DNS to the Untangle box rather than the machine with the controller. Not big mistakes in themselves, but I failed to recognize them. Initially, I didn't even know DNS was involved as I have no domain and I'm not looking outside my network. Therefore, it seemed, it should have been merely an IP issue. You're right, they don't teach this or teach it poorly, and I'm still scratching my bald head over why I couldn't see it. Except I couldn't see it because I don't know it. I should, but I don't. So, where can I learn it? Apparently not by getting a certification.

Once again, thank you!

 

[Sky-Knight]

Again there is no isolation between the networks! If you want to create that isolation, then you need a firewall rule! Untangle makes this pretty easy...

So the first rule you need is the "halt anything from going between LANs rule" And that is this:



This rule stops any traffic sourced from a non-wan interface, and destined to a non-wan interface. Again, this is the firewall module, which like all rack applications processes ONLY TCP and UDP, ICMP will go straight through it! But, as soon as that rule pops up, your controller is going to lose connectivity to the stuff not on the local network.

So to fix that, you need your pinhole!



This rule says, anything sourced from a LAN interface, and destined to the Unifi controller's IP address, and using the TCP protocol, and terminating on port 8080 PASS, this rule needs to be ABOVE the block rule in the list of firewall rules.

And for the record, scs.com DOES publicly exist, and if you're using that as an internal domain, you'll have problems communicating with it. But, as you can see, you've defined it internally, and it's still working. Why? Because YOUR DNS is responding to those names! Which is how DNS works, is there a record here? Yes?! answer it! No?!? OK, go ask someone else.

 

[Mike McCall]

Again there is no isolation between the networks! If you want to create that isolation, then you need a firewall rule! Untangle makes this pretty easy...

So the first rule you need is the "halt anything from going between LANs rule" And that is this:

View attachment 11245

This rule stops any traffic sourced from a non-wan interface, and destined to a non-wan interface. Again, this is the firewall module, which like all rack applications processes ONLY TCP and UDP, ICMP will go straight through it! But, as soon as that rule pops up, your controller is going to lose connectivity to the stuff not on the local network.

So to fix that, you need your pinhole!

View attachment 11246

This rule says, anything sourced from a LAN interface, and destined to the Unifi controller's IP address, and using the TCP protocol, and terminating on port 8080 PASS, this rule needs to be ABOVE the block rule in the list of firewall rules.

And for the record, scs.com DOES publicly exist, and if you're using that as an internal domain, you'll have problems communicating with it. But, as you can see, you've defined it internally, and it's still working. Why? Because YOUR DNS is responding to those names! Which is how DNS works, is there a record here? Yes?! answer it! No?!? OK, go ask someone else.

So all that makes sense and I've made the rules. I didn't think DNS mattered internally when there's no domain. Apparently it does come into play without a domain, at least in some cases. I suppose I should change my internal domain to something else while I'm at this.

 

[Sky-Knight]

That's one of the features of Untangle that has me totally spoiled... usually you have to make a zone, and then you can stuff names in it. DNSMasq (Untangle's DNS and DHCP service) doesn't require any of that. You can just say hey... this name? Make it resolve THAT address.

You can use it to flush domains down the toilet you don't want anyone connecting to no matter what, or to steal traffic and push it elsewhere. The bad guys do this stuff ALL THE TIME, but the good guys often don't have the tools. Well... you do with Untangle. Or anything else that uses DNSMasq anyway.

But as I mentioned earlier, the "proper" way to name an internal network is lan.domain.com. Based off your public domain name. So were I to setup things for you, I'd use lan.shamrockcomputerservices.com as the domain name, making the Unifi controller live on unifi.lan.shamrockcomputerservices.com.

But in the end it doesn't really matter, the only record your serving is the unifi one, and I doubt you're ever going to need to connect to the real unifi.scs.com. So ho cares?!?

Also I'm not entirely sure how the controller will react to that, I'm pretty sure you can just push a new domain suffix, update the DNS record, and reboot the devices... but it's been awhile since I tinkered with Unifi on that level.

 

[Mike McCall]

I've already changed the name and things are fine. I'll change it again based on your advice this time. So, where's a good place to go and get this right in my head? Any thoughts?

 

[Sky-Knight]

I wish I had one, as I said earlier I need to make videos because in my experience it's all wrong.

I can take you through the binary, due to my software dev background, and show you how a network mask actually works. Once that light comes on, IPv4 or v6... doesn't matter, works the same! After that routing tables get stupid, real stupid. All of a sudden the idea of building those tables with a protocol if you want isn't so hard. Then you move onto DNS, DHCP, and on up the stack.

But that's just the generics, then you have all the vendor specific quirks you pick up over the years, because everyone interprets this stuff differently.

So, what is the difference between 10.58.58.1, and 10.25.25.1? You said both networks are using a /24 mask, but do you know how to convert /24 to 255.255.255.0?

10.58.58.1 is 00001010.00111010.00111010.00000001 in binary. Now the /24 mask, or 255.255.255.0. 255 is 8 1s! So this is easy to convert to binary 11111111.11111111.11111111.00000000. Subnet masks must be all 1s, until they are all 0s. That's why the numbers involved in the decimal representations are always the same! And that's what the 24 means... 24 1s, in a 32bit address, broken up into 8 bit chunks... which means 8 1s or 0s per octet. v6 is the same, but with a 128bit address length! But on binary it works THE EXACT SAME WAY! It's just a longer number. 128 1s, broken up into 8, 16bit chunks expressed in hex instead of decimal.

But again on a binary level it's the same, but back to the 32bit address we're messing with here, again the mask is all 1s until it's 0s.

10000000 = 128
11000000 = 192
11100000 = 224
11110000 = 240
11111000 = 248
11111100 = 252
11111110 = 254
11111111 = 255

Of course the above may not be quite something you come up with if you were never taught how to convert decimal to binary and back again. The programmer mode on the Win10 calculator can do this stuff in a snap, just type in the DEC number and see the output next to BIN on the left. Or click BIN, and type in the binary and see the output next to DEC.

So you have this in binary:

IP: 00001010.00111010.00111010.00000001
SM: 11111111.11111111.11111111.00000000

If the text was fixed width, and they lined up perfectly you'd see now this works... how does IP know when to use the gateway or not? It peels off the bit of the IP address that matches to the 1s in the subnet mask, that's the "network ID". It then compares that bit of the IP to the same chunk of the destination address, does it match? Yes? It's local... No? Ask the local routing table... Default route? Gateway of Last Resort? Translation, IP doesn't have a blasted CLUE what to do with this, so send it HERE. On to the local router the packet goes.

Oh, and the boundaries? The network ID and the host ID portions of the IP address cannot be all 1s, or all 0s.

10.58.58.1 or 00001010.00111010.00111010.00000001

Network ID: 10.58.58 or 00001010.00111010.00111010
Host ID: 1 or 00000001

24bits of network ID grants 2^24 possibilities, or 16,777,216 networks, all the combinations possible with 24 zeros and ones in a line. But remember, they can't be all zeros or ones! So TWO of those possibilities don't work, so you have 2^24-2 use able networks, 16,777,214 of them. But oh wait, Cisco changed that so you CAN use the zero and the one network on the ends... WTF?!?

8bits of host ID grants 2^8 or 256 total addresses, but again all 0s and all 1s doesn't work. So you have 254 usable addresses. That is, 10.58.58.1-254. You can't use 10.58.58.0, and 10.58.58.255 is what? Local broadcast...

And look, even I'm devolving into the "subnet" talk, and that's WRONG. Because it implies a boundary that doesn't exist. CIDR, or class based routing?!? LIES! Again, all the local IP stack does is look at a packet, read the destination address, peel off lengths of bits based on the mask lengths of any records in the local routing table. Then compares them all... got a match? Yes? Off it goes based on the rule in the table that was matched. No? to the default gateway with you!

But you didn't put anything into the routing table of your Untangle?!? Yes you did! When you assigned IP addresses to the local interfaces, and again when you put an address on the WAN interfaces. Even if the address got there via DCHP, it doesn't matter. The fact that IP address exists, and it has a mask with it, and it's attached to an interface on the system, means an entry in Untangle's routing table for that network! The workstations and servers you connect to the LAN? SAME THING! You can see Untangle's routing table in config -> network -> routes. You may have no static routes on the left, or no dynamic routing configred (config -> network -> advanced -> dynamic routing), but you'll still have routes for all the addresses you've assigned to Untangle.

BTW you can see Window's routing table with this command: route print.

 

[Mike McCall]

I'll refer you to this thread from 2015 for a little background.

https://www.technibble.com/forums/threads/unable-to-join-domain.63430/

At that time I was much newer with no real experience with the basics. Many people stepped up and were very helpful explaining some basic principals to me in a way I was able to make use of. Again, this was after obtaining certifications only to learn I learned nothing useful. Yes, I've learned a few thing since then based on what I learned in that thread, but it's all been IP addressing and such on flat LAN's. I'm only now moving into segmentation and the fun that opens up.

Part of the difficulty, as you point out, is they don't teach this well and folks like me come out unprepared for the real world. Like most people, I learn best by doing which means I have to break stuff and quit thinking I should know something by now. Whatever I do know, it isn't as I should know it. But I doubt I'm alone in this.

It seems that having different subnets might be easier on an actual domain. You said Untangle makes this easier as I don't have to set up zones first. I've read where pfSense is much more complicated to setup properly, but my hands-on with it is extremely limited.

I chose to use an additional switch because I knew I'd get in trouble trying to do this using VLAN's for the same reasons I got in trouble here. I preferred the physical separation as well. There are some concepts which have clicked for me, but clearly many others haven't.

 

[Sky-Knight]

Part of the confusion is the overlap of technical terms.

VLAN, IP Network, DNS Domain, AD Domain, AAD Domain, these are all very different things.

And yet the first two get interchanged a lot when people get talking. The and the last two, sit on top of and depend desperately on the 3rd one.

Network segmentation is going out of style because modern networks can handle broadcast storms at higher intensities. With the visibility of a modern switch, it's now trivial to manage thousands of machines on a single IP network. So why deal with the separation? I still segment, with or without AD for various purposes. But it's rarely due to technical or security reasons anymore, it's due to organizational reasons.

The only thing I say should always be isolated is the public wifi space, which every office needs now. That's where the employees stuff their cell phones and the like. You need a dedicated VLAN to the edge, supporting a relatively large IP network to handle that properly.

If you don't know the difference between a VLAN and an IP Network, just remember the layers. VLANs are divisions on layer 2, IP Networks are divisions on layer 3. Usually, the divides are in the same place, but they don't have to be. The OSI model is one of the few commonly taught things that is really important to understand. It's not so much a real thing as it is a mental model to help you categorize network technologies so you can more easily see how they're likely to interact with each other. https://en.wikipedia.org/wiki/OSI_model

Even though it's still weird to me to know that you never... EVER actually send a network packet anywhere...