[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1394
  • Last Modified:

How do I find out what incoming connection window firewall is blocking

I have a server application that client machines need to access.   I have gone through and opened the ports and programs that I thought were need to the incoming allow rules, but the clients still can run the server program.  How do I turn logging on for the Firewall (Server 2008 R2) so that I can figure out what Firewall is blocking.  Or what is the easiest way to figure out what programs need to be added to the allow list.

Thanks,
0
vbchewie
Asked:
vbchewie
  • 7
  • 7
1 Solution
 
jason987Commented:
Go to start and then type in "windows firewall" and once in the dialog for that go to "monitoring" and then "firewall".  This will list all of the programs and any inbound and outbound ports allowed.  If you application is in there and the proper ports allowed go back to start and type in "cmd" and then in that window type "netstat -a" and see if there is a line with "listening" on the port the application should be.
0
 
vbchewieAuthor Commented:
The problem is I don't know what it is blocking is there a way for me look an figure what it blocked not what it is blocking.  The Developer is telling me just shut of your firewall,  and I would prefer not to.  So I need to figure out what needs to be allowed so I can keep the firewall on.

Thanks
0
 
jason987Commented:
Well turning off the firewall temporarily is a good step if you can do it because it will isolate whether the issue is the program or the firewall.

Here is the walk-through on how to turn on and view the WinFirewall log, you should only need to turn on the option for blocked connections but for debugging purposes I would do both:

http://technet.microsoft.com/en-us/library/cc947815%28WS.10%29.aspx
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
vbchewieAuthor Commented:
Here is my pfirewall file.  The Client is 192.166.125.138, does this mean I need to open ports 1072 and 1074?

pfirewall.txt
0
 
jason987Commented:
No, port 86 is where they are trying to get to, 1074 is the originating port.
0
 
vbchewieAuthor Commented:
Opening that port did not fix the problem.  Any places I can look for whats getting blocked?
0
 
jason987Commented:
Honestly, dropping the firewall temporarily will move this along much faster.  9/10 times when I see issues like this it is the application/service not listening, accepting connections, or handling them properly.

What did:

"netstat -a"

...produce?  You haven't said what ports the application needs or what protocol it is, that's a huge "step one"
0
 
vbchewieAuthor Commented:
Should I run "netstat -a" with firwall on or off?  The problem is I don't know what ports the application needs thats what I'm trying to figure out the developer is say just completely disable the firewall and I won't have the issue.
0
 
jason987Commented:
You can run netstat with the firewall on or off.  The operation of the firewall simply does not allow incoming connections, the applications or services will still attempt to listen.  If you are in contact with the developer can't they tell you what ports the application listens on?

The tcpview tool will show you what applications are listening or connected which should list your application if it is indeed listening for incoming connections:

http://technet.microsoft.com/en-us/sysinternals/bb897437

Again, turning off the firewall temporarily and testing would be the best way to diagnose if this is a firewall problem and not a application issue.
0
 
vbchewieAuthor Commented:
I'm sorry, I already determined it was the firewall.  If I turn it off the client application connects fine.  I've attached the netstat -a and the highlighted the to programs on TCPView that I know are part of the application.
netstat.txt
TCPView.png
0
 
jason987Commented:
From that:

CCITCP2.EXE is listening for *UDP* connections on port 86.
IMPCSU.EXE is listening for *TCP* connections on port 57196.

The only reason you should need to not have the firewall on is if the application uses different ports for some odd reason.  The TCP/UDP distinction is important.
0
 
vbchewieAuthor Commented:
How did you get the UDP port 86?  I see the TCP 57196.
0
 
jason987Commented:
CCITCP2.exe is listening on local port "mfcobol" which is translated to port 86 as described in:

\Windows\System32\drivers\etc\services

It could point to a different port in services but I verified the port in the netstat log.
0
 
vbchewieAuthor Commented:
Thank you it turned out to be just the UDP port 86. Client Program is working now.
0

Featured Post

Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

  • 7
  • 7
Tackle projects and never again get stuck behind a technical roadblock.
Join Now