Getting communication interface's IP

[nano2k]

Hi



I have a client application that consumes a webservice, both developed
by me.

For each connected client I need to keep several information.

One piece of info is to uniquely identify each client along with the
location where the connection was initiated by the client application.

That is, let's say my computer is inside a LAN with a local IP. Let's
say 192.168.0.10. My machine communicates over the Internet through a
router which, of course, has a phisical IP.

The webservice is published at: http://www.ikonsoft.ro

To uniquely identify a client, the webservice needs to know 2 pieces
of info:

1. Router's IP - public; can be easily obtained

2. Local IP of the connecting machine.

This second IP must be communicated to the webservice at connection
time.

But first, the local machine has to know the IP used to communicate
with the webservice. Is there a way for the client application to
obtain this value? I mean, there could be several interfaces installed
on a system, but only one will be used to communicate with the
webservice. How to determine this particular interface along with its
IP? It's easy to enumerate the list of configured IPs on local
machine, but determining the right one, beats me



Thanks.

 

[John Saunders [MVP]]

Hi



I have a client application that consumes a webservice, both developed
by me.

For each connected client I need to keep several information.

One piece of info is to uniquely identify each client along with the
location where the connection was initiated by the client application.

That is, let's say my computer is inside a LAN with a local IP. Let's
say 192.168.0.10. My machine communicates over the Internet through a
router which, of course, has a phisical IP.

The webservice is published at: http://www.ikonsoft.ro

To uniquely identify a client, the webservice needs to know 2 pieces
of info:

1. Router's IP - public; can be easily obtained

2. Local IP of the connecting machine.

This second IP must be communicated to the webservice at connection
time.

But first, the local machine has to know the IP used to communicate
with the webservice. Is there a way for the client application to
obtain this value? I mean, there could be several interfaces installed
on a system, but only one will be used to communicate with the
webservice. How to determine this particular interface along with its
IP? It's easy to enumerate the list of configured IPs on local
machine, but determining the right one, beats me

I would encourage you to not use IP addresses or any other Network-layer
entity in your application code. Those values, and even the relationships
among them, can change at the whim of your IT department.

If you want the client to be uniquely identified, then you need to _give_
the client a unique ID and have the client give it back to you. Don't depend
on your network infrastructure to do this for you, as that's not its job.

 

[nano2k]

Thanks John

You're right, but I want to use this inforrmation for general auditing
purposes, too.
I mean, I want to be able to create a report to track the locations
from where the webservices was called.
Because of the nature of the application, assigning different IDs to
different installations doesn't really make sense. Meanwhile the
project manager of the project accepted that I should log the IP
address from where the webservice was invoked and the host name of the
invoking computer.



John Saunders [MVP] a scris:

 

[John Saunders [MVP]]

Thanks John

You're right, but I want to use this inforrmation for general auditing
purposes, too.
I mean, I want to be able to create a report to track the locations
from where the webservices was called.
Because of the nature of the application, assigning different IDs to
different installations doesn't really make sense. Meanwhile the
project manager of the project accepted that I should log the IP
address from where the webservice was invoked and the host name of the
invoking computer.

Just keep in mind that the IP address may be of limited or no value if
proxies or NAT boxes are involved; and that finding the host name takes time
and may not succeed.

 

[nano2k]

Hi

The host name is sent by the invoking computer itself at the
autentication time.


John Saunders [MVP] a scris:

 

[joseG]

Hi,

But, how know the client ip?

joseG

Just keep in mind that the IP address may be of limited or no value if
proxies or NAT boxes are involved; and that finding the host name takes time
and may not succeed.

 

[John Saunders [MVP]]

Hi,

But, how know the client ip?

Questions like this are often the result of a restricted understanding of
networking.

1) Why do you assume that the client has only a single IP address?
2) Why do you assume the client's IP address does not change whenever it
feels like changing?
3) Why do you feel entitled to know the client's IP address? Did the client
_tell_ you its IP address? Did you assign the clients IP address?
4) I hope you don't assume that the clients IP address will be usable as a
way to communicate to the client!

