UDM Pro vs USG

[VISA MC]

We took over IT at a customer who just had a UDM Pro installed. We previously had a USG in place and all was fine. Another IT firm came and installed a UDM Pro and now some small things aren’t working. I’m not super familiar with the UDM pro, but I wouldn’t think it would be all that different from a USG in terms of settings.

We have a PAX S80 credit card terminal that cannot process transactions or update it’s software. This appears to be an almost factory-default UDM, with an unmanaged switch. We have tried connecting directly to the UDM without success as well.

The topography is super basic (modem connected to UDM, modem in bridge mode with a static IP on the UDM). These card terminals are also extremely basic. It receives it’s IP info correctly via DHCP, including the DNS info. It had a built in ping tool as well that simply pings google.com. This ping is failing. I have tried using 8.8.8.8 as DNS as well as the IP of the UDM. No dice.

Going back to the USG is successful, but the other IT company would prefer to keep the UDM in place due to other access and protect equipment they have installed, but they are not willing to troubleshoot this issue. We do have full access to the UDM.

 

[Sky-Knight]

UDM and UDM Pro are hybrid devices.

They contain a managed switch, WAP, and Cloud key in one box.

There's a problem... the CPU and RAM in the UDM and UDM Pro are BOTH too weak to meet those objectives. Every single UDM I've seen in the field has been heavily CPU bound as a result, and all of them are "fixed" by tossing them in the trash where they belong and replacing them with the appropriate collection of dedicated devices.

UDMs need to die in a fire already. The Pro variant could be fixed, if Ubiquity had the skill to do it, but they don't... And if they do, it's apparent it's tasked elsewhere.

 

[VISA MC]

UDM and UDM Pro are hybrid devices.

They contain a managed switch, WAP, and Cloud key in one box.

There's a problem... the CPU and RAM in the UDM and UDM Pro are BOTH too weak to meet those objectives. Every single UDM I've seen in the field has been heavily CPU bound as a result, and all of them are "fixed" by tossing them in the trash where they belong and replacing them with the appropriate collection of dedicated devices.

UDMs need to die in a fire already. The Pro variant could be fixed, if Ubiquity had the skill to do it, but they don't... And if they do, it's apparent it's tasked elsewhere.

I’ve not been happy at all with the UDM but the issue at hand is confusing. I went screen by screen with my controller and the built in controller and although there are a couple pages that we have that aren’t even present in the UDM, everything seems the same.

It’s a new enough install the other IT firm said the UDM is basically out of the box. I am stumped as to why these machines cannot get out.

 

[timeshifter]

We took over IT at a customer ... but the other IT company would prefer to keep the UDM in place

Huh?

 

[YeOldeStonecat]

We have a few out there in service. We only use them for clients with VERY basic needs. As in...a small business (since we only do businesses) with a network as simple as a home network. No on-prem servers, no multiple static WAN IPs, no port forwarding, etc.

I'm good with them like that.
The "UDM" is Ubiquitis solution to an all in one wireless router....one device is like any Linksys or Netgear wireless home router....with a built in 4x port switch. Has the router to do the firewall duties, and a wireless access point bridged to the LAN swith.
The "UDM-PRO" ...does not have built in wireless. But it has substantial horsepower.

