Help Sorting out a Firewall Issue
-
@dashrender said in Help Sorting out a Firewall Issue:
@mr-jones said in Help Sorting out a Firewall Issue:
Windows Management Instrumentation
Interesting - that is port 135, likely by specifically allowing this port open, when the random port is now needed, WMI tells the firewall and opens it, just like Scott said.
WMI the service, yes. It's a good process.
-
@pete-s I can try to clarify what I meant with some pretend numbers.
Server = Actual server Asset Management is hosted on (192.168.0.20)
Client = Client Machine (192.168.0.50)What I saw on the Network Firewall:
TCP - Server > Client Port 135 (server to client)
TCP - Server <> Client Port 135 (bi-directional)
TCP - Server > Client Port 65849 (server to client) - Time-outI was looking specifically for 192.168.0.20 (server) as SOURCE and 192.168.0.50 (client) as DESTINATION, so it's possible I missed a bit of it.
I would love to take this opportunity to learn a bit on the matter though. Could you expand on why that doesn't make sense? Is port negotiation not a functionality of TCP?
-
@mr-jones said in Help Sorting out a Firewall Issue:
What I saw on the Network Firewall:
TCP - Server > Client Port 135 (server to client)
TCP - Server <> Client Port 135 (bi-directional)
TCP - Server > Client Port 65849 (server to client) - Time-outThat's a bit confusing as a way to think about it. The "server" is your WMI client. The "Client Port" is the WMI server. You always start client > server in any communications because only a server can be listening.
-
@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.
-
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.
-
@mr-jones said in Help Sorting out a Firewall Issue:
I was looking specifically for 192.168.0.20 (server) as SOURCE and 192.168.0.50 (client) as DESTINATION, so it's possible I missed a bit of it.
It's more than semantics that are at play here. Having the client and server components backwards in your mind will also cause confusion with licensing. In a case like this, what you are calling the "server" is really a client - meaning it "reaches out". That is why server licensing is not required for that software and it can run on Windows 10 or 11 legally under proper licensing (as long as nothing else violates licensing.) It is technically not a server at all, so does not trigger any Windows server licensing requirements.
Having the server and client straight semantically also helps a LOT in trying to follow a TCP path. Requester (client) and Listener (server) should not get reversed in your head or trying to figure out firewalls will border on the impossible.
-
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.
-
@scottalanmiller Do you recommend any books that deep dive into this stuff? I know there's always google, but I feel like you would know of some really good reads.
-
@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.
-
@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.
-
@scottalanmiller said in Help Sorting out a Firewall Issue:
@mr-jones said in Help Sorting out a Firewall Issue:
I was looking specifically for 192.168.0.20 (server) as SOURCE and 192.168.0.50 (client) as DESTINATION, so it's possible I missed a bit of it.
It's more than semantics that are at play here. Having the client and server components backwards in your mind will also cause confusion with licensing. In a case like this, what you are calling the "server" is really a client - meaning it "reaches out". That is why server licensing is not required for that software and it can run on Windows 10 or 11 legally under proper licensing (as long as nothing else violates licensing.) It is technically not a server at all, so does not trigger any Windows server licensing requirements.
This is a good point - but does it violate the licensing of the Windows 10/11 clients that it's trying to connect to to get data from?
-
@dashrender 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:
I was looking specifically for 192.168.0.20 (server) as SOURCE and 192.168.0.50 (client) as DESTINATION, so it's possible I missed a bit of it.
It's more than semantics that are at play here. Having the client and server components backwards in your mind will also cause confusion with licensing. In a case like this, what you are calling the "server" is really a client - meaning it "reaches out". That is why server licensing is not required for that software and it can run on Windows 10 or 11 legally under proper licensing (as long as nothing else violates licensing.) It is technically not a server at all, so does not trigger any Windows server licensing requirements.
This is a good point - but does it violate the licensing of the Windows 10/11 clients that it's trying to connect to to get data from?
No, WMI is specifically allowed for that.
-
@scottalanmiller said in Help Sorting out a Firewall Issue:
@dashrender 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:
I was looking specifically for 192.168.0.20 (server) as SOURCE and 192.168.0.50 (client) as DESTINATION, so it's possible I missed a bit of it.
It's more than semantics that are at play here. Having the client and server components backwards in your mind will also cause confusion with licensing. In a case like this, what you are calling the "server" is really a client - meaning it "reaches out". That is why server licensing is not required for that software and it can run on Windows 10 or 11 legally under proper licensing (as long as nothing else violates licensing.) It is technically not a server at all, so does not trigger any Windows server licensing requirements.
This is a good point - but does it violate the licensing of the Windows 10/11 clients that it's trying to connect to to get data from?
No, WMI is specifically allowed for that.
Cool - I only recall file and print services being mentioned in the EULA - but it makes sense that WMI would be available for this purpose as MS themselves use it a lot for this stuff too...
-
@mr-jones said in Help Sorting out a Firewall Issue:
@scottalanmiller Do you recommend any books that deep dive into this stuff? I know there's always google, but I feel like you would know of some really good reads.
It's been so long. Sadly I don't know a good one anymore. I am sure that there are lots, I just don't know which ones are good today.
