Re: Different external IP address for different "show my IP" pages!!!

On Thu, 23 Sep 2010 09:25:18 -0700 (PDT), Elton <(E-Mail Removed)>
wrote:

>Where can you see the IP address of the poster of a post/reply, like
>you saw mine?
>Because, for example, I look at the header of your posts and can't
>find anywhere your IP or the NNTP-Posting-Host field.
>Why my IP is shown and yours is not?

Different Usenet providers do it slightly differently. Here are a few
of the headers your provider (Google Group?) includes:

NNTP-Posting-Host: 79.106.109.116
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Trace: posting.google.com 1285259124 11582 127.0.0.1 (23 Sep 2010
16:25:24 GMT)
X-Complaints-To: groups-(E-Mail Removed)
NNTP-Posting-Date: Thu, 23 Sep 2010 16:25:24 +0000 (UTC)
Complaints-To: groups-(E-Mail Removed)


>My purpose isn't to setup an webserver because I need it.
>My purpose is to see if I can make my computer accessible from the
>internet and in the process, to learn more about networks and the way
>how they work.
>
>It puzzles me why software such as TeamViewer and the TeamViewer
>server, can access my home pc from outside

Are you running any kind of client software related to those
applications? If so, that's how they do it. The client initiates an
outbound connection, which your ISP allows, and the return traffic
simply uses that existing connection.

>or my ISP accepts traffic from facebook.com and sends it to me

No idea what you're talking about here. I don't use Facebook. What are
they sending to you?

>while I can't access my home PCs server ports at all.

I thought this had been settled. It appears that your ISP is either
doing double NAT (most likely) or is using another kind of technology
that effectively prevents you from doing what you're trying to do.

>If, for example, youtube.com sees my 79.106.109.XXX IP and then
>streams the video to this IP, and the ISP can send it to the exact
>computer which requested it, then why can't I, instead of a video,
>send a request to my computer to connect in port 80 for example ???

Youtube doesn't send anything that you haven't requested, as far as I
know. As above, you make a request which your ISP sees as an outgoing
connection, which is allowed, and the response from youtube is the
video you've requested. No mystery there. That scenario works through
multiple layers of NAT. But that's not the same as some entity trying
to initiate a connection to your PC. Your ISP's NAT infrastructure has
no idea what to do with that kind of incoming connection. How would
they know they should forward it to you rather than to any of their
other subscribers? There's no user-identifying information in the
connection setup.

I think Char Jackson has covered your questions real well. Let me drop
a few comments in below.

On 9/23/2010 2:39 PM, Char Jackson wrote:
> On Thu, 23 Sep 2010 09:25:18 -0700 (PDT), Elton<(E-Mail Removed)>
> wrote:
>
>> Where can you see the IP address of the poster of a post/reply, like
>> you saw mine?
>> Because, for example, I look at the header of your posts and can't
>> find anywhere your IP or the NNTP-Posting-Host field.
>> Why my IP is shown and yours is not?
>
> Different Usenet providers do it slightly differently. Here are a few
> of the headers your provider (Google Group?) includes:
>
> NNTP-Posting-Host: 79.106.109.116
> Mime-Version: 1.0
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> X-Trace: posting.google.com 1285259124 11582 127.0.0.1 (23 Sep 2010
> 16:25:24 GMT)
> X-Complaints-To: groups-(E-Mail Removed)
> NNTP-Posting-Date: Thu, 23 Sep 2010 16:25:24 +0000 (UTC)
> Complaints-To: groups-(E-Mail Removed)
>

I tend to hit the 'view source' to see everything in an email or news
post. If you depend upon the headers shown by your news reader, you may
not see everything. The news server my ISP uses (they farm it out in
recent years) does not pass on the IP address of the originator. Some
people get upset about that information being passed on. Knowing an IP
address lets you (maybe) identify where a person is. When I ran one of
your IP addresses thru a whois server, it showed me on a map that you
weren't too far from the "heel of the boot" :-) -- that agreed with
what you had posted a little earlier.

>
>> My purpose isn't to setup an webserver because I need it.
>> My purpose is to see if I can make my computer accessible from the
>> internet and in the process, to learn more about networks and the way
>> how they work.
>>
>> It puzzles me why software such as TeamViewer and the TeamViewer
>> server, can access my home pc from outside
>
> Are you running any kind of client software related to those
> applications? If so, that's how they do it. The client initiates an
> outbound connection, which your ISP allows, and the return traffic
> simply uses that existing connection.

