At a loss figuring out if an IP is on LAN or INET

  • Thread starter Thread starter Terry Olsen
  • Start date Start date
T

Terry Olsen

I'm writing an app that communicates with computers both inside and outside
my router. So I need to determine by the remote host's IP address if I need
to send them my LAN IP or my Internet IP. Someone suggested AND'ing the IP
and my Subnet Mask but I come up with this:

My IP: 192.168.0.14
Mask: 255.255.255.0

Result: 192.168.0.0

Should I just compare the first two octets? Or are there situations where
this would provide incorrect results?
 
Terry,

AFAIK are there three ranges reserved for internal use

10.x.x.x
150.x.x.x
192.168.x.x

If I am not completely wrong than the first two should therefore be enough.

Cor
 
Terry,

Sorry when I had sent it I realized me that it was not the 150 so I searched
for it in Google.

10.x.x.x
172.16.x.x - 172.31.x.x
192.168.x.x

Cor
 
corrrect you are.

Testing against the forst two octets should be sufficient to determine
routable vs. non routable.... aka internal/external.

NOW, if an internal network is configured to have an IP scheme with ROUTABLE
IPs ( which CAN be done --- WHY? I wouldn't know)... that would make it a
bit touchy.
 
The correct way is to AND both the PC's own IP address and the destination
IP address each with the subnet mask... If the result is the same, then
they are on the same subnet of the network.

Out of interest the result of AND'ing the ip address against the subnet mask
produces what is called the "Network Address". For class B addresses (such
as your example) this is simply the same as the first two octects followed
by 2 zeros, but this may not always be the case...

HTH
Simon

--
================================
Simon Verona
Dealer Management Service Ltd
Stewart House
Centurion Business Park
Julian Way
Sheffield
S9 1GD

Tel: 0870 080 2300
Fax: 0870 735 0011
 
I'm writing an app that communicates with computers both inside and outside
my router. So I need to determine by the remote host's IP address if I need
to send them my LAN IP or my Internet IP. Someone suggested AND'ing the IP
and my Subnet Mask but I come up with this:

My IP: 192.168.0.14
Mask: 255.255.255.0

Result: 192.168.0.0

Should I just compare the first two octets? Or are there situations where
this would provide incorrect results?
Click to expand...

I'm curious, why do you need to do this? The remote host should already
know how to respond to you. If you're sending an IP to a third host
that distributes the IP (like many P2P networks), then using the IP
address to determine local vs. remote isn't going to help you, because
you'll have conflicts with identical addresses.
 
I'm curious, why do you need to do this? The remote host should already
know how to respond to you. If you're sending an IP to a third host
that distributes the IP (like many P2P networks), then using the IP
address to determine local vs. remote isn't going to help you, because
you'll have conflicts with identical addresses.
Click to expand...

There should not be any identical addresses. I am writing a P2P application
that communicates via UDP (as an experiment, I know UDP isn't reliable for a
chat application). I want to be able to communicate with other peers both
inside and outside my router. Since there is no TCP connection from which to
read the remote IP address, when one peer sends a message to another, it
also sends the return IP address. So I need to be able to determine if the
peer is inside or outside my router so I know which IP address to send as
the return address. I won't be sending my "192.168.x.x" address to anyone
outside my router, and I should not received a private IP from anyone
outside my router.

I believe I understand now how to get the "network address" by AND'ing the
Subnet Mask with with each IP and comparing the results. I'm going to try
that.
 
corrrect you are.

Testing against the forst two octets should be sufficient to determine
routable vs. non routable.... aka internal/external.

NOW, if an internal network is configured to have an IP scheme with ROUTABLE
IPs ( which CAN be done --- WHY? I wouldn't know)... that would make it a
bit touchy.
Click to expand...

The computers could have external static IPs that all lie on the same subnet. This most likely a few servers beloning to
one company that have brought a block of ips, etc. They now can have both their 'internal' network between each other
(internal being that they all lie on the same side of a gateway) but at the same time they are external (probaly have a
firewall though, at least I'd hope they do).
 
There should not be any identical addresses. I am writing a P2P application
that communicates via UDP (as an experiment, I know UDP isn't reliable for a
chat application). I want to be able to communicate with other peers both
inside and outside my router. Since there is no TCP connection from which to
read the remote IP address, when one peer sends a message to another, it
also sends the return IP address.
Click to expand...

I don't see where the TCP vs. UDP issue comes in. Both have the source
address in the packet.
So I need to be able to determine if the
peer is inside or outside my router so I know which IP address to send as
the return address. I won't be sending my "192.168.x.x" address to anyone
outside my router, and I should not received a private IP from anyone
outside my router.
Click to expand...

Maybe I just don't understand the problem. I can sorta see issue in
p2p swarming apps like BitTorrent or Kazaa where a third server needs
to keep lists of distributable IP addresses and the sender address might
not match the distributable address.

In this case though, it doesn't look like that's happening. So why
can't a node receiving a packet simply reply to the sender, without the
issue of embedding a user-defined IP address in the data.
I believe I understand now how to get the "network address" by AND'ing the
Subnet Mask with with each IP and comparing the results. I'm going to try
that.
Click to expand...

That's going to break on any internal network with routing. In other
words, on anything larger than a very trivial home network.

This is kinda what I'm getting at. Checking the subnet mask will
answer the question you asked, i.e., whether a transmission went through
a router. But the question you want seems to be whether a tranmission
went through a NAT router, which is a completely different question.

Of course, I'm not sure why you need the second question either...
 
Ok, take an example of a pc with an ip address of 192.168.1.1 and a sub net
mask of 255.255.255.128

if you do an AND of the ip address and the subnet mask, you get 192.168.1.0
which is the network address for this subnet.

Take another PC with an IP address of 192.168.1.129 with the subnet mask of
255.255.255.128. Do an AND of these two and you get 192.168.1.128 as the
network address.

These two addresses are on different subnets. There needs to be a router
somewhere in the network to route between these networks. The two pc's may
be at different locations seperated by a WAN (perhaps the internet).

Whilst we normally see subnet masks of 255.255.0.0 or 255.255.255.0 it
should not be assumed that it's always a zero at the end of the netmask.

This explain better?

Regards
Simon
--
================================
Simon Verona
Dealer Management Service Ltd
Stewart House
Centurion Business Park
Julian Way
Sheffield
S9 1GD

Tel: 0870 080 2300
Fax: 0870 735 0011
 
Ok, take an example of a pc with an ip address of 192.168.1.1 and a sub net
mask of 255.255.255.128

if you do an AND of the ip address and the subnet mask, you get 192.168.1.0
which is the network address for this subnet.

Take another PC with an IP address of 192.168.1.129 with the subnet mask of
255.255.255.128. Do an AND of these two and you get 192.168.1.128 as the
network address.

These two addresses are on different subnets. There needs to be a router
somewhere in the network to route between these networks. The two pc's may
be at different locations seperated by a WAN (perhaps the internet).
Click to expand...

Well, probably not the internet, since these addresses are in the
private IP range.
 
I don't see where the TCP vs. UDP issue comes in. Both have the source
address in the packet.
Click to expand...

What source address is in the packet? The local, private IP? or the public
internet IP?
Maybe I just don't understand the problem. I can sorta see issue in
p2p swarming apps like BitTorrent or Kazaa where a third server needs
to keep lists of distributable IP addresses and the sender address might
not match the distributable address.

In this case though, it doesn't look like that's happening. So why
can't a node receiving a packet simply reply to the sender, without the
issue of embedding a user-defined IP address in the data.
Click to expand...

Ok. I'm talking to multiple peers, some inside and some outside my router.
If I send out my private IP (192.168.0.14) to all peers as a return address,
then only those INSIDE my router will be able to respond. If I send out my
public internet IP to all peers, only those OUTSIDE my router will be able
to respond. I need to send the appropriate return IP address to each peer
determined by their location relative to my router.
That's going to break on any internal network with routing. In other
words, on anything larger than a very trivial home network.
Click to expand...

I don't think I have to worry about this at all. Since I don't control the
corporate firewall at work (port forwarding & such), I wouldn't be able to
communicate outside the company boundaries anyway. I would simply send my
local IP (10.x.x.x) to all other peers.
 
I don't think I have to worry about this at all. Since I don't control the
corporate firewall at work (port forwarding & such), I wouldn't be able to
communicate outside the company boundaries anyway. I would simply send my
local IP (10.x.x.x) to all other peers.
Click to expand...

Why do you have to send 'your ip' to the server. Can the server not just
look at the IP and port it sees from the incomming tcp connection? If
you need a new connection between the two clients:
* client A could tells the server it is ready to accept a connection on
port X.
* The server can now tell client A to expect a connection from client B
* The server now tells client B, client A's ip address (from the tcp
connection) and port X
* Client B now trys to connect to client A on the give IP and port

This could fail if there is a firewall / NAT, but no way to solve this
unless you can change the NAT settings to forward your chosen port. To
make it easier you could let the client's set what port rages they use
for these connection in a config somewhere.
 
Not knowing the particular problem I just thought you may be trying this
as some sort of speed optimisation. If the two computers are on the same
subnet try sending using internal ip's (like MSN). For this you could:
* query both clients for internal ip/subnet, and client A for port X to
connect to
* mask ips and compare. If equal you can now send to each client,
internal ip and external ip (and to client B, port X from A)
* the sever tells client A to expect a connection from A's internal or
external ip (probaly want to have A send some sort of random key to the
server that can be sent to B)
* client B can now try to connect on the internal ip, if that fails it
could retry the external ip (and the first thing it needs to send is
that secrect key or A or A will close the connection)

Along with all this automatic discovery you could allow power users to
decide they really do know better and have a config somewhere, where
they can set what IP address to send to the server. This gives us two
types of IP sent from the client to the server; internal IP/subnet, and
forced IP (no subnet as we're now telling the server to always use this
IP, should disregard the external IP unless this is some sort of
automate regular connection which could result in a DDOS if misused)
 
What source address is in the packet? The local, private IP? or the public
internet IP?
Click to expand...

The IP address from which the packet arrived. In other words, for
internet hosts, the packet will contain the external public address, for
internal network hosts, the packet will contain the internal address.

This seems to be the information you're trying to handle yourself, when
in fact the network layer is already handling it for you.

More importantly, for external internet hosts what you really want is
the NATted address, and that's what the packet will contain, since a NAT
firewall will replace the source address in the header.
Ok. I'm talking to multiple peers, some inside and some outside my
router. If I send out my private IP (192.168.0.14) to all peers as a
return address, then only those INSIDE my router will be able to
respond. If I send out my public internet IP to all peers, only those
OUTSIDE my router will be able to respond. I need to send the
appropriate return IP address to each peer determined by their
location relative to my router.
Click to expand...

What I'm suggesting is don't send any IP address in your data packet.
Let the IP stack worry about putting the correct address in the
header. Unless you have special needs, this isn't something the
application layer should be worrying about.
I don't think I have to worry about this at all. Since I don't control
the corporate firewall at work (port forwarding & such), I wouldn't be
able to communicate outside the company boundaries anyway. I would
simply send my local IP (10.x.x.x) to all other peers.
Click to expand...

Host 1 has address 10.0.0.1/255.255.255.0 (address/subnet)
Host 2 has address 10.0.1.1/255.255.255.0

Now these two hosts are NOT on the same subnet, in fact they must be
routed, and your algorithm will correctly identify that. But in reality
both hosts are probably behind the firewall, and you'd have to use the
internal IP addresses to communicate between them.

IAW, routed != NAT.
 
This gets into what I mentioned before, the complications of adding a
server host to the two clients. I'm not entirely sure the OP needs
this, although it's an interesting problem.
Not knowing the particular problem I just thought you may be trying this
as some sort of speed optimisation. If the two computers are on the same
subnet try sending using internal ip's (like MSN). For this you could:
* query both clients for internal ip/subnet, and client A for port X to
connect to
* mask ips and compare. If equal you can now send to each client,
internal ip and external ip (and to client B, port X from A)
Click to expand...

I still don't see how using the subnet mask helps anything here. The
fact that two ip addresses are on different subnets doesn't tell you
whether to use the internal IP or the external IP.

What the server probably wants to check here is whether the IP in the
packet header matched the IP in the packet data. That would tell you
whether the packet was NATted, which is what you really want to know.

You might also want to check whether hosts A and B had the same external
IP both in the packet data and the packet header, which would let you
identify situations where A and B are local to each other but remote
from the server.
 
What I'm suggesting is don't send any IP address in your data packet.
Let the IP stack worry about putting the correct address in the
header. Unless you have special needs, this isn't something the
application layer should be worrying about.
Click to expand...

Here's the code I'm using to receive the packets:

Private Sub RcvCallback(ByVal ar As IAsyncResult)
Dim _UdpState As UdpState = ar.AsyncState
Dim _UdpClient As UdpClient = _UdpState.cl
Dim IPE As IPEndPoint = _UdpState.ep
Dim rcvd As String = ASCII.GetString(_UdpClient.EndReceive(ar, IPE))
ThreadPool.QueueUserWorkItem(New WaitCallback(AddressOf
ProcessIncoming), rcvd)
_UdpClient.BeginReceive(New AsyncCallback(AddressOf RcvCallback),
_UdpState)
End Sub

How would I go about getting the source IP (and port?) ? I tried looking at
the Address from IPE but it just shows "0.0.0.0".
 
Nevermind. I got it. Check IPE.Address _AFTER_ the _UdpClient.EndReceive,
not before :) Can't use the port property, because I need to know what port
the peer is listening on, no the port used to send.
 
I still don't see how using the subnet mask helps anything here. The
fact that two ip addresses are on different subnets doesn't tell you
whether to use the internal IP or the external IP.

What the server probably wants to check here is whether the IP in the
packet header matched the IP in the packet data. That would tell you
whether the packet was NATted, which is what you really want to know.

You might also want to check whether hosts A and B had the same external
IP both in the packet data and the packet header, which would let you
identify situations where A and B are local to each other but remote
from the server.
Click to expand...

I originaly thought about that, but then I thought about the fact that
the NAT we think about of multiple machines sharing the same IP is in
fact NAPT, whilst true NAT means that each machine could have a
different external IP whilst all being on the same internal network. The
only work around I could see was to have one client try to talk to the
other client internaly first to see if a connection could be found,
hence the use of the shared secrect. Think about it you probaly want two
shared secrects, one from A and one from B so that they both know they
are talking to the right machine, whilst in my first idea only A knew it
had the right computer, B does not (B could have connected to a random
computer that just accepted the connection).
 
Back
Top