NetTalk Central

Author Topic: IP address/port conflict  (Read 9268 times)

Jane

  • Sr. Member
  • ****
  • Posts: 372
  • Expert on nothing with opinions on everything.
    • View Profile
    • Email
IP address/port conflict
« on: March 16, 2017, 07:12:33 AM »
I have a nettalk web app running on a server that has multiple IP addresses.

I've restricted the nettalk app to only one address.  And it correctly responds only to that one - ignoring loopback or the other routable IP.

My problem is that I tried installing IIS on that machine on the other IP address.  It refuses to start on port 80.  It will start on another port, or if I kill the nettalk app.

So I'm *guessing* the nettalk app is actually reading port 80 from all the IPs on that machine, but only actually responding to the one that's selected?

I wound up installing IIS on a different server, but wonder whether there's a way to do what I was trying to??

Thanks for any info.

-- Jane

mmelby

  • Newbie
  • *
  • Posts: 35
    • View Profile
    • Email
Re: IP address/port conflict
« Reply #1 on: March 16, 2017, 12:02:22 PM »
I have IIS and a NetTalk app running on the same PC with no issues. I would install IIS without the NT app running. I would then verify that the NT app is not using port 80.

If you are still having issues you might want to run the netstat command to see what other program might be using port 80.
« Last Edit: March 16, 2017, 12:05:11 PM by mmelby »

Jane

  • Sr. Member
  • ****
  • Posts: 372
  • Expert on nothing with opinions on everything.
    • View Profile
    • Email
Re: IP address/port conflict
« Reply #2 on: March 16, 2017, 01:27:55 PM »
Yes the nettalk app is using port 80.

But only on one IP.

IIS should use port 80 on the other IP.

kevin plummer

  • Hero Member
  • *****
  • Posts: 1195
    • View Profile
    • Production Accounting and Software Payroll
Re: IP address/port conflict
« Reply #3 on: March 16, 2017, 08:42:33 PM »
did you bind nettalk to the IP Address? The setting is the same place in the templates that you set the port to listen on and set ssl etc.

mmelby

  • Newbie
  • *
  • Posts: 35
    • View Profile
    • Email
Re: IP address/port conflict
« Reply #4 on: March 20, 2017, 05:25:44 AM »
Sorry, I did not see the multiple IP addresses part. To add to Kevin, you also need to bind IIS to the specific IP you want as the default is for "All Assigned"

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11250
    • View Profile
Re: IP address/port conflict
« Reply #5 on: March 21, 2017, 03:10:36 AM »
>> So I'm *guessing* the nettalk app is actually reading port 80 from all the IPs on that machine, but only actually responding to the one that's selected?

That would be incorrect.
you can test this yourself - make 2 examples (with NetTalk), bind both to different IP addresses then run both.

I suspect you just need to bind IIS to the other address as well.

cheers
Bruce


bshields

  • Sr. Member
  • ****
  • Posts: 392
    • View Profile
    • Inhabit
    • Email
Re: IP address/port conflict
« Reply #6 on: March 22, 2017, 01:55:40 AM »
Hi Jane,

You can be a little more precise about what program is bound to what IP.

Run task manager and show the PID (Process ID) column (Menu | View | Select Columns). Make a note of your processes PID.

Go to command prompt, type netstat -a -o

You'll see a lot of stuff (especially if the machine is in production).

Look at the "State" column for LISTENING, ignore all the other stuff.

Then check the IP address to the left.

[::] means any IP

So

TCP  [::]:80            YOURMACHINE              LISTENING            1111

 - means that PID 1111 is bound to all IPs on port 80.

or say

TCP  192.168.0.2:443      YOURMACHINE             LISTENING           1111

- means that PID is bound to 192.168.0.2 on port 443.

More importantly you can find out what IIS and other servers are up to on your machine.

Removes the guess work.

Regards
Bill

