How Do I determine which process (or program) initiated a TCP SYN_

[Guest]

I have two AD Domain Controllers (DCs) that are repeatedly sending out a TCP
SYN_SENT message to an IP address of 192.1.32.7. These DCs are also
repeatedly sending out ISAKMP (IKE) messages to the same IP address mentioned
earilier. The IP address space of 192.1.32.x/24 used to be our old address
space before we changed it to 172.25.0.0/16.

I would like to know if there is way to determine which process (or program)
is causing these packets to be sent from the DCs to 192.1.32.7?

I checked with my DNS servers (which are hosted on the DCs) and found no
reference to 192.1.32.7.

Any assistance would be greatly appreciated.

 

[Herb Martin]

I have two AD Domain Controllers (DCs) that are repeatedly sending out a TCP
SYN_SENT message to an IP address of 192.1.32.7. These DCs are also
repeatedly sending out ISAKMP (IKE) messages to the same IP address mentioned
earilier. The IP address space of 192.1.32.x/24 used to be our old address
space before we changed it to 172.25.0.0/16.

I would like to know if there is way to determine which process (or program)
is causing these packets to be sent from the DCs to 192.1.32.7?

Yes, but unfortunately some such stuff gets buried in
internal processes of the OS and may not be as definitive
as you would like.

For instance, IKE messages are quite likely being
generated by IPSec (subsystem) and thus due to an (old?)
IPSec filter either locally or from the Group Policy.

But why some application is trying to contact that address
is more obscure.

TCPView v2.34
http://www.sysinternals.com/ntw2k/source/tcpview.shtml
"See all open TCP and UDP endpoints. On Windows NT, 2000 and
XP TCPView even displays the name of the process that owns each
endpoint. Includes a command-line version, tcpvcon."

I checked with my DNS servers (which are hosted on the DCs) and found no
reference to 192.1.32.7.

Any assistance would be greatly appreciated.

 

[Steven L Umbach]

In addition to Herb's fine advice I just want to recommend another
SysInternals tool you may want to try called Tdimon as shown in the link
below which may or may not help based on Herb's reply as difficulty in
tracking down processes. Netdiag /test:ipsec /debug [ Windows 2000 only] may
give info on any configured ipsec policy. Process Explorer from SysInternals
can also display detailed info on a process if you look at it's properties
including tcp/ip info if pertinent and what services belong to that process
which is helpful for the multiple instances of svchost. --- Steve

http://www.sysinternals.com/ntw2k/freeware/tdimon.shtml

I have two AD Domain Controllers (DCs) that are repeatedly sending out a TCP
SYN_SENT message to an IP address of 192.1.32.7. These DCs are also
repeatedly sending out ISAKMP (IKE) messages to the same IP address mentioned
earilier. The IP address space of 192.1.32.x/24 used to be our old address
space before we changed it to 172.25.0.0/16.

I would like to know if there is way to determine which process (or program)
is causing these packets to be sent from the DCs to 192.1.32.7?

Yes, but unfortunately some such stuff gets buried in
internal processes of the OS and may not be as definitive
as you would like.

For instance, IKE messages are quite likely being
generated by IPSec (subsystem) and thus due to an (old?)
IPSec filter either locally or from the Group Policy.

But why some application is trying to contact that address
is more obscure.

TCPView v2.34
http://www.sysinternals.com/ntw2k/source/tcpview.shtml
"See all open TCP and UDP endpoints. On Windows NT, 2000 and
XP TCPView even displays the name of the process that owns each
endpoint. Includes a command-line version, tcpvcon."

I checked with my DNS servers (which are hosted on the DCs) and found no
reference to 192.1.32.7.

Any assistance would be greatly appreciated.

 

[Herb Martin]

In addition to Herb's fine advice I just want to recommend another
SysInternals tool you may want to try called Tdimon as shown in the link
below which may or may not help based on Herb's reply as difficulty in
tracking down processes. Netdiag /test:ipsec /debug [ Windows 2000 only] may
give info on any configured ipsec policy.

Process Explorer from SysInternals
can also display detailed info on a process if you look at it's properties
including tcp/ip info if pertinent and what services belong to that process
which is helpful for the multiple instances of svchost. --- Steve

http://www.sysinternals.com/ntw2k/freeware/tdimon.shtml

Can you say more about tracking use of svchost's? Or is there
more around? (I will re-download the current process viewer
and see if there is anything obvious so feel free to just say that.)

I am often frustrated by an inability to track svchost usage and
problems.

--
Herb Martin

 

[Steven L Umbach]

