It is worth pursuing this thread because this was someone two weeks ago facing this same issue but trying to say that option 2 was the "only" option and that a legacy bandaid should be seen as a modern approach. It's an acceptable bandaid in many cases, but it is a 1998 way of fixing things. Legacy by any IT standard. That doesn't make it wrong or bad, but it is old and exists only to fix layers of the same problems.

https://mangolassi.it/topic/24043/vdi-options-modernization

Are you sure that the firewall is the issue? Typically you don't need to allow outbound traffic, that's open by default 99% of the time. Otherwise "nothing" works and you are having loads and loads of issues.

Often asset discovery tools don't work over the WAN, they require an open LAN.

What actual protocol and firewall are we looking at here?

@dashrender said in Help Sorting out a Firewall Issue:

I don't have the full port range open on my Firewall for RTP ports for my phones.

They aren't servers, either.

@dashrender said in Help Sorting out a Firewall Issue:

I thought this is what ALG was supposed to solve (but instead often more frequently breaks).

ALG has no real world purpose. There is no problem to solve.

@mr-jones said in Help Sorting out a Firewall Issue:

Could you expand on why that doesn't make sense? Is port negotiation not a functionality of TCP?

Because you are thinking of WMI as being like HTTP, FTP or SMTP (single protocol.) In all those cases, yes, port negotiation is built in to TCP. But this is why I asked for the protocol details from the beginning, because this is not that simple. This is like SIP.

First, when we talk about port negotiation in TCP the server is always a static port and is always protocol based. It doesn't negotiate, it's published. This is the Port 135 that you know for WMI. WMI then responds on a random port, that's the negotiation.

When you are dealing with HTTP, FTP, etc. that is all that there is.

The port 65849 in your example is not WMI, it is DCOM. The problem here is that DCOM is not published or open. WMI is not using that port. WMI tells the client that it wants them to initiate a DCOM client and reach out to the DCOM server on a dynamic IP (it's dynamic to you and me, it's static to the protocol.)

So the DCOM port needs to be open. Since DCOM has no known port, we'd have to open all available ports for DCOM to listen OR we need the WMI application to be allowed so that whatever ports the DCOM server is using at the moment are open.

WMI is one protocol and working fine. DCOM is another protocol and working fine. Your problem was that you were thinking of DCOM as part of WMI and that's what is confusing you. Either protocol on its own works as expected. What does not work magically is when you have one protocol (WMI, SIP) trying to automate another protocol connection (RTP, DCOM) because the network layer (firewalls, routers, etc.) have no way to know what is going on because it is happen in the application rather than in the network stack. There's no networking involved here, it's literally all inside the application. Not the application layer of the ISO OSI, but the actual application itself.

SIP is exactly the same with RTP. RTP is not a part of SIP. You can use RTP without SIP. You can use SIP without RTP. But by far the most common way is to use then together. SIP is a protocol for negotiating multiple RTP connections, among other things. So SIP is doing a lot. But in a typically phone call you have one SIP connection and two independent RTP connections. So there are three channels of communications going on at any given time.

Each one is independent and which service is the server and which is the client varies based on the channel. And on how the call is set up.

Each individual protocol is solid and straightforward. But when we try to look at them as "phone call" it is super complex. Because it is three individually simple network communications that have to happen coordinated together, in real time, handling lots of traffic, with both sides being client and server.

WMI might as well be a human using the computer. If it were, it would be like this...

WMI server gets request from WMI client. WMI server pops a message on the screen for the user to fire up a temporary DCOM server.

User double clients on "DCOM server", which randomly assigns itself an available port number from a giant pool and tells the user (on the screen) which port number it is.

User takes said port number and goes to Windows firewall and opens that port temporarily. Then the user responds in the WMI app that the port is ready.

The WMI client fires up a DCOM client that connects to newly available DCOM server and does its thing. When it finished, it tells the WMI client to tell the WMI server that it is done.

WMI server receives "finished" message and tells the human looking at the screen that it is done. Human closes DCOM server, then human removes open port from Windows firewall.

That "human" step is really happening, it is just automated with a script. But it's actually happening.

@pmoncho said in MeshCentral - Anyone tried this?:

@scottalanmiller

I misread that. Yeah only 140 agents.

Apparently I am far behind.

We use it pretty extensively

