Networking Forums

Networking Forums > Computer Networking > Linux Networking > IP routing with remote DNS, but server & client on same subnet - how?

Reply
Thread Tools Display Modes

IP routing with remote DNS, but server & client on same subnet - how?

 
 
Randy Brick MacKenna
Guest
Posts: n/a

 
      10-16-2007, 02:24 PM
I'm trying to understand how IP addresses and packet routing work on
my home network. Here's what I have set up:

1. Three WinXP clients
2. One Linux server running Apache2
3. A Linksys router, and cable modem

I have a website running on the Apache server, which is listening on
port 32004. The Linux machine is at a static ip address of
192.168.1.10

On the Linksys router, I have my cable modem IP address port-forwarded
to the Linux server's IP address.

I also have a domain name registered, e.g. www.mydomain.net

At my registrar, I tell them to redirect www.mydomain.net to my cable
modem IP address, port 32004. Everything works fine -- when I'm "out
there" (physically out of my house) and on the internet, I can browse
to www.mydomain.net and I'm redirected to my little Apache server.

Now, what I'm wondering is this: When I am physically on my home
network, on one of my WinXP clients and I browse to www.mydomain.net,
is the Linksys router, or Apache (or both) smart enough to say "wait a
minute -- the domain and client are on the same subnet, so let me just
route the packets completely within the 192. domain" (?)

I'm asking this because when I am on my home network I'd rather not
have HTTP being served out through my ISP's network, and back to me.
It would be much more efficient if that traffic just stayed on my
private network.

Also, if this traffic does indeed go back out through my ISP, is there
some way for me to configure (using a hosts file, or something) to say
"only when you are on your home domain, then www.mydomain.net should
map to 192.168.10:32004" (?)

Thanks,
Randy

 
Reply With Quote
 
 
 
 
Andrew Madsen
Guest
Posts: n/a

 
      10-16-2007, 03:08 PM

"Randy Brick MacKenna" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> I'm trying to understand how IP addresses and packet routing work on
> my home network. Here's what I have set up:
>
> 1. Three WinXP clients
> 2. One Linux server running Apache2
> 3. A Linksys router, and cable modem
>
> I have a website running on the Apache server, which is listening on
> port 32004. The Linux machine is at a static ip address of
> 192.168.1.10
>
> On the Linksys router, I have my cable modem IP address port-forwarded
> to the Linux server's IP address.
>
> I also have a domain name registered, e.g. www.mydomain.net
>
> At my registrar, I tell them to redirect www.mydomain.net to my cable
> modem IP address, port 32004. Everything works fine -- when I'm "out
> there" (physically out of my house) and on the internet, I can browse
> to www.mydomain.net and I'm redirected to my little Apache server.
>
> Now, what I'm wondering is this: When I am physically on my home
> network, on one of my WinXP clients and I browse to www.mydomain.net,
> is the Linksys router, or Apache (or both) smart enough to say "wait a
> minute -- the domain and client are on the same subnet, so let me just
> route the packets completely within the 192. domain" (?)
>
> I'm asking this because when I am on my home network I'd rather not
> have HTTP being served out through my ISP's network, and back to me.
> It would be much more efficient if that traffic just stayed on my
> private network.
>
> Also, if this traffic does indeed go back out through my ISP, is there
> some way for me to configure (using a hosts file, or something) to say
> "only when you are on your home domain, then www.mydomain.net should
> map to 192.168.10:32004" (?)
>
> Thanks,
> Randy
>

What is the subnet of the XP stations? Does your Apache server have an
address internal to your network as well as the external address? If not
then you will always go out to the router and back in thus having potential
firewall issues. If you do have an internal address for your Apache server
then an entry in the hosts file pointing to the internal:32004 address will
keep it in house. The host file would need to be on all the XP clients. The
sequence is hosts file then DNS. If there is no internal IP then you can add
the line 192.168.10:32004 but you will most likely not notice any speed
difference between using a hosts file and the DNS server of choice.


 
Reply With Quote
 
