Diagnostics Console Firewall Information?

[John_Anderson4]

Assume that all traffic is currently blocked between a client PC running Diagnostics Console in remote mode and the OnBase app server running the Diagnostics Service. What firewall rules would need to be added to allow the client PC full access to Diagnostics Console? I believe the traffic is sent from the client to the server on port 8989, but what about the traffic from the server back to the client?

Thanks.

[Mike_Kovacina]

The port for the return traffic is assigned dynamically by the client machine (i.e., Windows) when it a connection is established.

So, for example, when you connect to DiagnosticService:8989, your Windows machine tells the DiagnosticService to send replies to port 12345 (for example) on your machine.  But if your firewall is stateful, it should handle all of this for you.

Are you having problems seeing diagnostic information?

[John_Anderson4]

Yes we were having issues before we totally opened up all ports. The return traffic was being blocked. I'm told our firewalls are stateful (I think the traffic was actually going through 2 firewalls), but it wasn't working. Keep in mind we are using 9.2, if that changes your answer any.

[John_Anderson4]

Also, is there a certain port range it uses for the return traffic? Or could it be literally any valid port?

[Mike_Kovacina]

The port range we are talking about here is the ephemeral port range, and technially it can span from port 1025 to port 65535.  Windows XP had a configurable ephemeral port range of 1025 to 5000.  Windows Vista and beyond have migrated to the IANA standard which is port ranges 49152 to 65535.

So maybe the next step is to try just opening up ports 49152 to 65535 and see if that resolves the issue.  But you did mention that there are two firewalls in play here.  Are you able to determine which firewall is blocking the traffic and why?

TechNet Article - http://support.microsoft.com/kb/929851

[John_Anderson4]

I'm on Windows XP and the app server is Windows 2003.

Here are some firewall logs

CLIENT.3944 > APPSERVER.445: S 2843119526:2843119526(0) win 64240 <mss 1460,nop,nop,sackOK>
APPSERVER.445 > CLIENT.3944: S 3750593918:3750593918(0) ack 2843119527 win 64240 <mss 1460,nop,nop,sackOK>

Here is where the client starts the session with the server using a return port of 3948:
CLIENT.3948 > APPSERVER.8989: S 749967349:749967349(0) win 64240 <mss 1460,nop,nop,sackOK>
APPSERVER.8989 > CLIENT.3948: S 1025434051:1025434051(0) ack 749967350 win 64240 <mss 1460,nop,nop,sackOK>

Here is where the server starts a new session with the client using a return port of 1395. This is why we had to open up all the ports on the firewall. The server is not resuming the same session that the client initiated.
APPSERVER.1395 > CLIENT.3941: S 3415444341:3415444341(0) win 64240 <mss 1460,nop,nop,sackOK>
CLIENT.3941 > APPSERVER.1395: S 841510517:841510517(0) ack 3415444342 win 64240 <mss 1460,nop,nop,sackOK>

CLIENT.3951 > APPSERVER.8989: S 3885830742:3885830742(0) win 64240 <mss 1460,nop,nop,sackOK>
APPSERVER.8989 > CLIENT.3951: S 2114983260:2114983260(0) ack 3885830743 win 64240 <mss 1460,nop,nop,sackOK>

CLIENT.3944 > APPSERVER.445: F 2174:2174(0) ack 1914 win 63903
APPSERVER.445 > CLIENT.3944: F 1914:1914(0) ack 2175 win 63565

I am also opening an official ticket with our first line of support, but if those logs help you at all, please let me know what you find out.

Note that those logs are taken with the firewall open on all ports, so we can get work done. We will need to close it eventually and just have a specific port open for this traffic.

Thanks!