@pete-s said in Help Sorting out a Firewall Issue:

@scottalanmiller said in Help Sorting out a Firewall Issue:

@mr-jones said in Help Sorting out a Firewall Issue:

Could you expand on why that doesn't make sense? Is port negotiation not a functionality of TCP?

Because you are thinking of WMI as being like HTTP, FTP or SMTP (single protocol.) In all those cases, yes, port negotiation is built in to TCP. But this is why I asked for the protocol details from the beginning, because this is not that simple. This is like SIP.

First, when we talk about port negotiation in TCP the server is always a static port and is always protocol based. It doesn't negotiate, it's published. This is the Port 135 that you know for WMI. WMI then responds on a random port, that's the negotiation.

When you are dealing with HTTP, FTP, etc. that is all that there is.

The port 65849 in your example is not WMI, it is DCOM. The problem here is that DCOM is not published or open. WMI is not using that port. WMI tells the client that it wants them to initiate a DCOM client and reach out to the DCOM server on a dynamic IP (it's dynamic to you and me, it's static to the protocol.)

So the DCOM port needs to be open. Since DCOM has no known port, we'd have to open all available ports for DCOM to listen OR we need the WMI application to be allowed so that whatever ports the DCOM server is using at the moment are open.

WMI is one protocol and working fine. DCOM is another protocol and working fine. Your problem was that you were thinking of DCOM as part of WMI and that's what is confusing you. Either protocol on its own works as expected. What does not work magically is when you have one protocol (WMI, SIP) trying to automate another protocol connection (RTP, DCOM) because the network layer (firewalls, routers, etc.) have no way to know what is going on because it is happen in the application rather than in the network stack. There's no networking involved here, it's literally all inside the application. Not the application layer of the ISO OSI, but the actual application itself.

Good points! Actually FTP is also not really straight forward and has a similar mechanism with it's data and control ports - depending on if it's running in active or passive mode.

Ugh true, I should not have mentioned FTP. It's a mess.

@dashrender said in Issue with NGINX passthough TLS:

@scottalanmiller said in Issue with NGINX passthough TLS:

If you are just passing through, what is the point of Nginx? Just use HA-Proxy and set to TCP mode and TLS will pass through flawlessly.

Nginx' purpose is to tear the connection apart and inspect it, breaking TLS pass through.

I didn't know that.

At its core, Nginx is a web server. If you do TCP pass through, you are bypassing the core functionality.

Nginx has TCP pass through capability, so you CAN do this. But it is really intended to be a piece of a bigger picture. WHereas with HA-Proxy, this is its bread and butter and is way simpler.

https://fedingo.com/how-to-configure-ssl-tls-passthrough-in-nginx/

@pete-s said in Why Hyperconverged For Small Business:

@woodbutcher said in Why Hyperconverged For Small Business:

Is there truly a case for a hyperconverged infrastructure for a small business?

Not if you're looking for high availability.

Most small businesses lacks a lot of things to get a fault-tolerant high availability system. You need to look beyond the servers themselves because there are a lot of dependencies that also needs to be highly available. Like network, power, cooling etc.

Look at a commercial datacenter. It's usually redundant all the way through, from one end to the other.

Pete is spot on. The ability to do full HA by a company under 1,000 employees is nearly impossible and almost never valuable. The cost to actually do it is so absurd. But if you move to hosted, it can cost almost nothing. We have HA on things for pennies. The HA discussion is a big piece driving the ERP purchasing decision. WHoever chooses the ERP is the core decision maker about HA. Sounds like they likely decided HA was pretty far from a priority (which is reasonably accurate.)

@woodbutcher said in Why Hyperconverged For Small Business:

The concern with that approach would be minimizing data loss. Primarily transactions in the ERP, though the volume of these transactions is low relative to other companies. But I would guess with proper backups at the DB level, this could be minimized as well if they had to recover via a backup.

Unless you have DB level HA, nothing in your current set up (or in the HA setup!!!) will protect against transactional losses. Only proper database protection does that and nothing being discussed here touches on that.

@woodbutcher said in Why Hyperconverged For Small Business:

That was another thought as well. I don't think their existing 2 node ESXi system is n+1 anyway so they essentially are already in this position, but maybe without extended warranty. Hard to tell as I am just digging in and their internal knowledge is not great.

Easy test...