Randy Brick MacKenna
Guest
Posts: n/a

 
      10-16-2007, 03:34 PM
On Oct 16, 11:08 am, "Andrew Madsen" <andrew.mad...@harley-
davidson.com> wrote:
> "Randy Brick MacKenna" <randymacke...@yahoo.com> wrote in messagenews:(E-Mail Removed) oglegroups.com...
>
> > I'm trying to understand how IP addresses and packet routing work on
> > my home network. Here's what I have set up:

>
> > 1. Three WinXP clients
> > 2. One Linux server running Apache2
> > 3. A Linksys router, and cable modem

>
> > I have a website running on the Apache server, which is listening on
> > port 32004. The Linux machine is at a static ip address of
> > 192.168.1.10

>
> > On the Linksys router, I have my cable modem IP address port-forwarded
> > to the Linux server's IP address.

>
> > I also have a domain name registered, e.g.www.mydomain.net

>
> > At my registrar, I tell them to redirectwww.mydomain.netto my cable
> > modem IP address, port 32004. Everything works fine -- when I'm "out
> > there" (physically out of my house) and on the internet, I can browse
> > towww.mydomain.netand I'm redirected to my little Apache server.

>
> > Now, what I'm wondering is this: When I am physically on my home
> > network, on one of my WinXP clients and I browse towww.mydomain.net,
> > is the Linksys router, or Apache (or both) smart enough to say "wait a
> > minute -- the domain and client are on the same subnet, so let me just
> > route the packets completely within the 192. domain" (?)

>
> > I'm asking this because when I am on my home network I'd rather not
> > have HTTP being served out through my ISP's network, and back to me.
> > It would be much more efficient if that traffic just stayed on my
> > private network.

>
> > Also, if this traffic does indeed go back out through my ISP, is there
> > some way for me to configure (using a hosts file, or something) to say
> > "only when you are on your home domain, thenwww.mydomain.netshould
> > map to 192.168.10:32004" (?)

>
> > Thanks,
> > Randy

>
> What is the subnet of the XP stations? Does your Apache server have an
> address internal to your network as well as the external address? If not
> then you will always go out to the router and back in thus having potential
> firewall issues. If you do have an internal address for your Apache server
> then an entry in the hosts file pointing to the internal:32004 address will
> keep it in house. The host file would need to be on all the XP clients. The
> sequence is hosts file then DNS. If there is no internal IP then you can add
> the line 192.168.10:32004 but you will most likely not notice any speed
> difference between using a hosts file and the DNS server of choice.


Thanks! Yes, all the XP clients are on the same subnet as the Apache
server (everyone is on 192.168.1.x).

Yes, I can get to my website by browsing to 192.168.1.10:32004 -- so
that's the Apache server's internal address.

The problem is that some of the content on the website has a link that
has the domain name "www.mysillydomain.net" as it's root -- so even if
I surf to 192.168.1.10:32004 I think when I click on one of those
links, I'm back out on the real internet -- unless it is 'smart
enough' to keep the traffic on the internal network (this is the part
I don't understand).

