Open Ports

January 14, 2008

On a new install of Windows Sever 2003, and firewall not yet setup, are only

certain ports open?? I'm trying to get a usb security key to work so I can

see it on the server from workstations. Do I have to start the firewall in

Windows Server and open the ports I want such as 3047, 1974 even though the

workstations are behind the hardware firewall?

January 14, 2008

Re: Open Ports

On Jan 14, 10:17 am, Todd <T...@discussions.microsoft.com> wrote:

> On a new install of Windows Sever 2003, and firewall not yet setup, are only

> certain ports open?? I'm trying to get a usb security key to work so I can

> see it on the server from workstations. Do I have to start the firewall in

> Windows Server and open the ports I want such as 3047, 1974 even though the

> workstations are behind the hardware firewall?

If you are able to connect directly to the server (without going

through a router/firewall) and the server has no firewall running, you

should be able to connect. How are you trying to connect? Terminal

services/Remote desktop?

If you are passing through a router/firewall you will need to open/

forward proper ports to the server from within the router.

Andrew

January 14, 2008

Re: Open Ports

The security key is plugged into the server and the workstations need to see

it for the software that needs it on the workstations to open up in normal

mode not demo mode. HASP is the security key maker but its for a clock

software and a work clock. If the software on the workstations do see the

key, it opens up in demo mode. The clock place is trying to tell me it in my

network not there software. The only thing between the work stations and the

server is Cisco Catalyst Express 500 switches for voice over IP. I think its

a software issues.....

"Andrew Meador" wrote:

> On Jan 14, 10:17 am, Todd <T...@discussions.microsoft.com> wrote:

> > On a new install of Windows Sever 2003, and firewall not yet setup, are only

> > certain ports open?? I'm trying to get a usb security key to work so I can

> > see it on the server from workstations. Do I have to start the firewall in

> > Windows Server and open the ports I want such as 3047, 1974 even though the

> > workstations are behind the hardware firewall?

>

> If you are able to connect directly to the server (without going

> through a router/firewall) and the server has no firewall running, you

> should be able to connect. How are you trying to connect? Terminal

> services/Remote desktop?

>

> If you are passing through a router/firewall you will need to open/

> forward proper ports to the server from within the router.

>

> Andrew

>

January 14, 2008

Re: Open Ports

On Jan 14, 11:25 am, Todd <T...@discussions.microsoft.com> wrote:

> The security key is plugged into the server and the workstations need to see

> it for the software that needs it on the workstations to open up in normal

> mode not demo mode. HASP is the security key maker but its for a clock

> software and a work clock. If the software on the workstations do see the

> key, it opens up in demo mode. The clock place is trying to tell me it in my

> network not there software. The only thing between the work stations and the

> server is Cisco Catalyst Express 500 switches for voice over IP. I think its

> a software issues.....

>

> "Andrew Meador" wrote:

> > On Jan 14, 10:17 am, Todd <T...@discussions.microsoft.com> wrote:

> > > On a new install of Windows Sever 2003, and firewall not yet setup, are only

> > > certain ports open?? I'm trying to get a usb security key to work so I can

> > > see it on the server from workstations. Do I have to start the firewall in

> > > Windows Server and open the ports I want such as 3047, 1974 even though the

> > > workstations are behind the hardware firewall?

>

> > If you are able to connect directly to the server (without going

> > through a router/firewall) and the server has no firewall running, you

> > should be able to connect. How are you trying to connect? Terminal

> > services/Remote desktop?

>

> > If you are passing through a router/firewall you will need to open/

> > forward proper ports to the server from within the router.

>

> > Andrew- Hide quoted text -

>

> - Show quoted text -

How does the key connect to the server?

How does the software on the workstations know where to find the

key, is there somewhere where you can configure that? Is there some

"agent" on the server that should be finding the key and accepting

requests from the workstations based on a good key being plugged in?

What I'm trying to get at is whether this may be a configuration

issue. From my experience, software on the machine where these kinds

of keys are plugged in are the ones that can see the key, not other

machines. Typically this allows a central component on the 'server'

machine to work (like the timeclock management module) and that module

will take requests from the clients. The central component then

decideswhat level of operation is permissable (full/demo/etc...) If

the key is a usb device and is showing up as a drive, maybe the usb

drive needs to be shared, and the clients software configured to

connect to the share. If network based, clients need IP address and

port of key device? If on a serial or LPT port, I don't know - the

only thing I could think of here is that you would have the central

management structure. Again in this case, maybe the clients need

configured with settings on how to connect to the 'agent', for that

you may need IP/computer name, possibly a port number, and maybe the

'agent' name for it to connect to the 'agent' component.

Have you tried running the client software on the server to see if

it is able to work in full mode there? If not, maybe the key is bad/

corrupt?

Andrew

January 14, 2008

Re: Open Ports

The client software works on the server ok, full mode there. But why do they