Jane

  • Sr. Member
  • ****
  • Posts: 372
  • Expert on nothing with opinions on everything.
    • View Profile
    • Email
Re: IP address/port conflict
« Reply #7 on: March 23, 2017, 11:58:43 AM »
Thanks, guys.

Here's some more info.

Simple IPCONFIG:

C:\Windows\system32>ipconfig

Windows IP Configuration


Ethernet adapter Ethernet0:

   Connection-specific DNS Suffix  . :
   Link-local IPv6 Address . . . . . : fe80::598f:9611:c008:5369%12
   IPv4 Address. . . . . . . . . . . : 10.15.12.15
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   IPv4 Address. . . . . . . . . . . : 10.15.12.114
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.15.12.1


Bruce, perhaps I'm setting the limiting IP for the nettalk service in the wrong place.  I'm reading from an INI file, and then setting it as shown here:



In this case, setting its IP to 10.15.12.15

Trying to set IIS binding to using 10.15.12.114:80 as shown here:


netstat -a -o does just show 10.15.12.15:80, as Bill suggests.

If I temporarily set IIS to a different port (88) and set the binding to all addresses rather than to the specific IP I want, then (as BIll also suggests) netstat shows [::]:88

So from that standpoint, I'm even more confused. 

Unfortunately, I can't play with it much during the day because the nettalk app is heavily used.

It's not a major issue... I've moved IIS onto a different server.  Just trying to understand what I might be able to do differently in the future.

Thanks for the suggestions, and any others!

Jane

Bruce

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 11250
    • View Profile
Re: IP address/port conflict
« Reply #8 on: March 23, 2017, 09:02:26 PM »
it won't change the effect, but I recommend using the template setting;
WebServer procedure, Security tab, Bind Server to only IP:
In your case simply set it to
glo:PublicIP

and of course set it before it is used.

cheers
Bruce

Jane

  • Sr. Member
  • ****
  • Posts: 372
  • Expert on nothing with opinions on everything.
    • View Profile
    • Email
Re: IP address/port conflict
« Reply #9 on: March 24, 2017, 08:52:35 AM »
Thanks, Bruce.

My feeble memory *thinks* I did it this way because I wanted limiting to a single IP to be optional.  And didn't know if I put it in the template as a string and then just left the string blank, whether it would automatically listen on all IPs (as desired).  And was too lazy to take the time to experiment.

I'll do some more experiments.

Jane


Poul

  • Full Member
  • ***
  • Posts: 160
    • View Profile
Re: IP address/port conflict
« Reply #10 on: March 24, 2017, 12:18:21 PM »
Jane,

if that code is your webserver code then your
ThisWebServer._ServerIP assignment has to be further down after the generated assignment - as it will override yours.

if you had left  the template setting blank, then that would be in effect (listening on all ip address)  regardless of your  INI settings.

Or just do what bruce suggests but just a thought:
if BOUNCE.INI is not where you think, GLO:PUBLICIP might be blank by default...

Unless there is another reason, you only need one global variable, set it based on your ini settings
and make sure that the template uses it, i think thats how bruce intended it.

poul



Jane

  • Sr. Member
  • ****
  • Posts: 372
  • Expert on nothing with opinions on everything.
    • View Profile
    • Email
Re: IP address/port conflict
« Reply #11 on: March 24, 2017, 05:21:20 PM »
I'll play some more, Poul.

But my kludge *IS* at least partially working.

If I don't specify to limit the IP, then the app responds to 127.0.0.1 or to the two IPV4 addresses on the box.

If I limit it as shown in my code, the app does not respond to the loopback or to the other IP - just to the IP I want.

BUT...  for some reason, IIS refuses to start when I bind it to the other IP:80.

If I kill the nettalk app, IIS starts and binds that address fine.

So again, what I've done is partially working.  I'll need to do some more experimenting.  But just moving IIS to a different server in my production network has solved my immediate issue.

Thanks.

Jane