If you need N+1, you should have HA. If you need HA, it has to be HC.

So it all comes down to answering "is N+1 needed"? Chances are, no. It isn't now. Nor are the most reliable setups being used. So nothing here suggests HA is even on the radar. Going down to a single host will lower cost and, we assume, increase reliability too!

@woodbutcher said in Why Hyperconverged For Small Business:

With redundant PSUs, a healthy RAID setup, incoming power filtering, etc, the failure isn't likely to be a server death sentence. The issue (RAM, CPU, MB, etc.) would be resolved, fire back up the server and go back to making money.

Even on Wall St. that is how they handle it because single servers have better transactional integrity and better overall reliability costs.

SOme resources for your team. For real, sit down and make them watch these...

Youtube Video

@woodbutcher said in Why Hyperconverged For Small Business:

The previous IT guy was not really an IT guy and never took an interest in his job. I think the VAR identified this pretty quickly and are trying to one-up themselves with what they can get away with.

It's a standard model. "Fake" IT guy (or lazy, over his head, politically screwed, fill in the blank here) finds a sales guy that is willing to do something that kind of looks like his job for him, for "free" and gets the company to pay for it. The company gets insanely screwed while the VAR makes loads of money for being unethical, and the "IT guy" gets away without having to do the job he is being paid for. So the company pays double for something they aren't getting at all (IT guidance and protection.)

The tiniest audit or thought from management catches this. It's impossible hide. But it exposes how often CEOs take zero interest in IT and totally ignore it.

@woodbutcher said in Why Hyperconverged For Small Business:

My frustration is that I don't even do this full time and can't find a single drop of value this VAR is adding even though they claim to be experts at this.

That's how sales people work. And that your company had engaged a sales person to be an expert, it is caveat emptor. The sales person isn't pretending not to be a sales person, so 100%, absolutely all fault lies in the management at your company for engaging a sales guy and acting like he's an IT guy. As a business, it is their job to properly engage experts and hire them. And only themselves that are put at risk, so the decision is theirs.

@woodbutcher said in Why Hyperconverged For Small Business:

I'm no slouch but I am also not an IT expert. My background is mostly software development and manufacturing automation but also have experience with things like ERP and MES. Most jobs I take are with small companies and I end up doing or assisting with a lot of the IT work.

Then bringing in a real MSP/ITSP is the proper course of action. A qualified MSP will protect you and save you a ton of money. Going to a VAR means the company is throwing money away to avoid critical thinking. It's a common approach as it is quick, easy and very, very few people point out the obvious flaws in the process so it caters well to hubris.

@carnival-boy said in Why Hyperconverged For Small Business:

I've never really understood the desire for a single over double host.

All about money. If the value of the uptime is less than the cost of the second host, you don't get a second host. That's lost money.

These days, most people (most just being over 51% mind you) can shift the most critical workloads to cloud or desktop or some other holdover temporarily while waiting for a part.

I would say that 90% of my customers don't need a second server, and wouldn't see a single dollar of benefit to it if they had one, because they have other ways to keep the workloads running while the server gets repaired or replaced. And I've almost never had an issue getting parts under SLA because if they don't meet the SLA we get money back and they don't want that to happen. I've done literally thousands of HPE parts replacements (and other vendors too) and I can't remember (although I am sure that they have) them missing their SLA. Generally they would have parts in minutes rather than the four hour SLA period (NYC and Dallas are amazing for parts availability, of course.)

However, all the concerns about licensing should raise red flags about your system. Yes, there are times that having something require licensing is okay or even desired. But you should always see it as a truly huge risk and one that you have to consider carefully. Licensing makes the most sense higher up the stack. For example, the application itself is the most likely object to justify licensing. The cabling is the least. Imagine how ridiculous it would be if your rack, desks, and cables required that you have a special license for each use!! It would be insane and you'd never stand for it (you might have to stand if your chair was licensed only to someone else's butt.)

Your hypervisor and operating system are closer to the cables, rack and desk than they are to the application in this way. These aren't components that you want to have at risk due to a need for licensing. Sometimes you have to, but it is rare and a "have to" would only be caused by an application and if an application puts you in that position for many companies that alone is a reason to question the viability of the developers behind said application.

At a minimum, something like ESXi introduces totally unwarranted complexity and risk and is something that can be quietly, transparently, removed and fixed during this process.