Topic: How is SME Server's host name known by the LAN?

[LANMonkey]

And what about the mysterious passing of the domain name accross the router?  If SME were doing it all by itself, then that's suspicious based on what I know about IP addresses, DNS and the rest -- however limited.  But I can see that IIS can do the same thing, so somewhere the domain name is traveling along with the IP address.  Maybe in the "application layer" of TCP/IP?

[cactus]

And what about the mysterious passing of the domain name accross the router?  If SME were doing it all by itself, then that's suspicious based on what I know about IP addresses, DNS and the rest -- however limited.  But I can see that IIS can do the same thing, so somewhere the domain name is traveling along with the IP address.  Maybe in the "application layer" of TCP/IP?

No, your questions are way out of the scope of SME Server, if you are really looking for the technical details you should read the concerning RFC documents that describe the standards. Computers are only known by there IP number in the computer world, the hostname is a translation (easier for users). In the basic a list of hostnames and there correlated IP numbers is registered on the DNS server. All systems know which is the DNS Server they should look for (either this is configured explicitly or by dynamic settings when they receive their IP number). They ask which IP Number belongs to the hostname and in turn try to contact the IP number that is communicated back to them from the DNS.

My advice is to read up on basic networking principles if you are really interested in the technical background. Here is a list of DNS related RFC documents: http://www.dns.net/dnsrd/rfc/

[LANMonkey]

That's a pretty technical reference to a simple question.

I think I understand the basics.  For HTTP, for example, the client browser gets a domain name and then goes out looking for a DNS server to give it an IP address that is represented by the name.  It then uses that IP address to get the page it wants.  For example, I can use an IP address directly on my LAN to get a page from one of my servers, "192.168.0.123/index.htm".

When I use a router with NAT, or something like it and my ISP connection has an address then if I can get a domain name out there for the IP address of that connection, then somebody out there on the internet can make an inquiry to that name and expect that if the router had a website, the router might give a page in response.

But also the router can forward the request to another server in the LAN using the internal private IP addresses of the servers.  But say there are two servers, then the router can only forward to one unless a different port is requested by the outside request along with the router's IP address and this different port is forwarded to the second server.  I've set up my LAN like this myself.

What comes next is you can assign more than one name to the same IP address for the router's ISP connection.  But since the router is only dealing in IP addresses, then how can different domain names be assigned to different IP addresses in the LAN?  Yet I can see that my LAN is set up so that a web server can distinguish between domain name requests that have been made from outside the LAN.  Somewhere information about the domain name must be crossing into the LAN else the web server cannot redirect the request to either a virtual website or another server on the LAN which is what I am doing here.

The technical details of how this occurs must be reduced to a simple answer to a simple question, "How does information about the external domain name request cross over the router into the LAN?"  Either it comes along with the actual traffic, or somehow the webserver is communicating with a DNS somwhere, or ... ?

[Boris]

The technical details of how this occurs must be reduced to a simple answer to a simple question, "How does information about the external domain name request cross over the router into the LAN?"  Either it comes along with the actual traffic, or somehow the webserver is communicating with a DNS somwhere, or ... ?

Here is your simple(r) answer:
Nobody on the Internet knows about your internal LAN layout. The most outside DNS server can do is to direct all requests for domain.name to your current ISP assigned IP. That is external IP of your router. Your NAT router can only pass traffic to internal host by port destination unless it really smart and more complicated that simple residential grade router/gateway/firewall. All http (80) traffic can be directed to single internal host regardless of HTTP header, that include the actual domain.name of the webpage requested. There is nothing so far that knows how to read the http on the application level and direct traffic to correct internal host.

Now that request came (hopefully) to your web server, it reads the request and decide if it can be served from the local folder,  rejected or served from the other web server via proxypass.
Again, until packet reaches the application that can decode HTTP (webserver, proxy server or similar), it only operates on the network layer. Firewall that uses reverse proxy protocol could help you, but its not the scope of this discussion. Simple (but effective) proxy based redirection is offered to you via proxypass directive on SME.

[LANMonkey]

Here is your simple(r) answer:
Nobody on the Internet knows about your internal LAN layout. The most outside DNS server can do is to direct all requests for domain.name to your current ISP assigned IP. That is external IP of your router. Your NAT router can only pass traffic to internal host by port destination unless it really smart and more complicated that simple residential grade router/gateway/firewall. All http (80) traffic can be directed to single internal host regardless of HTTP header, that include the actual domain.name of the webpage requested. There is nothing so far that knows how to read the http on the application level and direct traffic to correct internal host.

Now that request came (hopefully) to your web server, it reads the request and decide if it can be served from the local folder,  rejected or served from the other web server via proxypass.
Again, until packet reaches the application that can decode HTTP (webserver, proxy server or similar), it only operates on the network layer. Firewall that uses reverse proxy protocol could help you, but its not the scope of this discussion. Simple (but effective) proxy based redirection is offered to you via proxypass directive on SME.

OK, indirectly, that delivers the final clue, "HTTP Headers".  This is what goes along with the request that delivers up the domain name accross the router and independent of the IP address.

http://en.wikipedia.org/wiki/HTTP_header

http://en.wikipedia.org/wiki/Virtual_hosting

The answer to the question, "How does information about the external domain name request cross over the router into the LAN?" is "The domain name is the 'host' part of the HTTP request header.  It is the request that carries this information.  The IP address is just the place to deliver the request."

[LANMonkey]

Two and a half years later and I am back again going over this bit of correspondence.  Smoothwall is out, SME is my gateway and I was trying to forward an incoming port to a second computer on the LAN and I assumed that web-manager's security option would be doing that.  It doesn't.  It forwards incoming ports to another port on the same computer.

As mentioned above, I need ProxyPass:

http://wiki.contribs.org/SME_Server:Documentation:FAQ#Proxy_Pass

[cactus]

As mentioned above, I need ProxyPass:

http://wiki.contribs.org/SME_Server:Documentation:FAQ#Proxy_Pass

Perhaps, but what is you question? Why are you reviving this thread with above information?

[LANMonkey]

I was just making a note for reference sake.  It was not my intention to revive the thread.  I frequently use this site for a reference as I am expected to do.  Sometimes, even with an old thread, I'll add that the thread solved my problem too.

If the post was a problem, go ahead and delete it.

Maybe it should be an option to post a reply without moving it to the top of the que.

[cactus]

If the post was a problem, go ahead and delete it.

It was not a problem, it was merely wondering if you perhaps had issues implementing the proxypass configuration, but it seems you used it successfully:

I'll add that the thread solved my problem too.

[LANMonkey]

Thank you for your concern.  I haven't even looked into it yet, but I don't anticipate any problems.  If I have to come back for help, I'll start a new thread.