JohanR

  • Sr. Member
  • ****
  • Posts: 375
    • View Profile
    • Email
Re: IP address/port conflict (possible resolve)
« Reply #12 on: March 27, 2017, 07:10:39 AM »
Hi Jane

I have a similar problem with a server2012 R2 in that something is using port 443 and my NTWS can't bind to 443.

My machine has multiple IP's and it also has IIS
I did redo the binding of the IIS default website to 81 and 444, but it did not help.
Something in the core system was still using 443.

After quite a bit of time and investigating I found this article solved my problem.

This might help you with your problem.

https://helpdesk.stone-ware.com/portal/kb/articles/port-443-80-not-available-on-windows-server





This is the actual text from the page
#####################################################################################################

Port 443 / 80 not available on Windows server.
-------------------------------------------------------------------

443 / 80 not available for webNetwork
 
Customer installed webNetwork on a brand new Windows 2012 server and can't bind to port 443 because it is already in use. What is using it and how can I fix it ?
 


Most likely the built in IIS manager has 443 enabled for some of the new features in server 2012. This can happen even if you disable all of the IIS services.

Go to a dos cmd prompt and type :
netstat -ban > c:\\netstat.txt

Now edit c:\\netstat.txt with notpad and look for something like :
TCP 0.0.0.0:443 0.0.0.0:0 LISTENING

This says that 443 will be used on every ip number on the box. Thus even adding another ip number will not fix the problem.

Next try this from a cmd prompt :
netsh
http
show iplisten

If nothing shows up then that means that it is using every ip number automatically.

To fix this type :
add iplisten ipaddress=[ip address of the server]

now type :
show iplisten

It should display the ip number.

Next restart IIS by typing : iisreset

Type netstat -an > c:\\netstat.txt and double check.

You may still need to disable your other IIS services or add a 2nd ip number for webnetwork but you won't have the problem of IIS binding to all ip addresses anymore.


If you need help figuring out what is listening on those ports you can type: netsh http show urlacl
An example of what you might see : Reserved URL : https://+:443/remoteDesktopGateway/

Another command that helps : netsh http show service
An example of what you might see : Registered URLs: HTTPS://+:443/KDCPROXY/

If you have Remote Desktop Gateway installed then that will always take port 443 and you would have to remove that role or add a 2nd ip number for webNetwork.

The following microsoft url talks about changing the port numbers for the IP-HTTPS service : http://technet.microsoft.com/en-us/library/jj134148.aspx

Similar problems can happen for port 80 if the Microsoft IIS server or another webserver is active on that box.  webNetwork has its own webserver and does not use 3rd party web servers to run.  Disable these other webservers before starting webNetwork.

#####################################################################################################


Jane

  • Sr. Member
  • ****
  • Posts: 372
  • Expert on nothing with opinions on everything.
    • View Profile
    • Email
Re: IP address/port conflict
« Reply #13 on: March 27, 2017, 07:54:42 AM »
YOU ARE A GENIUS, JOHAN!!!!

Thank You! 

Works perfectly now.  IIS listening on 10.15.12.114:80 and nettalk on 10.15.12.15:80 on the same box.

So here I was blaming nettalk for bogarting the port when it was actually IIS  ;)

Even though in my case it was not an issue with 443, explicitly using netsh http add iplisten ipaddress pointed IIS at the IP I wanted it to use... then I was able to set the bindings in IIS and it started fine.

Thank you!

-- Jane

JohanR

  • Sr. Member
  • ****
  • Posts: 375
    • View Profile
    • Email
Re: IP address/port conflict
« Reply #14 on: March 27, 2017, 09:07:54 AM »
Hi Jane

Cool that it worked for you as well.

I have been called many things in my life but never a genius.

The only credit I can take for the solution is a few hours of googling and scratching around the remote server
and thankfully I got lucky.
The credit must go to google and the author of the solution.

Glad it helped.

regards

Johan