want the ports open even ifs all in house and behind the hardware firewall???

"Andrew Meador" wrote:

> On Jan 14, 11:25 am, Todd <T...@discussions.microsoft.com> wrote:

> > The security key is plugged into the server and the workstations need to see

> > it for the software that needs it on the workstations to open up in normal

> > mode not demo mode. HASP is the security key maker but its for a clock

> > software and a work clock. If the software on the workstations do see the

> > key, it opens up in demo mode. The clock place is trying to tell me it in my

> > network not there software. The only thing between the work stations and the

> > server is Cisco Catalyst Express 500 switches for voice over IP. I think its

> > a software issues.....

> >

> > "Andrew Meador" wrote:

> > > On Jan 14, 10:17 am, Todd <T...@discussions.microsoft.com> wrote:

> > > > On a new install of Windows Sever 2003, and firewall not yet setup, are only

> > > > certain ports open?? I'm trying to get a usb security key to work so I can

> > > > see it on the server from workstations. Do I have to start the firewall in

> > > > Windows Server and open the ports I want such as 3047, 1974 even though the

> > > > workstations are behind the hardware firewall?

> >

> > > If you are able to connect directly to the server (without going

> > > through a router/firewall) and the server has no firewall running, you

> > > should be able to connect. How are you trying to connect? Terminal

> > > services/Remote desktop?

> >

> > > If you are passing through a router/firewall you will need to open/

> > > forward proper ports to the server from within the router.

> >

> > > Andrew- Hide quoted text -

> >

> > - Show quoted text -

>

> How does the key connect to the server?

>

> How does the software on the workstations know where to find the

> key, is there somewhere where you can configure that? Is there some

> "agent" on the server that should be finding the key and accepting

> requests from the workstations based on a good key being plugged in?

> What I'm trying to get at is whether this may be a configuration

> issue. From my experience, software on the machine where these kinds

> of keys are plugged in are the ones that can see the key, not other

> machines. Typically this allows a central component on the 'server'

> machine to work (like the timeclock management module) and that module

> will take requests from the clients. The central component then

> decideswhat level of operation is permissable (full/demo/etc...) If

> the key is a usb device and is showing up as a drive, maybe the usb

> drive needs to be shared, and the clients software configured to

> connect to the share. If network based, clients need IP address and

> port of key device? If on a serial or LPT port, I don't know - the

> only thing I could think of here is that you would have the central

> management structure. Again in this case, maybe the clients need

> configured with settings on how to connect to the 'agent', for that

> you may need IP/computer name, possibly a port number, and maybe the

> 'agent' name for it to connect to the 'agent' component.

>

> Have you tried running the client software on the server to see if

> it is able to work in full mode there? If not, maybe the key is bad/

> corrupt?

>

> Andrew

>

January 15, 2008

Re: Open Ports

On Jan 14, 1:08 pm, Todd <T...@discussions.microsoft.com> wrote:

> The client software works on the server ok, full mode there. But why do they

> want the ports open even ifs all in house and behind the hardware firewall???

>

> "Andrew Meador" wrote:

> > On Jan 14, 11:25 am, Todd <T...@discussions.microsoft.com> wrote:

> > > The security key is plugged into the server and the workstations need to see

> > > it for the software that needs it on the workstations to open up in normal

> > > mode not demo mode. HASP is the security key maker but its for a clock

> > > software and a work clock. If the software on the workstations do see the

> > > key, it opens up in demo mode. The clock place is trying to tell me it in my

> > > network not there software. The only thing between the work stations and the

> > > server is Cisco Catalyst Express 500 switches for voice over IP. I think its

> > > a software issues.....

>

> > > "Andrew Meador" wrote:

> > > > On Jan 14, 10:17 am, Todd <T...@discussions.microsoft.com> wrote:

> > > > > On a new install of Windows Sever 2003, and firewall not yet setup, are only

> > > > > certain ports open?? I'm trying to get a usb security key to work so I can

> > > > > see it on the server from workstations. Do I have to start the firewall in

> > > > > Windows Server and open the ports I want such as 3047, 1974 even though the

> > > > > workstations are behind the hardware firewall?

>

> > > > If you are able to connect directly to the server (without going

> > > > through a router/firewall) and the server has no firewall running, you

> > > > should be able to connect. How are you trying to connect? Terminal

> > > > services/Remote desktop?

>

> > > > If you are passing through a router/firewall you will need to open/

> > > > forward proper ports to the server from within the router.

>

> > > > Andrew- Hide quoted text -

>

> > > - Show quoted text -

>

> > How does the key connect to the server?

>

> > How does the software on the workstations know where to find the

> > key, is there somewhere where you can configure that? Is there some

> > "agent" on the server that should be finding the key and accepting

> > requests from the workstations based on a good key being plugged in?

> > What I'm trying to get at is whether this may be a configuration