Sure. For any process, right click to bring up the context menu and select
properties or double click the process. Then you will see a services tab if
that process is related to a service. Svchost of course always will be.
Tlist -s on Windows 2000 will also enumerate svchost process to services.---
Steve

In addition to Herb's fine advice I just want to recommend another
SysInternals tool you may want to try called Tdimon as shown in the link
below which may or may not help based on Herb's reply as difficulty in
tracking down processes. Netdiag /test:ipsec /debug [ Windows 2000 only] may
give info on any configured ipsec policy.

Process Explorer from SysInternals
can also display detailed info on a process if you look at it's
properties
including tcp/ip info if pertinent and what services belong to that process
which is helpful for the multiple instances of svchost. --- Steve

http://www.sysinternals.com/ntw2k/freeware/tdimon.shtml

Can you say more about tracking use of svchost's? Or is there
more around? (I will re-download the current process viewer
and see if there is anything obvious so feel free to just say that.)

I am often frustrated by an inability to track svchost usage and
problems.

 

[Herb Martin]

Sure. For any process, right click to bring up the context menu and select
properties or double click the process. Then you will see a services tab if
that process is related to a service. Svchost of course always will be.
Tlist -s on Windows 2000 will also enumerate svchost process to

services.---

I use Tlist all the time but never noticed the -s switch
(or forgot if I did.)


Actually, mine doesn't do that <grin>. I just tried it,
and I only have one copy so maybe I need to upgrade it.





--
Herb Martin

Steve

In addition to Herb's fine advice I just want to recommend another
SysInternals tool you may want to try called Tdimon as shown in the link
below which may or may not help based on Herb's reply as difficulty in
tracking down processes. Netdiag /test:ipsec /debug [ Windows 2000

only]
may

give info on any configured ipsec policy.

Process Explorer from SysInternals
can also display detailed info on a process if you look at it's
properties
including tcp/ip info if pertinent and what services belong to that process
which is helpful for the multiple instances of svchost. --- Steve

http://www.sysinternals.com/ntw2k/freeware/tdimon.shtml

Can you say more about tracking use of svchost's? Or is there
more around? (I will re-download the current process viewer
and see if there is anything obvious so feel free to just say that.)

I am often frustrated by an inability to track svchost usage and
problems.

--
Herb Martin

I have two AD Domain Controllers (DCs) that are repeatedly sending

out
a

TCP
SYN_SENT message to an IP address of 192.1.32.7. These DCs are also
repeatedly sending out ISAKMP (IKE) messages to the same IP address
mentioned
earilier. The IP address space of 192.1.32.x/24 used to be our old
address
space before we changed it to 172.25.0.0/16.

I would like to know if there is way to determine which process (or
program)
is causing these packets to be sent from the DCs to 192.1.32.7?

Yes, but unfortunately some such stuff gets buried in
internal processes of the OS and may not be as definitive
as you would like.

For instance, IKE messages are quite likely being
generated by IPSec (subsystem) and thus due to an (old?)
IPSec filter either locally or from the Group Policy.

But why some application is trying to contact that address
is more obscure.

TCPView v2.34
http://www.sysinternals.com/ntw2k/source/tcpview.shtml
"See all open TCP and UDP endpoints. On Windows NT, 2000 and
XP TCPView even displays the name of the process that owns each
endpoint. Includes a command-line version, tcpvcon."


I checked with my DNS servers (which are hosted on the DCs) and

found
no

reference to 192.1.32.7.

Any assistance would be greatly appreciated.

 

[Steven L Umbach]

Wow. You must have an old copy. The link below shows the details but is not
Service Pack specific. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;250320

Sure. For any process, right click to bring up the context menu and
select
properties or double click the process. Then you will see a services tab if
that process is related to a service. Svchost of course always will be.
Tlist -s on Windows 2000 will also enumerate svchost process to

services.---

I use Tlist all the time but never noticed the -s switch
(or forgot if I did.)


Actually, mine doesn't do that <grin>. I just tried it,
and I only have one copy so maybe I need to upgrade it.





--
Herb Martin

Steve

In addition to Herb's fine advice I just want to recommend another
SysInternals tool you may want to try called Tdimon as shown in the link
below which may or may not help based on Herb's reply as difficulty in
tracking down processes. Netdiag /test:ipsec /debug [ Windows 2000 only]
may
give info on any configured ipsec policy.


Process Explorer from SysInternals
can also display detailed info on a process if you look at it's
properties
including tcp/ip info if pertinent and what services belong to that
process
which is helpful for the multiple instances of svchost. --- Steve

http://www.sysinternals.com/ntw2k/freeware/tdimon.shtml