I'll look at the hosts file as a solution, but I have a feeling that
hardcoding something like that on my XP laptop client will mean that
if I'm out of my house then that mapping will no longer work -- since
in that case (when I'm out of my house) I do want to be going through
the internet.

Am I asking/hoping for too much?

-Randy

 
Reply With Quote
 
Stefan Monnier
Guest
Posts: n/a

 
      10-16-2007, 03:57 PM
> Now, what I'm wondering is this: When I am physically on my home
> network, on one of my WinXP clients and I browse to www.mydomain.net,
> is the Linksys router, or Apache (or both) smart enough to say "wait a
> minute -- the domain and client are on the same subnet, so let me just
> route the packets completely within the 192. domain" (?)


Yes and no.

> I'm asking this because when I am on my home network I'd rather not
> have HTTP being served out through my ISP's network, and back to me.
> It would be much more efficient if that traffic just stayed on my
> private network.


Rest assured that it will not go out to your ISP.

There are 2 possibilities:
1 - it won't work because the port remapping is only applied to packets
coming in from outside rather than from the local network.
This can happen depending on the details of how the port-forwarding
is done.
2 - it will work and the packets will go from the client to the router, then
to the server and the reply will go from the server to the router back
to the client.

I.e. it all goes through the router, but not through the cable modem.


Stefan
 
Reply With Quote
 
Randy Brick MacKenna
Guest
Posts: n/a

 
      10-16-2007, 05:36 PM
On Oct 16, 11:57 am, Stefan Monnier <monn...@iro.umontreal.ca> wrote:
> > Now, what I'm wondering is this: When I am physically on my home
> > network, on one of my WinXP clients and I browse towww.mydomain.net,
> > is the Linksys router, or Apache (or both) smart enough to say "wait a
> > minute -- the domain and client are on the same subnet, so let me just
> > route the packets completely within the 192. domain" (?)

>
> Yes and no.
>
> > I'm asking this because when I am on my home network I'd rather not
> > have HTTP being served out through my ISP's network, and back to me.
> > It would be much more efficient if that traffic just stayed on my
> > private network.

>
> Rest assured that it will not go out to your ISP.
>
> There are 2 possibilities:
> 1 - it won't work because the port remapping is only applied to packets
> coming in from outside rather than from the local network.
> This can happen depending on the details of how the port-forwarding
> is done.
> 2 - it will work and the packets will go from the client to the router, then
> to the server and the reply will go from the server to the router back
> to the client.
>
> I.e. it all goes through the router, but not through the cable modem.
>
> Stefan


Thanks! I like this theory (well, maybe to you it is a fact!) -- so
tonight I will try pulling the ethernet cable out of the cable modem
while a file transfer from my website is underway. If all stays on my
local network and no traffic out through the ISP, then the file
transfer (staying within the Linksys router) should be uninterrupted.

-Randy

 
Reply With Quote
 
Stefan Monnier
Guest
Posts: n/a

 
      10-16-2007, 08:34 PM
> Thanks! I like this theory (well, maybe to you it is a fact!) -- so
> tonight I will try pulling the ethernet cable out of the cable modem
> while a file transfer from my website is underway. If all stays on my
> local network and no traffic out through the ISP, then the file
> transfer (staying within the Linksys router) should be uninterrupted.


It may work. It may also fail because disconnecting the modem may force PPP
to take down the connection and interface and hence remove the external IP
and potentially remove the corresponding iptables rules as well, depending
on how the scripts work. It'll probably work, tho.

Another way to look at it is to run a tcpdump on the WAN side and look at
the packets that go through.


Stefan
 
Reply With Quote
 
Randy Brick MacKenna
Guest
Posts: n/a

 
      10-17-2007, 12:21 AM
On Oct 16, 4:34 pm, Stefan Monnier <monn...@iro.umontreal.ca> wrote:
> > Thanks! I like this theory (well, maybe to you it is a fact!) -- so
> > tonight I will try pulling the ethernet cable out of the cable modem
> > while a file transfer from my website is underway. If all stays on my
> > local network and no traffic out through the ISP, then the file
> > transfer (staying within the Linksys router) should be uninterrupted.

>
> It may work. It may also fail because disconnecting the modem may force PPP
> to take down the connection and interface and hence remove the external IP
> and potentially remove the corresponding iptables rules as well, depending
> on how the scripts work. It'll probably work, tho.
>
> Another way to look at it is to run a tcpdump on the WAN side and look at
> the packets that go through.
>
> Stefan


Here are my experiments. Tell me if it makes sense:

1. With the cable modem plugged in, I surfed to my website www.foodomain.net
(which is a server on my home network)
2. I surfed to a link to a large document (32Meg)
3. *Before* clicking on the link, I unplugged the cable modem
(disconnecting from the internet)
4. I clicked on the file link -- and it timed out, server
unreachable.

Next experiment:

1. With the cable modem plugged in, I surfed to my website www.foodomain.net
2. I surfed to a link to a large document (32Meg)
3. I *first* clicked on the link, then during the file transfer, I
unplugged the cable modem
4. The file transfer completed successfully!

So, from this I deduce that the internet connection is required only
for DNS -- but after that the actual routing of packets from the
server and the client (all within my home network) do not involve the
internet connect -- and stays off my ISP's network.

Does this sound right? If so, then the transport layer is already
very optimized and knows enough to stay within its own subnet if it
can. This is excellent, if correct.

Thanks,
Randy

 
Reply With Quote
 
Pascal Hambourg
Guest
Posts: n/a

 
      10-17-2007, 04:30 PM
Hello,

Randy Brick MacKenna a écrit :
>
> 1. With the cable modem plugged in, I surfed to my website www.foodomain.net
> (which is a server on my home network)
> 2. I surfed to a link to a large document (32Meg)
> 3. *Before* clicking on the link, I unplugged the cable modem
> (disconnecting from the internet)
> 4. I clicked on the file link -- and it timed out, server
> unreachable.
>
> Next experiment:
>
> 1. With the cable modem plugged in, I surfed to my website www.foodomain.net
> 2. I surfed to a link to a large document (32Meg)
> 3. I *first* clicked on the link, then during the file transfer, I
> unplugged the cable modem
> 4. The file transfer completed successfully!
>
> So, from this I deduce that the internet connection is required only
> for DNS -- but after that the actual routing of packets from the
> server and the client (all within my home network) do not involve the
> internet connect


IHMO this sounds a bit optimistic.

First, I believe there is more than just DNS. If you browsed the website
before unplugging the cable, it is likely that the DNS resolution was
already cached by the client. You said in your first post that you told
your registrar to redirect www.foodomain.net to
[your.public.ip.address]:32004. DNS does not handle ports (neither does
the the "hosts" file), so I guess there is some form of web indirection
(HTTP redirect, frame...) performed not by a DNS server but by a web
server hosting www.foodomain.net operated by your registrar. So I guess
the path is as follows :

1) User browses URL <http://www.foodomain.net/some/file>.
2) Browser sends a DNS query asking for the IP address of host
"www.foodomain.net".
3) DNS replies with the IP address of a registrar's web server.
4) Browser connects to that IP address on port 80 and asks for
"/some/file" on host "www.foodomain.net".
5) Web server replies that the document is actually at URL
<http://[your.public.ip.address]:32004/some/file>.
6) Browser connects to your.public.ip.address on port 32004.
7) Router transparently forwards the connection to 192.168.1.10.
8) Browser asks for page "/some/file" on that connection.