IP addresses are intended as a mechanism to permit communication over the IP
protocol. They are not there in order to provide a service to your
application. If, at any time, they do a good job of being a network address,
and a poor job of helping your application, then you can't blame them for
doing their job.

In other words, ask yourself what you had hoped to gain by using the clients
IP address - and then don't use it! Use something else instead. Something
that _you_ have control over. Something that won't change if the networking
infrastructure changes.

In particular, if you need your clients to have a unique id within your
application, then your application should _give_ them a unique id. You can
encrypt that ID if necessary. Such an ID will be something that you have
total control over. Nobody will be able to change it out from under you by
adding routers, changing subnets, adding, removing or reconfiguring NAT
boxes, etc.

 

[nano2k]

Hi John

I totally understand what you said and I also agree with that.
First, I will use the IP _only_ for auditing reasons.
For example, if someone _uninvited_ will try to use my webservice's
services, this could be a tool to track that person or to reject it's
request(s). It's not my intention to initiate some connections to
those IPs. No, sir!

Now, there are many other means to track access to my webservice, but
its more handy for the unexperimented user to initiate a report that
will point out the locations from where the webservice was invoked.
I could also implement some sort of "firewall" inside my webservice.
Many clients ask me: the application (webservice) should be accessed
from the Internet _only_ from specific locations (locations have fixed
IPs). How can we restrict the access?
The first solution could be: set your firewall. But the client doesn't
want to restrict the access but for this particular webservice (e.g.
others may connect from other IPs to other webservices).
Of course, for each case alone, some combinations of solution may
solve the problem. But why bother each time with so many settings and
configs when I could easily create a simple tool as part of my
webservice?

Note: I'm using dotnet framework v1.1. WSE is out of the question
partly because the webservice should support WIN98 clients that do not
support WSE. Many headaches already derived from this, but this is
life


John Saunders [MVP] a scris:

 

[John Saunders [MVP]]

Hi John

I totally understand what you said and I also agree with that.
First, I will use the IP _only_ for auditing reasons.

Ok, you're telling me you're ok with auditing unreliable data. I get that.

For example, if someone _uninvited_ will try to use my webservice's
services, this could be a tool to track that person or to reject it's
request(s).

Except that the IP address is unreliable, but ok.

It's not my intention to initiate some connections to
those IPs. No, sir!

Now, there are many other means to track access to my webservice, but
its more handy for the unexperimented user to initiate a report that
will point out the locations from where the webservice was invoked.

Except that IP addresses are unreliable, and don't always equate to a
location. Maybe more than 80% of the time, though, assuming that most of
your users aren't wireless users. I understand that in many countries with
limited Internet infrastructure, wireless technology is growing faster than
wired technology. Maybe that's not true for your users.

I could also implement some sort of "firewall" inside my webservice.

You'd do better to leave firewall implementation to those whose job it is to
do that. Leave the network to networking people.

Many clients ask me: the application (webservice) should be accessed
from the Internet _only_ from specific locations (locations have fixed
IPs). How can we restrict the access?

With a firewall. The firewall admin software will doubtless have the ability
for administrators to add and change IP addresses. No need for your web
service to re-invent that wheel.

The first solution could be: set your firewall. But the client doesn't
want to restrict the access but for this particular webservice (e.g.
others may connect from other IPs to other webservices).

You could put the web service on a particular port, and restrict access to
that port.

Of course, for each case alone, some combinations of solution may
solve the problem. But why bother each time with so many settings and
configs when I could easily create a simple tool as part of my
webservice?

Because many others have already done this, and they've probably done a
better job than you will, since that is the business you're in. They even
compete with each other to do better and better at this. I bet you don't
compete with any of them, and will have little reason to enhance this minor
feature of your web service.