Perhaps I can expound on that a little. When you access a web site
(lets assume a html server) your computer first looks up (at a DNS
server) the URL to get an IP for that destination, then connects to it
-- specifying a default port at the destination -- unless you gave a
specific port. For a web server, that will be port 80. That connect
request coming from your computer also specifies a port number for
replies to be sent to. Those ports at the originating computer will be
random, but usually in the higher numbers. Once that connection has
been set up, your computer sends traffic to the other on that port 80,
and replies come back to whatever you specified.

Enter a router into the mix! A router does a network address
translation (NAT) so that more than one computer can share the
connection to the internet. Your router will track the IP of the
computer and the port it expects replies on, and modify those so it is
showing them as coming from whatever IP your ISP thinks you are using,
and probably a different port number. Replies that come back to your
router are to that outside address and at the modified port. The router
replaces those with the original IP/port pair and sends it on to your
computer.

As long as you keep that connection up to the other end (and I'm not
sure how that is determined) your router knows where to forward those
replies.

In your case, if you do a IPCONFIG on your computer, you will see the
information on your connection to your router -- in the 192.168 range.
The router is using an address in the 10.0 range for it's WAN
connection. It really, since it is using PPPoE, is simply talking to
another computer at the ISP that is doing a form of NAT, but using an
available IP address in the 79.106.109 range for the connection. I
suspect those IP addresses are held down for you only as long as that
connection is open.

The advantage of that, to the ISP, is possibly fewer IP addresses it
needs. I sit here with a DSL connection up 24/7, and that is using one
IP address. You have your DSL connection up 24/7 -- but when there is
no traffic going on, you are not using any IP address in the pool the
ISP has purchased.

>
>> or my ISP accepts traffic from facebook.com and sends it to me
>
> No idea what you're talking about here. I don't use Facebook. What are
> they sending to you?
>
>> while I can't access my home PCs server ports at all.
>
> I thought this had been settled. It appears that your ISP is either
> doing double NAT (most likely) or is using another kind of technology
> that effectively prevents you from doing what you're trying to do.
>
>> If, for example, youtube.com sees my 79.106.109.XXX IP and then
>> streams the video to this IP, and the ISP can send it to the exact
>> computer which requested it, then why can't I, instead of a video,
>> send a request to my computer to connect in port 80 for example ???
>
> Youtube doesn't send anything that you haven't requested, as far as I
> know. As above, you make a request which your ISP sees as an outgoing
> connection, which is allowed, and the response from youtube is the
> video you've requested. No mystery there. That scenario works through
> multiple layers of NAT. But that's not the same as some entity trying
> to initiate a connection to your PC. Your ISP's NAT infrastructure has
> no idea what to do with that kind of incoming connection. How would
> they know they should forward it to you rather than to any of their
> other subscribers? There's no user-identifying information in the
> connection setup.
>

If you were to be able to get an IP address that could be seen from the
internet, then if you were to set up a server, it would be listening on
a specific port. As I mentioned, for a web server, the default is port 80.

I set the router here up originally to forward port 80 traffic on to the
computer I was running a server on. That was a big mistake! All the
hackers in the world scan IP addresses on port 80, and when they get an
acknowledgment, they know they have a target to play with. Without
going into details, it was very obvious very soon that was a bad scene.

I set the server here to listen for connections to an unused port (got
64,000 to pick from!), and used a server at DYNDNS to translate connects
coming to port 80 to the port my server listens on.

And, a question maybe someone can answer: How do you set up a VPN
connection if you have a PPPoE connection like Elton does?

....Bob

On Thu, 23 Sep 2010 21:28:28 -0400, Bob K <(E-Mail Removed)>
wrote:

>I think Char Jackson has covered your questions real well. Let me drop
>a few comments in below.

Thanks, Bob. Your comments dovetailed nicely.

[big snip]

>And, a question maybe someone can answer: How do you set up a VPN
>connection if you have a PPPoE connection like Elton does?

I believe it's simply a tunnel within a tunnel. The PPPoE connection
is set up first (as part of the Internet connection itself) and
probably has endpoints at the CPE modem and somewhere within the ISP's
network, while the VPN tunnel is optionally set up later and will have
endpoints that extend past the PPPoE tunnel, perhaps at the CPE router
(versus the CPE modem) and somewhere on the Internet.

The VPN tunnel would be inside the PPPoE tunnel, and the customer data
would be inside the VPN tunnel.

On 9/24/2010 7:58 AM, Elton wrote:
<snip>
> But you did keep the port forwarding of port 80 to the X port server
> on your router even with DynDNS?
> How did you configure the DynDNS server to do the port translating?
> Where is the option?