So, even though you cache the DNS resolution for www.foodomain.net, you
still need the internet connection in order to use the web redirection
performed by your registrar.

Second, even though your second test was successul, as Stefan wrote, the
port forwarding rule on the router may be bound to the internet link
state. I'll take for example the way the port forwarding is done in
Linux - I believe some Linksys routers run Linux. The port forwarding
rules is used only for the first packet of the redirected connection ;
then a NAT mapping is created for all other packets of that connection.
So if the transfer has started before the port forwarding rule is
removed, it does not stop. But any subsequent new HTTP connection will
fail because the port forwarding rule does not exist any more.

A workaround to all this would be a local DNS server resolving
www.foodomain.net into the private web server address and having the web
server listening on port 80.
 
Reply With Quote
 
Randy Brick MacKenna
Guest
Posts: n/a

 
      10-18-2007, 01:26 AM
On Oct 17, 12:30 pm, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org>
wrote:
> Hello,
>
> Randy Brick MacKenna a écrit :
>
>
>
>
>
> > 1. With the cable modem plugged in, I surfed to my websitewww.foodomain.net
> > (which is a server on my home network)
> > 2. I surfed to a link to a large document (32Meg)
> > 3. *Before* clicking on the link, I unplugged the cable modem
> > (disconnecting from the internet)
> > 4. I clicked on the file link -- and it timed out, server
> > unreachable.

>
> > Next experiment:

>
> > 1. With the cable modem plugged in, I surfed to my websitewww.foodomain.net
> > 2. I surfed to a link to a large document (32Meg)
> > 3. I *first* clicked on the link, then during the file transfer, I
> > unplugged the cable modem
> > 4. The file transfer completed successfully!

>
> > So, from this I deduce that the internet connection is required only
> > for DNS -- but after that the actual routing of packets from the
> > server and the client (all within my home network) do not involve the
> > internet connect

>
> IHMO this sounds a bit optimistic.
>
> First, I believe there is more than just DNS. If you browsed the website
> before unplugging the cable, it is likely that the DNS resolution was
> already cached by the client. You said in your first post that you told
> your registrar to redirectwww.foodomain.netto
> [your.public.ip.address]:32004. DNS does not handle ports (neither does
> the the "hosts" file), so I guess there is some form of web indirection
> (HTTP redirect, frame...) performed not by a DNS server but by a web
> server hostingwww.foodomain.netoperated by your registrar. So I guess
> the path is as follows :
>
> 1) User browses URL <http://www.foodomain.net/some/file>.
> 2) Browser sends a DNS query asking for the IP address of host
> "www.foodomain.net".
> 3) DNS replies with the IP address of a registrar's web server.
> 4) Browser connects to that IP address on port 80 and asks for
> "/some/file" on host "www.foodomain.net".
> 5) Web server replies that the document is actually at URL
> <http://[your.public.ip.address]:32004/some/file>.
> 6) Browser connects to your.public.ip.address on port 32004.
> 7) Router transparently forwards the connection to 192.168.1.10.
> 8) Browser asks for page "/some/file" on that connection.
>
> So, even though you cache the DNS resolution forwww.foodomain.net, you
> still need the internet connection in order to use the web redirection
> performed by your registrar.
>
> Second, even though your second test was successul, as Stefan wrote, the
> port forwarding rule on the router may be bound to the internet link
> state. I'll take for example the way the port forwarding is done in
> Linux - I believe some Linksys routers run Linux. The port forwarding
> rules is used only for the first packet of the redirected connection ;
> then a NAT mapping is created for all other packets of that connection.
> So if the transfer has started before the port forwarding rule is
> removed, it does not stop. But any subsequent new HTTP connection will
> fail because the port forwarding rule does not exist any more.
>
> A workaround to all this would be a local DNS server resolvingwww.foodomain.netinto the private web server address and having the web
> server listening on port 80.


Thanks...this makes sense to me. And you are right, any subsequent
HTTP requests will fail after I pulled the plug on the cable modem.
So, perhaps if the cable were left plugged in then the traffic indeed
may go out through my ISP.

I tell you, though, there is a noticeable speed difference when I'm on
my home network compared to when I'm outside my home, connected back
into my home-based Linux web server. So much faster that it seems to
me that traffic 'feels' like it is staying in my local network.

So, are you saying to really end the uncertainty, that if I ran a DNS
on my little Linux box, I could set it to always 'catch' www.foodomain.net
and point it to Apache, listening at 192.168.1.10:32004?

(note: I don't use port 80, since when I really do want to get to
this Apache server from the outside, I need to use a different port --
since my ISP blocks hosted traffic on port 80)

So...it sounds like configuring a DNS on my Linux machine might be the
trick (?) I wonder how hard that is...hmmm...

Thanks again,
Randy

 
Reply With Quote
 
Randy Brick MacKenna
Guest
Posts: n/a

 
      10-18-2007, 01:39 AM
On Oct 17, 12:30 pm, Pascal Hambourg <boite-a-s...@plouf.fr.eu.org>
wrote:
> Hello,
>
> Randy Brick MacKenna a écrit :
>
>
>
>
>
> > 1. With the cable modem plugged in, I surfed to my websitewww.foodomain.net
> > (which is a server on my home network)
> > 2. I surfed to a link to a large document (32Meg)
> > 3. *Before* clicking on the link, I unplugged the cable modem
> > (disconnecting from the internet)
> > 4. I clicked on the file link -- and it timed out, server
> > unreachable.