> > issue. From my experience, software on the machine where these kinds

> > of keys are plugged in are the ones that can see the key, not other

> > machines. Typically this allows a central component on the 'server'

> > machine to work (like the timeclock management module) and that module

> > will take requests from the clients. The central component then

> > decideswhat level of operation is permissable (full/demo/etc...) If

> > the key is a usb device and is showing up as a drive, maybe the usb

> > drive needs to be shared, and the clients software configured to

> > connect to the share. If network based, clients need IP address and

> > port of key device? If on a serial or LPT port, I don't know - the

> > only thing I could think of here is that you would have the central

> > management structure. Again in this case, maybe the clients need

> > configured with settings on how to connect to the 'agent', for that

> > you may need IP/computer name, possibly a port number, and maybe the

> > 'agent' name for it to connect to the 'agent' component.

>

> > Have you tried running the client software on the server to see if

> > it is able to work in full mode there? If not, maybe the key is bad/

> > corrupt?

>

> > Andrew- Hide quoted text -

>

> - Show quoted text -

The ports wouldn't have to be 'open' in that case. That's the

reason I asked if the server was behind any routers, firewalls, or the

such. If they have an 'agent' running on the server that listens on

that port, then it's accessible on that server period. It's like: I

think therfore I am :) If the agent listens on that port, then it just

is. The issue of whether a port is 'open' has to do with firewalls,

routers, and such as they filter communications based on ports, IP

addresses, content, etc... Routers/firewalls do not typically allow

any traffic routed to any port, that is not specifically 'opened'.

Say you have this scenario; a server named 'websvr1' with web

server software running on it that has been configured to listen to

port 80. The web server software on 'Websvr1' is then 'listening' on

port 80 for http requests. If the server has no firewall running on

it, then it will respond to any http port 80 traffic that reaches it.

So long as a TCP/IP connection can be made to 'websvr1' and an http

client (web browser) makes a request of 'websvr1's IP address on port

80, the web server application will get the request.

However, put that server behind a router with port 80 turned off,

or 'closed', a client on the other side of that router/firewall will

not get through to the server because the router/firewall is not

passing the request through. It is considered unacceptable traffic. If

you configure the router/firewall to 'open' port 80, when a request

comes in aimed at 'websvr' using port 80, the router/firewall will

allow the request through and the request will make it to 'websvr'

which will then reply because the web server software on 'websvr' is

listening for traffic on that port.

Firewalls can be separate from routers and such. They can be

hardware based like many routers and such, but can also be software

installed in the operating system (like Microsoft Windows Firewall).

You can have both, a router with a firewall and a software firewall on

the computer (this is not uncommon).

If a firewall (that has port 80 closed) were running on 'websvr1',

local traffic (same subnet as the server) will make it the 'websvr',

but the firewall software will not pass the request through to the

listening web server application. If the router has port 80 open, a

request could make it from the client, through the router, to

'websvr', and then be killed by the firewall. Or, reverse this. If the

router has port 80 closed and the server's firewall has port 80 open,

clients on the opposite side of the router would not get their port 80

requests to the server, but clients on the same side of the router as

the server would get a response becasue they were passed through the

firewall (because it was open on port 80).

If port 80 is open on the router and the software firewall, then

requests from either side of the router would be successful.

But, like I said earlier, if you have no firewalls, routers,

gateways, etc... that may be blocking the port you need to use, then

it should work, the 'agent' is just listening for that traffic,

period. If your client is on the same network (same subnet) and there

is no firewall software running on the server, this should work. The

only other way I could see it not working is if for some reason the

'server' is pushing the application access level traffic to the

workstations vs. the workstations requesting the access level

information from the server 'agent'. This would be an odd approach,

but in this case, it would be an issue if the workstations had a

firewall running on them that is not allowing the port you are using

to pass through.

Are you sure that the Microsoft Firewall is not running on the

server or clients (I still think the client side would be unusual, but

hey...)? You may try turning the firewall software off on a test

client to check this possibility. If that works, you can configure the

Microsoft Firewall to allow specified ports to be opened up.

Are you running any McAfee, Norton, or other virus scanning items

on the server which may have a firewall component to it?

Being that the client part of your application works directly on

the server and it is supposed to work in this structure (key on server

only, clients able to run by contacting some server 'agent' over some

specified port using TCP/IP) then there must be some filtering going

on. I would assume the filtering/blocking would be on the server by

some firewall function, or again, so long as there is no router/

gateway/firewall things between the client computer(s) and server that

are blocking the port. If you are sure that none of this is the

problem the only thing left is client firewalls. If you test that idea

and still no deal, then I'm lost without more details on this from the

company who designed it, like setup instructions, tech support, etc...

Let me know what you find... I'de like to see what this turns out

to be. I am very inclined to think it is a software based firewall on

the server though - at least at this point.

Andrew

January 15, 2008