No -- port 80 requests to the router never get replied to. Just as if
the IP address wasn't there.

The DynDNS server has, in their bag of tricks, what is known as their
WebHop service. You pick up a domain name from them, and you point it
to where you want, with a destination port specified. (This works only
with HTML!)

In my case, I have two different computers, each with a web server. I
have my own domain name, requests to one sub-domain name get sent on to
a WebHop domain name where it gets forwarded to another domain name at
DynDNS with the modified port. That domain name is kept updated with my
IP address.

Requests to my domain name, with no sub-domain name (or with the WWW sub
domain) get forwarded to a different WebHop server, that request gets a
different port destination assigned, and then sent on.

My router forwards to the proper computer based on the port specified on
the packet.

At the service that I have my domain name at, they allow me to do
'cloaking' on requests. I'm not sure how that is done, but your address
bar would never show anything other than what you had given as the
destination. So, you don't see all various steps something goes thru to
get to me (and the port numbers!). It also means if you bookmark
something that you like, that bookmark is just to the original
destination you put in.

One downside to this, if I were to specify a favicon icon, that will
never make it back to you. Not a big deal for me -- it might bother some.

While the various steps along the way to my servers are reasonably well
hidden from the user, they are available if you know how to trace thru
the various steps.

One of those computers also has some other services I make available.
One is a telnet server. Again, I have unusual port numbers set up for
it. (Nothing here responds to any standard port numbers.) Another
sub-domain name forwards directly to the host name at DynDNS that points
to my IP. So users, if they need one of the other services here, use
that, with a port number specified.

I know all this may sound a little involved, but it really works very
nicely. There are many services available at DynDNS -- most if you
subscribe to their Pro service. What I am using is all within their
free offering (altho some of it is now grandfathered in).

Again, I hope this sort of explains how things work here. I still am
not sure how you might take advantage of it in your situation! Somehow
you need to be able to get some presence visible on the internet. You
might try running your problem by the support people at DynDNS and see
if they have any ideas.

....Bob

On Fri, 24 Sep 2010 03:30:01 -0700 (PDT), Elton <(E-Mail Removed)>
wrote:

>> Youtube doesn't send anything that you haven't requested, as far as I
>> know. As above, you make a request which your ISP sees as an outgoing
>> connection, which is allowed, and the response from youtube is the
>> video you've requested. No mystery there. That scenario works through
>> multiple layers of NAT. But that's not the same as some entity trying
>> to initiate a connection to your PC. Your ISP's NAT infrastructure has
>> no idea what to do with that kind of incoming connection. How would
>> they know they should forward it to you rather than to any of their
>> other subscribers? There's no user-identifying information in the
>> connection setup.
>
>In this case too, I was talking about the case when I request to view
>a video and that video is streamed to my computer.
>Yes now that I gave it a thought you're right. When I make a request
>to Youtube (I'm taking Youtube as an example), the TCP/IP packet of
>that request has in it the MAC address of my PC's network card.
>Youtube sees the IP and the MAC of the sender and sends the response
>(the video for example) in a TCP/IP packet with my external IP and my
>MAC address as destination. The ISP receives the response packet in
>one of those external IPs that the ISP had assigned me when I made the
>request to Youtube in the beginning, and then the ISP sends the
>response to the specified MAC address in the destination field of the
>response TCP/IP packet's header.

A minor clarification. MAC addresses don't typically travel past
routers. Routers keep a list of MAC addresses and the IP addresses
that belong to them, (the MAC table). If a router receives traffic for
a directly connected node that doesn't exist in the MAC table, it will
broadcast an ARP request ("hey, who owns address 1.2.3.4?") and every
system will ignore it except the system that owns that IP address.
That system will reply directly back to the router, the router will
update its MAC table, and then the router will forward the traffic
that it was holding to that MAC address. All of that is for traffic
coming into a local network only. If the destination is not local,
then the router simply forwards the packet to another router that it
determines will be able to get the packet closer to its destination.

I didn't explain that very well and don't have time to pretty it up. I
just wanted to say that youtube sees your WAN IP address, not your MAC
address.

>Now when I think of it, even TeamViewer works this way. They assign
>you an unique ID with your MAC that is mapped and saved in a database
>in their servers. So when I make a request to connect to my home PC
>from another PC, the request sent to my home PC already contains the
>MAC address and the ISP knows which computer to send it to.
>
>Is this scenario correct ?

As above, the MAC isn't typically sent across the Internet. It stops
at the first router.

>Now in this scenario I have an uncertainty:
>
>The TCP/IP packet that receives Youtube from me (when I make a request
>or want to start a connection to youtube.com), in the final step of
>routing thus when Youtube servers have received my TCP/IP packet, does
>that packet's headers contain my home PC's MAC address or the MAC
>address of the last router?

I don't know everything that's included. Your IP address is there, but
not your MAC address. Youtube replies to your IP address. The router
on that segment of youtube's network recognizes that the destination
IP address is not local so it forwards the packet to another router
that is (hopefully) closer to you. The packet continues to get
forwarded by IP address until it hits a router at your ISP. If they're
doing double NAT, they will have a lookup table to see who made this
youtube request and they will rewrite the packet and forward it toward
you. The packet will hit your own NAT router, in turn that router will
determine that the destination is locally attached, so it will get
your MAC address from its internal MAC lookup table, rewrite the
destination to your MAC, and put the packet onto the wire. Each system
on the LAN will see the packet, but all will ignore it except the
system that says "hey, that's *my* MAC!". That system will strip the
first set of headers and send the payload up the network stack, and
that will happen a few more times, each time headers getting stripped.
Finally, the actual payload is given to the application that requested
it.

I cut a whole lot of corners and took some big liberties, but
hopefully you get the gist.

On 9/24/2010 1:19 PM, Char Jackson wrote:
> On Fri, 24 Sep 2010 03:30:01 -0700 (PDT), Elton<(E-Mail Removed)>
> wrote:
>
>>> Youtube doesn't send anything that you haven't requested, as far as I
>>> know. As above, you make a request which your ISP sees as an outgoing
>>> connection, which is allowed, and the response from youtube is the
>>> video you've requested. No mystery there. That scenario works through
>>> multiple layers of NAT. But that's not the same as some entity trying
>>> to initiate a connection to your PC. Your ISP's NAT infrastructure has
>>> no idea what to do with that kind of incoming connection. How would
>>> they know they should forward it to you rather than to any of their
>>> other subscribers? There's no user-identifying information in the
>>> connection setup.
>>
>> In this case too, I was talking about the case when I request to view
>> a video and that video is streamed to my computer.
>> Yes now that I gave it a thought you're right. When I make a request
>> to Youtube (I'm taking Youtube as an example), the TCP/IP packet of
>> that request has in it the MAC address of my PC's network card.
>> Youtube sees the IP and the MAC of the sender and sends the response
>> (the video for example) in a TCP/IP packet with my external IP and my
>> MAC address as destination. The ISP receives the response packet in
>> one of those external IPs that the ISP had assigned me when I made the
>> request to Youtube in the beginning, and then the ISP sends the
>> response to the specified MAC address in the destination field of the
>> response TCP/IP packet's header.
>
> A minor clarification. MAC addresses don't typically travel past
> routers. Routers keep a list of MAC addresses and the IP addresses
> that belong to them, (the MAC table). If a router receives traffic for
> a directly connected node that doesn't exist in the MAC table, it will
> broadcast an ARP request ("hey, who owns address 1.2.3.4?") and every
> system will ignore it except the system that owns that IP address.
> That system will reply directly back to the router, the router will
> update its MAC table, and then the router will forward the traffic
> that it was holding to that MAC address. All of that is for traffic
> coming into a local network only. If the destination is not local,
> then the router simply forwards the packet to another router that it
> determines will be able to get the packet closer to its destination.
>
> I didn't explain that very well and don't have time to pretty it up. I
> just wanted to say that youtube sees your WAN IP address, not your MAC
> address.
>
>> Now when I think of it, even TeamViewer works this way. They assign
>> you an unique ID with your MAC that is mapped and saved in a database
>> in their servers. So when I make a request to connect to my home PC
>>from another PC, the request sent to my home PC already contains the
>> MAC address and the ISP knows which computer to send it to.
>>
>> Is this scenario correct ?
>
> As above, the MAC isn't typically sent across the Internet. It stops
> at the first router.
>
>> Now in this scenario I have an uncertainty:
>>
>> The TCP/IP packet that receives Youtube from me (when I make a request
>> or want to start a connection to youtube.com), in the final step of
>> routing thus when Youtube servers have received my TCP/IP packet, does
>> that packet's headers contain my home PC's MAC address or the MAC
>> address of the last router?
>
> I don't know everything that's included. Your IP address is there, but
> not your MAC address. Youtube replies to your IP address. The router
> on that segment of youtube's network recognizes that the destination
> IP address is not local so it forwards the packet to another router
> that is (hopefully) closer to you. The packet continues to get
> forwarded by IP address until it hits a router at your ISP. If they're
> doing double NAT, they will have a lookup table to see who made this
> youtube request and they will rewrite the packet and forward it toward
> you. The packet will hit your own NAT router, in turn that router will
> determine that the destination is locally attached, so it will get
> your MAC address from its internal MAC lookup table, rewrite the
> destination to your MAC, and put the packet onto the wire. Each system
> on the LAN will see the packet, but all will ignore it except the
> system that says "hey, that's *my* MAC!". That system will strip the
> first set of headers and send the payload up the network stack, and
> that will happen a few more times, each time headers getting stripped.
> Finally, the actual payload is given to the application that requested
> it.
>
> I cut a whole lot of corners and took some big liberties, but
> hopefully you get the gist.
>

Fantastic explanation!

Care to explain what goes on in a switch? I know that hubs simply
bridge the various legs of the network together. But (if I understand
it correctly) a switch makes a packet known only on the port that would
be interested in it. But, is that by IP or MAC address?

Seems like a switch can't have too much processing power built in it,
but then again I think they have a complicated job to do.

....Bob

On Fri, 24 Sep 2010 13:41:57 -0400, Bob K <(E-Mail Removed)>
wrote:

>Fantastic explanation!

I grimace when I skim back over it, knowing it could easily be picked
apart, but thanks.

>Care to explain what goes on in a switch? I know that hubs simply
>bridge the various legs of the network together. But (if I understand
>it correctly) a switch makes a packet known only on the port that would
>be interested in it. But, is that by IP or MAC address?

Most switches work at Layer 2, the MAC layer. Here's perhaps more than
you wanted to know: http://en.wikipedia.org/wiki/Network_switch
As you can see, other Layers are possible, but I'm most familiar with
the small unmanaged switches you'd find in SOHO applications. Layer 2
switches learn the MAC address of each connected device and associate
it with the corresponding switch port, so that when traffic comes in
it will know where to forward it.

>Seems like a switch can't have too much processing power built in it,
>but then again I think they have a complicated job to do.

More complicated than a hub, I suppose, since a hub simply sends a
packet out of every interface except the one it came in on.

On Fri, 24 Sep 2010 12:15:52 -0700 (PDT), Elton <(E-Mail Removed)>
wrote:

>The part that I was most interested in and that catched my attention
>was the:
>
>> The packet continues to get
>> forwarded by IP address until it hits a router at your ISP. If they're
>> doing double NAT, they will have a lookup table to see who made this
>> youtube request and they will rewrite the packet and forward it toward
>> you.
>
>especially the lookup table of requests because that was the thing I
>was looking for, an explanation for the internal mechanisms of the ISP
>to record requests with IPs between every level of NAT, and (maybe?)
>block unsolicited inbound traffic when they see that it has no match
>in the requests lookup table.
>So what you are saying is that my ISP is keeping track and mapping
>every single connection initiated by their customers to the outside
>servers?
>Does this mean that once this connection is initiated by me to the
>outside server and kept alive, afterwards this server could send me
>data/traffic or TCP packets that are not response to a request, to my
>external IP, and I could receive it because they are tunneled through
>the open connection and the ISP doesn't block it because it is in
>their lookup table ???
>
>If not, then I'll have to ask some more questions later because
>different scenarios bring up to me different questions about how
>things work, but for now they depend on the answer to the above
>question.

This is quickly getting over my head. Your ISP has to keep a session
table containing a "4-tuple" (4 pieces of related information) that
consists of your IP address and port and the destination IP and port.
Your IP obviously has to be sent so that the destination knows what
address to send the reply to, but your port is also sent (and is sent
back to you in the reply) so that your computer knows which
application should receive this data.

The session table gets populated with every new request, and to keep
it from growing out of control, entries are cleaned out when they are
finished (session closed) or they can be allowed to expire after a
configured elapsed time. I would assume that as long as a session is
active, data can be passed in either direction, but that may well be
too simplistic.

If you really want to know the details, the various RFC's are the
authoritative source. Here's one on NAT, for example:
http://tools.ietf.org/html/rfc3022
There are RFC's on everything related to networking.
http://tools.ietf.org/html/
You can enter your search terms and go from there.

Many thanks to all who offered information on this.

I, for one, have learned a lot. That is one good feature of these
newsgroups -- the exchange of ideas.

I am going to go crawl back into my 'lurk' mode :-)

....Bob