General
cancel
Showing results for 
Search instead for 
Did you mean: 

NT 4.0 server try to connect to 192.168.234.235

SOLVED
Go to solution
'chris'
Super Advisor

NT 4.0 server try to connect to 192.168.234.235

hi

NT 4.0 server with MS Exchange 5.5 try all the time to connect via UDP and all possible ports to the following IP address: 192.168.234.235

I don't use this address or range on my network.

How to find out, what's wrong ?

Could be a WINS problem ?

regards
chris

7 REPLIES
Michael Dillman
Valued Contributor

Re: NT 4.0 server try to connect to 192.168.234.235

Have you tried to tracert to the exchange server?
If at first you don't succeed, you must be installing Windows
'chris'
Super Advisor

Re: NT 4.0 server try to connect to 192.168.234.235

yes, if I tracert to this IP address goes to the internet

I think, maybe there is a problem with:
Dell Remote Access Controller (DRAC)

I have many DELL machines.

greetings
chris
Jim Mallett
Honored Contributor
Solution

Re: NT 4.0 server try to connect to 192.168.234.235

You may already have it narrowed down with the DRAC.

If you want to find out what executable is making these connect attempts you can use a free tool called fport. I don't leave home without it:
http://www.foundstone.com/?subnav=resources/navigation.htm&subcontent=/resources/proddesc/fport.htm

If you can narrow down the executable you may be able to find what service or program is causing this (if it's not DRAC).

Jim

Hindsight is 20/20
'chris'
Super Advisor

Re: NT 4.0 server try to connect to 192.168.234.235

thanks, fport it's a nice tool.

does exist fport for linux as well ?

and I will try:

http://support.dell.com/support/edocs/software/smdrac3/RAC/en/is/racugab.htm
http://support.microsoft.com/default.aspx?scid=kb;EN-US;292822

to solve my problem.

greetings
chris
Jim Mallett
Honored Contributor

Re: NT 4.0 server try to connect to 192.168.234.235

For Linux, you can start by looking in the /etc/services file and see if the program is registered there.

There is a program on the HP-UX side that I use called lsof that will do what you want (and more). I did a search for it and found that it's also ported to Linux (but I've never used or tested on that platform):

This version I found appears to need to be compiled if you're comfortable with that:
http://www.mirrors.wiretapped.net/security/host-security/lsof/binaries/linux/proc/i686/2.4.26/

Hmmmm, same site, may be pre-compiled:
http://www.mirrors.wiretapped.net/security/host-security/lsof/

Either way, if you decide you need it you can also just hit a search engine for 'linux lsof download' and I'm sure you'll come back with plenty of options.

Hope this helps....
Jim
Hindsight is 20/20
Antoniov.
Honored Contributor

Re: NT 4.0 server try to connect to 192.168.234.235

Chris,
it's weird this ip is on internet because 192.168.xxx.xxx are reserved for internal use only:
See RIPE whois database
http://www.ripe.net/perl/whois?form_type=simple&full_query_string=&searchtext=192.168.234.235&do_search=Search

Antonio Vigliotti
Antonio Maria Vigliotti
'chris'
Super Advisor

Re: NT 4.0 server try to connect to 192.168.234.235

I think this is the solution:

Here is an very interesting blog from Andy on Dual NIC problems on DELL Servers
Original Source can be found at ; http://cameron-webb.com/blog/archive/2004/04/15/165.aspx


There's a long-standing issue with domain controllers with multiple network interfaces and DNS.

On a normal workstation, or member server, the DHCP Client service is responsible for performing dynamic DNS registrations for the machine. On each network properties page, there is a checkbox â register this connection in DNSâ that controls the DNS registration such that you can have a dedicated monitoring or backup/restore LAN that is not used for normal traffic and is not listed in DNS.

On a domain controller, however, the Netlogon service is responsible for making the DNS registrations and it does not respect the setting of the â register this connection in DNSâ checkbox. This is normally something you can work around through careful configuration of the secondary network addresses, but it still results in extra records in the AD (_msdcs) that can be confusing and increase replication. There is a specific issue that does not have an obvious solution though - Dell servers with the DRAC cards enabled have a virtual network interface for the remote console VNC session connectivity. The address of this interface is 192.168.234.235 on /all/ Dell servers. This causes problems with all the servers on the network because when DNS queries are made for network logons, group policies, etc. one of the results of the query is the 192.168.234.235 address, which is a valid local address!

There are two possible resolutions to this problem:

1. There is now a hotfix available from Microsoft for Windows 2003 that corrects the Netlogon service to properly respect the â register this connection in DNSâ checkbox on the network properties. KB 832478. To make this work for the DRAC problem, there's one further trick once the hotfix is installed. You must open the racdun.pbk file (double click it) which has the network properties of the DRAC virtual interface and uncheck the â register this connection in DNSâ checkbox.

note that if you don't need the remote VNC connection to the console via the DRAC, you can simply disable the DRAC PPP device in Device Manager

2. The racadm utility from Dell can be used to change the IP address of the DRAC virtual interface.

"racadm config -g cfgRacTuning -o cfgRacTuneMnNwIpAddrBase xxx.xxx.xxx.xxx"
Set HKU\.DEFAULT\Software\Dell Computer Corporation\OpenManage\RacWinVnc3\HostIPAddress to be the next IP after xxx.xxx.xxx.xxx on the same network (clas