Help Sorting out a Firewall Issue
-
@scottalanmiller said in Help Sorting out a Firewall Issue:
Are you sure that the firewall is the issue?
@scottalanmiller Yea, using "Windows Firewall with advanced security" on Client. Turning it off on client solves the issue, but that's not a solution I'm comfortable deploying across the entire domain.
-
@dashrender said in Help Sorting out a Firewall Issue:
Sounds like Windows firewall is involved.
What software solution are you using to do this inventory?
...SW Web Help DeskAssuming the server is what is reaching out to the client - the client is likely where the incoming random port needs to be open - but that will be challenging since it's a random port. If there is an agent on the client machine - the agent could open the port on the fly.
Yea that was my hang-up, how do you allow a random port number? I tried allowing all traffic from the server IP as a workaround to test it, but either I'm not doing it right, or it doesn't fix the issue. Probably the former.
Mini Remote agent is deployed already in most cases, I'm wondering if there isn't an avenue there.
-
@mr-jones said in Help Sorting out a Firewall Issue:
@scottalanmiller said in Help Sorting out a Firewall Issue:
Are you sure that the firewall is the issue?
@scottalanmiller Yea, using "Windows Firewall with advanced security" on Client. Turning it off on client solves the issue, but that's not a solution I'm comfortable deploying across the entire domain.
OH Okay. That helps narrow down the problem.
Have you added the APPLICATION to the firewall. Rather than a port? Windows Firewall is "meant" to be done that way, so that it monitors the application itself rather than assigning ports statically.
-
@mr-jones said in Help Sorting out a Firewall Issue:
Yea that was my hang-up, how do you allow a random port number?
You don't, that's not a thing. You either have regular TCP communications that does this with the firewall naturally (like how you do with an every day web page) which requires nothing on your end. Or you have a situation like you often get with RTP because SIP sets up the RTP externally and you have to just have all available ports left open. Those are the two options.
EIther you do nothing, or you have to open the potential range.
-
@scottalanmiller said in Help Sorting out a Firewall Issue:
@mr-jones said in Help Sorting out a Firewall Issue:
Yea that was my hang-up, how do you allow a random port number?
You don't, that's not a thing. You either have regular TCP communications that does this with the firewall naturally (like how you do with an every day web page) which requires nothing on your end. Or you have a situation like you often get with RTP because SIP sets up the RTP externally and you have to just have all available ports left open. Those are the two options.
Can you expand on that? I don't have the full port range open on my Firewall for RTP ports for my phones. I thought this is what ALG was supposed to solve (but instead often more frequently breaks). I assumed more modern firewalls were doing a deep packet inspection to see the RTP port and then setting a temporary rule to get that traffic back to the specific internal IP.
If you just left RTP completely open - how would it know which internal IP to go to?
-
Make sure you're not confusing the port on the sender and the port on the receiver.
For instance a web browser connecting to a webserver will use a random port on the client to connect to port 80 or 443 on the server.
The primary reason to allocate a random port in this case is so it can support multiple client connections at the same time.
-
@dashrender I think you are confused.
-
@mr-jones said in Help Sorting out a Firewall Issue:
This is to due with 'Asset Discovery' which the server will perform a TCP handshake with the client, and then hop ports to a random port to collect information about that machine, or at least that's how I understand it.
I'm watching the traffic hit the client on 135, two way TCP traffic on 135, and then a swap of ports to a random port, let's say 63595 incoming to the client from the server, so I'm assuming the handshake went swimmingly. Problem is, as soon as traffic on 63595 is hitting the client from the server, the connection times out.What is defined as the server and what defined as the client here?
I mean it's common to say server when you take about a physical or virtual server and client for a workstation. But when we are talking about client/server communication it's different.
Your description that the communication is hopping to a different random incoming port doesn't really make sense.
-
@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.
-
@dashrender said in Help Sorting out a Firewall Issue:
If you just left RTP completely open - how would it know which internal IP to go to?
You can't port map RTP for your phones like that, so as you figured out, the entire point is moot. That's an unrelated set of issues.
-
@pete-s said in Help Sorting out a Firewall Issue:
@mr-jones said in Help Sorting out a Firewall Issue:
This is to due with 'Asset Discovery' which the server will perform a TCP handshake with the client, and then hop ports to a random port to collect information about that machine, or at least that's how I understand it.
I'm watching the traffic hit the client on 135, two way TCP traffic on 135, and then a swap of ports to a random port, let's say 63595 incoming to the client from the server, so I'm assuming the handshake went swimmingly. Problem is, as soon as traffic on 63595 is hitting the client from the server, the connection times out.What is defined as the server and what defined as the client here?
I mean it's common to say server when you take about a physical or virtual server and client for a workstation. But when we are talking about client/server communication it's different.
Your description that the communication is hopping to a different random incoming port doesn't really make sense.
Agreed - from the description - it seems like the end user device becomes the "server" it's what the server is trying to connect to on a random port. Is that the case?
-
Have you added the APPLICATION to the firewall. Rather than a port? Windows Firewall is "meant" to be done that way, so that it monitors the application itself rather than assigning ports statically.
Damnit, Scott. Take my upvote.
I was able to add a custom rule to allow the Windows Management Instrumentation SERVICE, and that solved it. Now, I know you said APPLICATION, and now I'm wondering if that's basically what you meant, and if not, what the security concern is now that I've whitelisted a whole service. Got some reading to do!
-
@mr-jones said in Help Sorting out a Firewall Issue:
Have you added the APPLICATION to the firewall. Rather than a port? Windows Firewall is "meant" to be done that way, so that it monitors the application itself rather than assigning ports statically.
Damnit, Scott. Take my upvote.
I was able to add a custom rule to allow the Windows Management Instrumentation SERVICE, and that solved it. Now, I know you said APPLICATION, and now I'm wondering if that's basically what you meant, and if not, what the security concern is now that I've whitelisted a whole service. Got some reading to do!
That's the ONLY way you should be doing it if possible. Of course you want the application whitelisted, because if it uses a port, it needs to be open. If it doesn't use a port, it shouldn't be open. There are only security risks to using ports instead of applications. Whitelisting an application is the most secure option short of keeping everything closed and not allowing things to work. Application listing is the minimum necessary. Ports is "more than necessary", except, sometimes it is necessary.
-
The entire point of opening a port is to get access to an application. The problem with opening a port is that if that application crashes, is hijacked, turns off, doesn't start, etc then the port could be used by another service and the port would stay open to it. So there is a risk opening a port rather than just the application. It's a small risk, but it is real. Listing an application is the proper way and the way Microsoft intends. Using ports is a fallback for when you can't do that.
-
@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.
-
@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.