What the UDM's do different than the prior generation Unifi gateways.....is they have a built in controller....do they run the Unifi controller (so you do not need a Cloud Key). However, they can ONLY be managed by this built in controller, they cannot be "informed" to be managed by a hosted controller such as Hostifi. They ALSO come out of the box with Protect video built in.....so you can run Unifis cameras. AND...they also have built in controllers for Access, Phones, and UID (Unifi's new Identity as a Service product). By default those last 3 are not "unbuckled"...so they are not using resources. The built in controller ties in with your Unifi.ui.com portal...where you manage them all. Recent updates in firmware put them on the front page where you see all your Cloud Key Gen2, Gen2 Plus, UDM, and UDM Pro devices...and the legacy old white Cloud Keys are now only visible in a second page....(you'll see a link at the top)....network.unifi.com

I have not found the CPU/RAM to be constrained on these new devices, they both keep up with full gigabit routing even when security services are "turned on". The prior USG would slow down to 85 megs with security on, and the prior USG pro would slow down to 250 megs. So I kinda like them...."for what they are". They've been reliable for us. Again, we keep for simple networks where we don't need full firewalls...else we'll have Untangle out front.

For your terminal issue, I would look at security services...the IDS/IPS for example.

 

[VISA MC]

Huh?

Keep reading…

due to other access and protect equipment they have installed

We don’t deal with door access, RFID stuff or cameras. They put the network in and can’t fix it, so the business owner reached out to me for some help. Sometimes you get a decent AV networking guy but not always.

 

[VISA MC]

For your terminal issue, I would look at security services...the IDS/IPS for example.

Thanks. I’ll look there today and report back.

I have about 175 Unifi deployments in the field, so I would say I am pretty familiar with the controller, I only have one other UDM PRO in the field and they only have a couple of computers a printer and a phone no servers so no port forwarding etc.

 

[YeOldeStonecat]

Speaking of...going around this week upgrading our controllers....to 6.5.53....which itself didn't bring a lot of new stuff, just improvements over a fairly recent 6.4.54 which brought a lot of improvements.

 

[VISA MC]

For your terminal issue, I would look at security services...the IDS/IPS for example.

IPS and global threat management are both disabled.

 

[YeOldeStonecat]

No VLANs I take it? More difficult without a managed switch...and with Unifi....more difficult without a Unifi switch. Just gives you so much more troubleshooting ease, visibility and insight into the network.

Unifi...Clients....any "blocked"?

I did have a client early this past summer, a frozen yogurt place, one of her two CC terminals would frequently fall offline. Swapped out network cables...both on its end, and down in the basement where the patch panel/switch was. Still no help...frequently just fall offline. It would come back if they did a complete power cycle...but that was a pain in the butt for them during busy summer season with a line outside! Anyways...into the Unifi switch I went..the switch port facing that CC terminal, I kicked it down to 100 megs. Maybe even 10 megs..can't remember. CC terminal doesn't need speed. Problem went away. A handful of times over 30 years, I've seen a NIC fail to auto negotiate well...and manually setting something helps out.

 

[VISA MC]

No VLANs I take it? More difficult without a managed switch...and with Unifi....more difficult without a Unifi switch. Just gives you so much more troubleshooting ease, visibility and insight into the network.

Unifi...Clients....any "blocked"?

I did have a client early this past summer, a frozen yogurt place, one of her two CC terminals would frequently fall offline. Swapped out network cables...both on its end, and down in the basement where the patch panel/switch was. Still no help...frequently just fall offline. It would come back if they did a complete power cycle...but that was a pain in the butt for them during busy summer season with a line outside! Anyways...into the Unifi switch I went..the switch port facing that CC terminal, I kicked it down to 100 megs. Maybe even 10 megs..can't remember. CC terminal doesn't need speed. Problem went away. A handful of times over 30 years, I've seen a NIC fail to auto negotiate well...and manually setting something helps out.

I had some time to work on this again today. I confirmed there are no blocked clients and that the global threat management and DPI and Intrusion Detection are all off. I did have the user move the terminal to the UDM and manually forced the port speed down to 100. I had the customer try other credit card devices on the same port and they don't work either, so I have a hard time buying that it's a bunch of bad terminals.

The AV contractor seems to think you have to use a UDM in order to use the Ubiquiti Access or Protect products. I have absolutely no experience with those products. Do you know if this is true? Another option we have is to factory reset the UDM and see if that works. This is a micro network, maybe 2 computers, a printer a couple of IP phones and the ubiquiti access / protect stuff.

 

[YeOldeStonecat]

Yes...above I noted that the UDM has the controller for Protect video, as well as Access, as well as the new Identity system (beta). So it's needed for those.

Certainly worth a try to reset it.

 

[Sky-Knight]

But if you reset it, you blow out the controller... but I suppose rebuilding it from scratch as the only device wouldn't be that big of a deal.

This is starting to sound like a bad wire... has anyone done any testing directly connected?

 

[Tech Savvy]

Did the IP scheme change between your USG and the UDM? Have you looked into what's happening via wireshark?

Is the CC terminal attempting to communicate with a POS system? or is it direct to a payment gateway over the internet? It sounds like its direct to gateway.

One idea that seems basic, but I haven't read it yet, so I figure I'll mention it. Have you tried using another device (e.g. laptop) same switch port, same wire, same ip (only statically set), same dns settings...etc

Might also be silly is maybe the CC terminal has two NICs, one hardwired and one wifi. Wifi might be enabled with static for a different network or bad gateway or maybe the hardwired NIC is set properly to DHCP, but its actually disabled. Embarassingly, I've banged my head against the wall a time or two when looking at the IP Settings on the wrong NIC.

Lastly have you tried a local ping (device on the same network)? By pinging google.com you're going outbound going through DNS, NAT and all, even with 8.8.8.8 you're still NATing and going through the firewall, I'd be curious to see if you can hit something locally.

 

[YeOldeStonecat]

But if you reset it, you blow out the controller...

Yup. But when you take over something from a prior IT person, and get such a weird issue like this, sometimes doing a "nuke 'n pave" and then setting things up how you want.....ends up fixing some issue that is/has been taking way longer to troubleshoot. Never know what the prior person did in there, or the history of the issue. And some of the settings in Unifi when you get to the advanced firewall area, you can go down rabbit holes for a long time looking for something you don't know what it is.

Either snag a backup, reset, and restore, or...just document the settings you need, reset, and go from there. You can backup/restore just the Unifi portion, without impacting the other apps on the integrated controller (Protect, Access, etc).

 

[VISA MC]

This is starting to sound like a bad wire... has anyone done any testing directly connected?

Yes. We have tried multiple cables, multiple machines and direct to the UDM. I also tried forcing the port down to 100 instead of auto negotiation with no dice.

Did the IP scheme change between your USG and the UDM? Have you looked into what's happening via wireshark?

Is the CC terminal attempting to communicate with a POS system? or is it direct to a payment gateway over the internet? It sounds like its direct to gateway.

One idea that seems basic, but I haven't read it yet, so I figure I'll mention it. Have you tried using another device (e.g. laptop) same switch port, same wire, same ip (only statically set), same dns settings...etc

Might also be silly is maybe the CC terminal has two NICs, one hardwired and one wifi. Wifi might be enabled with static for a different network or bad gateway or maybe the hardwired NIC is set properly to DHCP, but its actually disabled. Embarassingly, I've banged my head against the wall a time or two when looking at the IP Settings on the wrong NIC.

Lastly have you tried a local ping (device on the same network)? By pinging google.com you're going outbound going through DNS, NAT and all, even with 8.8.8.8 you're still NATing and going through the firewall, I'd be curious to see if you can hit something locally.

IP Scheme is the same. 192.168.0.1. I have not used wireshark- I thought you needed a hub for that to be able to capture packets for other devices. We use it to open PCAP files from our VOIP customers but I’ve not used it to capture in this case.

No POS here, we are trying to do the terminal’s initial download before it’s deployed. This office is a friend of mine in the payment world so downloading terminals will be common.

I have not tried a static on another device on the same port, I’ll add that to our list for next week.

This terminal does not have WiFi, only dial and Ethernet. Local ping is a great idea, I will try that next week as well!

Also we did a factory reset and even the out of the box config is not allowing the devices to communicate out, and all other computers are working.

I think at this point I am going to try to get ubiquiti to RMA the UDM and replace it. I am out of ideas on this one. These devices are so basic they should work anywhere. I’ve downloaded terminals in some pretty precarious situations, a factory UDM should have no problem with this download.