Unifi Switch on 2nd LAN

[Mike McCall]

This is one of the problems when trying to learn from searches and reading. I've been reading of the importance of segmenting networks for reasons including security. My reasons include separating bench work access from the main LAN, VOIP, and media streaming. Minimizing the additional traffic is a side benefit, though the network is small enough for that to really be a non-issue.

Though I'm reluctant to claim I know my own name at times, I do know the difference between a VLAN and an IP Network. While I had to memorize the OSI model, there was no context for it or instruction on how to use it in a practical sense. I've tried to make use of a lab to learn some things, but it's weakness is not having anyone to check my work and show me what I missed or got wrong. Many techs get to work for someone else who can help teach them, while others get to "grow-up" on their own. The latter is a longer process. Like many others here I didn't get to have someone mentor me. Not complaining, just noting. I take what I do seriously and want to do it well. More than anything else, that's what I want others to see in me.

 

[Sky-Knight]

It's the information age... who knew getting GOOD information would be the hard part?!?

 

[Mike McCall]

@Sky-Knight Sorry to resurrect an old thread, but this seemed the most appropriate place to put this.

After working for some time now, switch-2 at 10.25.25.69 has lost communication with the controller at 10.58.58.183 and I don't see why.






The controller sees everything on the 10.58.58.xxx LAN, but nothing on the 10.25.25.xxx LAN. Generally fine as I want them separate, but I thought the FW rule:



should allow communication. It worked fine for a while, but now it doesn't and I'm not seeing why.

 

[Sky-Knight]

Only thing I can think to check is your filter rule order. Is the rule you grabbed at the top of the list or the bottom? It needs to be toward the top, at very least needs to be above any rule you made to block traffic from that second network to the first one.

 

[Your PCMD]

Calling @YeOldeStonecat

 

[Sky-Knight]

@Mike McCall, one more thing... config -> network -> Hostname, the domain name field is scstech.com ? I'm also assuming the switch is configured via DHCP, and not static. Though that shouldn't matter much after adoption...

 

[Mike McCall]

@Mike McCall, one more thing... config -> network -> Hostname, the domain name field is scstech.com ? I'm also assuming the switch is configured via DHCP, and not static. Though that shouldn't matter much after adoption...

Thought about the rule order but don't see an issue.



You are correct about the Hostname, which has not changed.



The switch has a static IP.

 

[YeOldeStonecat]

Rob has it all covered...he's one of....if not THE..most knowledgeable peeps re: Untangle that I work with (the other one being one of the top guys at Untangles support...Graeme)

Assuming the IP of the on-prem Unifi controller has not changed..the rules above look proper.
Only other thing I can think of....but it's usually just related to the web admin link....when logging into the Unifi controller, ensure that Untangle is not blocking QUIC (UDP port 443). Which is what Unifi uses to securely proxy your web traffic when working through the Unifi portal. Untangle can have this enabled by default, check...Web Filter...Advanced tab..ensure not check in Block QUIC.

 

[Mike McCall]

Rob has it all covered...he's one of....if not THE..most knowledgeable peeps re: Untangle that I work with (the other one being one of the top guys at Untangles support...Graeme)

Assuming the IP of the on-prem Unifi controller has not changed..the rules above look proper.
Only other thing I can think of....but it's usually just related to the web admin link....when logging into the Unifi controller, ensure that Untangle is not blocking QUIC (UDP port 443). Which is what Unifi uses to securely proxy your web traffic when working through the Unifi portal. Untangle can have this enabled by default, check...Web Filter...Advanced tab..ensure not check in Block QUIC.

Not running the Web Filter in Untangle.

 

[YeOldeStonecat]

For giggles (assuming nothing dangerous currently plugged into your guest/bench networks)..just disable the "block non-wan to non-wan" rule for a short bit and see if it reconnects..and then of course re-enable that rule again.

 

[Mike McCall]

For giggles (assuming nothing dangerous currently plugged into your guest/bench networks)..just disable the "block non-wan to non-wan" rule for a short bit and see if it reconnects..and then of course re-enable that rule again.

No difference. Even restarted the controller. Yes, I've also restarted the switch yesterday but no go.

 

[Mike McCall]

For laughs I'm going to take the network down and restart each device individually and see if that helps.

 

[YeOldeStonecat]

From a computer on the same LAN as switch #2...can you Putty into it? Confirm that it's still good, You can log into it via Putty? Maybe the switch is failing.

 

[Mike McCall]

From a computer on the same LAN as switch #2...can you Putty into it? Confirm that it's still good, You can log into it via Putty? Maybe the switch is failing.

Nope. Every attempt to access the switch including via Putty results in "Connection Refused." Other than resetting & re-adopting the switch I'm stumped. It does continue to function normally otherwise.

 

[YeOldeStonecat]

Nope. Every attempt to access the switch including via Putty results in "Connection Refused." Other than resetting & re-adopting the switch I'm stumped. It does continue to function normally otherwise.

Hmmm...may be worth a hard reset...and re-adoption or manual reprovision.

 

[Mike McCall]

Well, good to know I can still make things worse. I told the controller to "forget" the switch, reset it, turned off all Untangle firewall related rules, restarted the controller, and restarted the switch. Now, it's nowhere to be found. Ubiquity Device Discovery Tool finds nothing. Everything currently resides on the primary 10.58.58.xx LAN However, connect a laptop via Ethernet and it gets a 10.25.25.xx IP address. So, Untangle is still assigning a static IP to the switch at 10.25.25.69. Since the related firewall rules are off, I don't think Untangle is isolating traffic. Shouldn't the controller or Discovery Tool be able to find the switch anyway?

 

[Sky-Knight]

The switch being statically configured introduces a wrinkle... The dns suffix passed out via Untangle's DHCP is determined by that domain name field I had you check. Unifi devices stuff unifi on the front, to make the lookup against the unifi.whatever DNS record you have.

If you go static, and you don't manually enforce the domain on the device itself, you create this condition where the DNS lookup doesn't happen, and the device cannot find the controller. If the device isn't using Untangle as its DNS server, the same thing happens. Which is why I recommend IP reservations for Unifi devices, not static assignment.

If the switch is indeed at defaults, you should see it in the list of DHCP reservations, assuming you documented the MAC address before you told the controller to forget it, you have that to search with. If you didn't then you get to read the sticker on the switch.

The autodiscovery stuff will NOT WORK through a layer 3 boundary, that is a router of any kind. You'll have to plugin to said switch and run it to find it. Once you have it, ssh into it with login ubnt, password ubnt, and you can manually set the inform and get it back online. But, if that process works, and the switch can't find home now... it means something is going on beyond what you've posted here. Because again, it all looks correct.

 

[YeOldeStonecat]

If you move that switch to the first LAN...and see if you can adopt it...just as a test.

 

[Sky-Knight]

@YeOldeStonecat I block QUIC, and never had a problem... But then again the local admin work is all on the same subnet and never subject to the filter. Honestly, I think I'd just bypass TCP 8443 into and out of the controller rather than open up that protocol. Allowing QUIC basically says any Android devices go unfiltered. If you're using a cloud key, why not just bypass the entire device? Not like it benefits from filters, just gets new issues.

 

[Mike McCall]

Ok, so I've removed the static IP from the equation. Then I realized this switch is on a different NIC and its interface is configured like this:



Maybe I need to remove this and start over?