none
Problem with open ports in Windows Firewall

    Question

  • Hello everyone! I'm basically new in managing Windows 2008 Server R2. I'm trying to open a port for a specific application in Windows Firewall (in domain group policies), so I create an "inbound rule" allowing traffic to the specific port. The problem is that the connection is not working. I disabled the firewall, I turn down the antivirus, and the connection is somehow blocked. When I run netstat -an and add the filter to show the "listening" ports, the port that I opened before in the inbound rules is not appearing. I tried with other ports and the results are the same.

    Any idea of what could be the problem?

    Thanks in advance!
    Wednesday, June 15, 2011 5:23 PM

Answers

All replies

  • Use tcpview from Sysinternal/Microsoft to view the process that have open ports.  Verify the process in question actually has the port open.  If not fix the process configuration/installation as needed.
    Thursday, June 16, 2011 12:40 AM
  • I'm trying to open a port for a specific application in Windows
    Firewall (in domain group policies), so I create an "inbound rule"
    allowing traffic to the specific port.

    Which is usually the way to go; just ensure to correctly specify
    the port/protocol and the scope for your rule

    The problem is that the connection is not working. I disabled the
    firewall, I turn down the antivirus, and the connection is somehow
    blocked. When I run netstat -an and add the filter to show the
    "listening" ports, the port that I opened before in the inbound
    rules is not appearing.

    This has nothing to do with the firewall, assuming you're dealing with a TCP port, try running the following

    netstat -oan|find "LISTEN"
    

    then check if the port you want to publish is shown as "LISTENING"
    if that isn't the case, then there is no application listening on such a
    port, so, even if you open it up in the firewall, connections to such a
    port will fail... since there's nothing there to "pick up the phone",
    so,
    first of all ensure that the application which should listen on that
    port is started and working correctly and that the port is shown in
    "LISTENING" state, next, create and enable your firewall rule

    Notice that, in case you're unsure about the port used by the app,
    the above netstat output will still help you; just fire up the task
    manager
    and check the process ID for your app, then look at the netstat list
    and find out which ports belonging to that same PID are in "listening"
    state

    HTH

    Thursday, June 16, 2011 7:32 AM
  • Hi Gunner, thanks a lot for your response. I run tcpview and the proccesses in question are in "Linstening" state.
    Thursday, June 16, 2011 3:57 PM
  • Thanks ObiWan for your response. Yes I was confusing about that, I thought netstat will show the blocked or allowed ports in firewall.

    Ok I get it now. The application i'm using uses a TCP port (that is actually "listening" with the command you mention). To be specific I'm trying to access remotely from a pc in the same lan to a server running SQL Analysis Services. Because I'm using a named instance, I need to allow traffic through TCP port 2382, so this port is "listening" but still has no access from another pc. I know this is another topic, but I want to determine if this is a firewall problem or a SSAS problem.

     

    Thursday, June 16, 2011 4:10 PM
  • Thanks ObiWan for your response. Yes I was confusing about that, I thought netstat will show the blocked or allowed ports in firewall.

    Ok I get it now. The application i'm using uses a TCP port (that is actually "listening" with the command you mention). To be specific I'm trying to access remotely from a pc in the same lan to a server running SQL Analysis Services. Because I'm using a named instance, I need to allow traffic through TCP port 2382, so this port is "listening" but still has no access from another pc. I know this is another topic, but I want to determine if this is a firewall problem or a SSAS problem.

     

     

    Ok, so, start by ensuring your firewall rule is in place and also ensure to enable firewall logging for both, dropped and accepted connections, then, move to another computer (the "client" if you want) and download this program then unzip it into whatever suitable folder and, from a command prompt run the following

     

    sl -bpt 2382 192.0.2.1
    

     


    replacing "192.0.2.1" with your server's IP, the above will scan the server to check if the port 2382 is open (for more infos see the scanline docs); if that isn't the case, go back to the server and check the firewall log, if it's the firewall which blocked the connection you'll see an entry in the log, if, otherwise there won't be any entry, then the "filtering" happens somewhere else

    [edit]

    Forgot; check which IP the port is bound to; if it's listening on 0.0.0.0 then it will answer on any IP but if it's shown as listening on 127.0.0.1 then... I don't think you'll be able to connect to that port from another host :) - also, check the MS SQL security settings and ensure that the analysis service was configured to accept connections from external hosts otherwise the port may even be open/listening, but the service will refuse external connections


    Thursday, June 16, 2011 4:23 PM
  • Just for testing, I turned off the firewall. So I ran scanline from the client and the port is opened. With the firewall turned off (even stopped the service) I still can't access the SSAS server. The server is listening on 0.0.0.0.

    I have a question, where else the "filtering" could be happening?

    I can access SQL Database Engine, but not Analysis Services. I found this thread  http://social.msdn.microsoft.com/forums/en-US/sqlanalysisservices/thread/fe56b6a6-dd02-4488-acba-df2f81aaa098/ a couple days ago, and my problem is exactly the same, because that thread has no response for the problem I thought it might be a Firewall or security problems. I will try to reopen that thread.

    Thursday, June 16, 2011 5:12 PM
  • Well, things can't be worst now! Now I can't access the Database engine! Yesterday I was able to connect to the SQL Database Server with Excel, now I can't, I don't know what I've changed!
    Thursday, June 16, 2011 6:52 PM
  • Just for testing, I turned off the firewall. So I ran scanline from
    the client and the port is opened. With the firewall turned off
    (even stopped the service) I still can't access the SSAS
    server. The server is listening on 0.0.0.0.

    Does the port appear open when the firewall is turned ON ?

    I have a question, where else the "filtering" could be happening?

    Well, not so easy to tell, it depends from "what is between" your
    server and the client, including hardware (network appliances)
    and software (e.g. ipsec policies...)

    I can access SQL Database Engine, but not Analysis Services. I found
    this thread
     http://social.msdn.microsoft.com/forums/en-US/sqlanalysisservices/thr
    ead/fe56b6a6-dd02-4488-acba-df2f81aaa098/ a couple days ago, and my
    problem is exactly the same, because that thread has no response for
    the problem I thought it might be a Firewall or security problems. I
    will try to reopen that thread.

    Hmm... did you look at the "SQL server attack surface configuration" ?

    See, that tool may just forbid connection coming from whatever external
    IP address if the services are configured to only allow local
    connections
    also, and since you're at it, check the SQL server network configuration
    and try disabling the use of dynamic ports (see the SQL server help
    for details)

    Friday, June 17, 2011 8:26 AM
  • Yes, the port appears open when the firewall is turned on as well.

    And yes, I checked the surface configuration, and I disabled the dynamic ports, so I'm using a fixed port.

    Today I tried something else. I tred to connect to another computer that is running Windows 7 and has SQL Server installed and has the exact same configuration as the server. This laptop is on the same LAN as the server. So, I built a cube in that laptop and when I tried connecting remotely it connects with no problems!

    So, definetly, is not a SQL Server configuration problem, I think the problem is with some secuirity problems in Windows 2008. As I said before, this is a test server so there's another roles running like Active Directory and DNS. I remember that when I installed SQL Server on the server it warns me that it was not recommended to install SQL Server on the same server running a DNS, but I don't know if that could be the problem.

    Thanks again!

    Friday, June 17, 2011 10:29 PM
  • Yes, the port appears open when the firewall is turned on as well.

    And yes, I checked the surface configuration, and I disabled the dynamic ports, so I'm using a fixed port.

    Today I tried something else. I tred to connect to another computer that is running Windows 7 and has SQL Server installed and has the exact same configuration as the server. This laptop is on the same LAN as the server. So, I built a cube in that laptop and when I tried connecting remotely it connects with no problems!

    So, definetly, is not a SQL Server configuration problem, I think the problem is with some secuirity problems in Windows 2008. As I said before, this is a test server so there's another roles running like Active Directory and DNS. I remember that when I installed SQL Server on the server it warns me that it was not recommended to install SQL Server on the same server running a DNS, but I don't know if that could be the problem.

    Thanks again!

     

    Hmmm that "on the same LAN" makes me wonder; are you referring to the same "subnet" or to the fact that the computer is in the same AD domain ?

    See, in the first case the issue may be due to some "limitation" imposed by either the firewall or the SQL server "IP allow" lists; in the second the issue may be related to the fact that SQL server is using integrated (AD) authentication and the client machine is unable to correctly authenticate

    Now, given that the issue doesn't seem to be related to "network" (you wrote that the port is open) you may try opening a discussion on the SQL server forum to try solving the issue (in such a case... please post your results here, they may be useful to others with the same kind of issue)

     


    Monday, June 20, 2011 3:59 PM
  • Yes. They're on the same domain.

    I'm really urged do deploy cubes so what i did was installing SQL Server on another server running Windows 2008, and now it works well with no problems!

    I'm assuming that the problem was installing SQL Server on the same server running Active Directory, Group Policies and DNS Services.

    Thanks a lot for all your help!

    Tuesday, June 21, 2011 6:11 PM
  • Just found out the problem! It turns that the PC from where I was trying to connect to the server was connected to the domain but it was still running on a "local" user Windows profile, so I logged off and logged in with an administrator domain account and then I finally could connect with no problems. I think the issue was as you said before, SQL server is using AD authentication, and the client not.
    I thought that setting up "Impersonation info" to the domain administrator account was enough for that, but that wasn't. 
    Thanks for your help again.
    Wednesday, June 22, 2011 10:13 PM
  • So the problem wasn't the ports, it was a logon problem. Go to this thread for the complete solution.

    http://social.technet.microsoft.com/Forums/en-US/sqlanalysisservices/thread/f6a915c6-87e3-4376-8161-158e4c8591ab

     

    • Marked as answer by gus_32 Thursday, June 23, 2011 6:48 PM
    Thursday, June 23, 2011 6:48 PM