Can you say more about tracking use of svchost's? Or is there
more around? (I will re-download the current process viewer
and see if there is anything obvious so feel free to just say that.)

I am often frustrated by an inability to track svchost usage and
problems.

--
Herb Martin



I have two AD Domain Controllers (DCs) that are repeatedly sending out
a
TCP
SYN_SENT message to an IP address of 192.1.32.7. These DCs are
also
repeatedly sending out ISAKMP (IKE) messages to the same IP address
mentioned
earilier. The IP address space of 192.1.32.x/24 used to be our old
address
space before we changed it to 172.25.0.0/16.

I would like to know if there is way to determine which process (or
program)
is causing these packets to be sent from the DCs to 192.1.32.7?

Yes, but unfortunately some such stuff gets buried in
internal processes of the OS and may not be as definitive
as you would like.

For instance, IKE messages are quite likely being
generated by IPSec (subsystem) and thus due to an (old?)
IPSec filter either locally or from the Group Policy.

But why some application is trying to contact that address
is more obscure.

TCPView v2.34
http://www.sysinternals.com/ntw2k/source/tcpview.shtml
"See all open TCP and UDP endpoints. On Windows NT, 2000 and
XP TCPView even displays the name of the process that owns each
endpoint. Includes a command-line version, tcpvcon."


I checked with my DNS servers (which are hosted on the DCs) and found
no
reference to 192.1.32.7.

Any assistance would be greatly appreciated.

 

[Herb Martin]

Found this:
< http://msdn.microsoft.com/msdnmag/issues/02/06/debug/default.aspx >

Had a heck of a time finding TList (until I realized
it is probably in the Debugging tools and might not
be available without the proper product or MSDN
subscription) but this page may have an open version:
< http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx >

Seems to be in the Visual Studio samples, but I haven't
dug it out yet (downloaded though) and didn't find it on
my VS system -- I will dig it out shortly and see if it must
be built (this link probably only works for those with a
subscription):
<
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcsample98/html/vcsmptlist.asp >

--
Herb Martin

Wow. You must have an old copy. The link below shows the details but is not
Service Pack specific. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;250320

Sure. For any process, right click to bring up the context menu and
select
properties or double click the process. Then you will see a services

tab
if

that process is related to a service. Svchost of course always will be.
Tlist -s on Windows 2000 will also enumerate svchost process to

services.---

I use Tlist all the time but never noticed the -s switch
(or forgot if I did.)


Actually, mine doesn't do that <grin>. I just tried it,
and I only have one copy so maybe I need to upgrade it.





--
Herb Martin

Steve


In addition to Herb's fine advice I just want to recommend another
SysInternals tool you may want to try called Tdimon as shown in the link
below which may or may not help based on Herb's reply as difficulty in
tracking down processes. Netdiag /test:ipsec /debug [ Windows 2000 only]
may
give info on any configured ipsec policy.


Process Explorer from SysInternals
can also display detailed info on a process if you look at it's
properties
including tcp/ip info if pertinent and what services belong to that
process
which is helpful for the multiple instances of svchost. --- Steve

http://www.sysinternals.com/ntw2k/freeware/tdimon.shtml

Can you say more about tracking use of svchost's? Or is there
more around? (I will re-download the current process viewer
and see if there is anything obvious so feel free to just say that.)

I am often frustrated by an inability to track svchost usage and
problems.

--
Herb Martin



I have two AD Domain Controllers (DCs) that are repeatedly

sending
out

a
TCP
SYN_SENT message to an IP address of 192.1.32.7. These DCs are
also
repeatedly sending out ISAKMP (IKE) messages to the same IP address
mentioned
earilier. The IP address space of 192.1.32.x/24 used to be our old
address
space before we changed it to 172.25.0.0/16.

I would like to know if there is way to determine which process (or
program)
is causing these packets to be sent from the DCs to 192.1.32.7?

Yes, but unfortunately some such stuff gets buried in
internal processes of the OS and may not be as definitive
as you would like.

For instance, IKE messages are quite likely being
generated by IPSec (subsystem) and thus due to an (old?)
IPSec filter either locally or from the Group Policy.

But why some application is trying to contact that address
is more obscure.

TCPView v2.34
http://www.sysinternals.com/ntw2k/source/tcpview.shtml
"See all open TCP and UDP endpoints. On Windows NT, 2000 and
XP TCPView even displays the name of the process that owns each
endpoint. Includes a command-line version, tcpvcon."


I checked with my DNS servers (which are hosted on the DCs) and found
no
reference to 192.1.32.7.

Any assistance would be greatly appreciated.