>
> > Next experiment:

>
> > 1. With the cable modem plugged in, I surfed to my websitewww.foodomain.net
> > 2. I surfed to a link to a large document (32Meg)
> > 3. I *first* clicked on the link, then during the file transfer, I
> > unplugged the cable modem
> > 4. The file transfer completed successfully!

>
> > So, from this I deduce that the internet connection is required only
> > for DNS -- but after that the actual routing of packets from the
> > server and the client (all within my home network) do not involve the
> > internet connect

>
> IHMO this sounds a bit optimistic.
>
> First, I believe there is more than just DNS. If you browsed the website
> before unplugging the cable, it is likely that the DNS resolution was
> already cached by the client. You said in your first post that you told
> your registrar to redirectwww.foodomain.netto
> [your.public.ip.address]:32004. DNS does not handle ports (neither does
> the the "hosts" file), so I guess there is some form of web indirection
> (HTTP redirect, frame...) performed not by a DNS server but by a web
> server hostingwww.foodomain.netoperated by your registrar. So I guess
> the path is as follows :
>
> 1) User browses URL <http://www.foodomain.net/some/file>.
> 2) Browser sends a DNS query asking for the IP address of host
> "www.foodomain.net".
> 3) DNS replies with the IP address of a registrar's web server.
> 4) Browser connects to that IP address on port 80 and asks for
> "/some/file" on host "www.foodomain.net".
> 5) Web server replies that the document is actually at URL
> <http://[your.public.ip.address]:32004/some/file>.
> 6) Browser connects to your.public.ip.address on port 32004.
> 7) Router transparently forwards the connection to 192.168.1.10.
> 8) Browser asks for page "/some/file" on that connection.
>
> So, even though you cache the DNS resolution forwww.foodomain.net, you
> still need the internet connection in order to use the web redirection
> performed by your registrar.
>
> Second, even though your second test was successul, as Stefan wrote, the
> port forwarding rule on the router may be bound to the internet link
> state. I'll take for example the way the port forwarding is done in
> Linux - I believe some Linksys routers run Linux. The port forwarding
> rules is used only for the first packet of the redirected connection ;
> then a NAT mapping is created for all other packets of that connection.
> So if the transfer has started before the port forwarding rule is
> removed, it does not stop. But any subsequent new HTTP connection will
> fail because the port forwarding rule does not exist any more.
>
> A workaround to all this would be a local DNS server resolvingwww.foodomain.netinto the private web server address and having the web
> server listening on port 80.


Okay, I did some reading on setting up a local DNS -- but I think that
may cause some other problems. Some people mentioned that it could
screw up connections to secure websites, like banking.

So, I guess maybe I'm back to the hosts file.

But, if I edit a hosts file on my XP laptop, that will be fine when
I'm connected to my home network (it will say to just map www.foodomain.net
to 192.168.1.10:32004) -- but if I use my laptop outside of my home,
when I'm traveling, and I want to get to my foodomain website -- then
that hosts file will cause it to fail, since I'm not on my home
network anymore.

I guess some sort of dynamic hosts file, based on which network I'm
connected to, would be the trick...

-Randy

 
Reply With Quote
 
 
 
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Routing - Computers on either subnet have problems finding PCs on the other subnet ZZYZX Windows Networking 2 03-26-2011 01:01 AM
"The client could not connect to the remote computer. Remote connections..." - Server 2003 Maestro Windows Networking 4 10-25-2007 06:58 PM
"The client could not connect to the remote computer. Remote connections..." - Server 2003 Maestro Windows Networking 5 10-17-2007 01:14 AM
OpenVPN working between client and server only, but not able to access any machines in server subnet GS Linux Networking 10 12-06-2006 10:48 AM
Client subnet mask wrong when using Windows Server 2003 DHCP Tim R Windows Networking 2 01-02-2004 07:13 PM



1 2 3 4 5 6 7 8 9 10 11