We just had "business" cable installed with a few static IPs.
There is a server behind the comcast-supplied cable/router on a local
IP: 10.1.10.253. I set up a static NAT on the router so that one of our
public IPs is translated to this private IP. From outside, on the
internet, everything works great.
The problem is the clients on the inside. They have a local IP of the
same network (10.0.0.0) our domain name, of course, points to the public
IP of our server. The comcast router will not route the public IP from
the local interface back to the local IP of the server. - so if someone
on the LAN goes to our domain, say "ourdomain.com", they get a public
IP, say: 75.144.162.81 (not real).
I can't figure out how to get this public IP to route to the server.
Does anyone have any recommendations? The server is running FreeBSD so I
can use any ipfw rules that I want.
> We just had "business" cable installed with a few static IPs.
> There is a server behind the comcast-supplied cable/router on a local
> IP: 10.1.10.253. I set up a static NAT on the router so that one of
> our
> public IPs is translated to this private IP. From outside, on the
> internet, everything works great.
>
> The problem is the clients on the inside. They have a local IP of the
> same network (10.0.0.0) our domain name, of course, points to the
> public
> IP of our server. The comcast router will not route the public IP from
> the local interface back to the local IP of the server. - so if
> someone
> on the LAN goes to our domain, say "ourdomain.com", they get a public
> IP, say: 75.144.162.81 (not real).
>
> I can't figure out how to get this public IP to route to the server.
> Does anyone have any recommendations? The server is running FreeBSD
> so I
> can use any ipfw rules that I want.
What do internal clients use for DNS? could do some sort of split
DNS. the rest depends on the actual model of router.
> We just had "business" cable installed with a few static IPs.
> There is a server behind the comcast-supplied cable/router on a local
> IP: 10.1.10.253. I set up a static NAT on the router so that one of our
> public IPs is translated to this private IP. From outside, on the
> internet, everything works great.
>
> The problem is the clients on the inside. They have a local IP of the
> same network (10.0.0.0) our domain name, of course, points to the public
> IP of our server. The comcast router will not route the public IP from
> the local interface back to the local IP of the server. - so if someone
> on the LAN goes to our domain, say "ourdomain.com", they get a public
> IP, say: 75.144.162.81 (not real).
>
> I can't figure out how to get this public IP to route to the server.
> Does anyone have any recommendations? The server is running FreeBSD so I
> can use any ipfw rules that I want.
>
>
> Thanks
> Martin
>
I was about to suggest a DNS solution as well.
Create a local DNS server which, for all other domains than your own, is
simply a caching server. For your own domain, make it authoritative, and
set the DNS entries for your domain appropriately.
Then whatever DHCP service you use, can be reconfigured to set the
internal DNS server as your network's DNS server.
On the other hand, I can;t picture the layout of your
router/server/network setup. Your description is somewhat mixed, and I
am unsure of whether the FreeBSD server you mention is the comcast
router too, or not.
Some machine somewhere has to be doing the NAT, and, this is presumably
the same as your 'FreeBSD' server. Is this also the router?
On Thu, 2007-11-01 at 12:48 -0400, Martin Klingensmith wrote:
> We just had "business" cable installed with a few static IPs.
> There is a server behind the comcast-supplied cable/router on a local
> IP: 10.1.10.253. I set up a static NAT on the router so that one of our
> public IPs is translated to this private IP. From outside, on the
> internet, everything works great.
>
> The problem is the clients on the inside. They have a local IP of the
> same network (10.0.0.0) our domain name, of course, points to the public
> IP of our server. The comcast router will not route the public IP from
> the local interface back to the local IP of the server. - so if someone
> on the LAN goes to our domain, say "ourdomain.com", they get a public
> IP, say: 75.144.162.81 (not real).
>
> I can't figure out how to get this public IP to route to the server.
> Does anyone have any recommendations? The server is running FreeBSD so I
> can use any ipfw rules that I want.
You need to use a router that supports "local loopback".
Unfortunately it's a feature that's rarely mentioned, so it's a crap
shoot whether one supports it or not.
As an alternative, set up a DNS server on your LAN that the machines
point to.
As a final alternative, have each client enter your domain name and the
machines local IP address in their HOSTS file. This solution may be
easiest in the beginning, but a bear to maintain.
>> I can't figure out how to get this public IP to route to the server.
>> Does anyone have any recommendations? The server is running
>> FreeBSD so I
>> can use any ipfw rules that I want.
>
> You need to use a router that supports "local loopback".
>
> Unfortunately it's a feature that's rarely mentioned, so it's a crap
> shoot whether one supports it or not.
It seems to be like a second router should make this "easy" in
addition to improving security by implementing your "DMZ" lan.
And routers are awfully cheap these days. I haven't tried to
do something like this with the available low-end router software
that's out there these days.
(Hmm. Interesting question: does DDWRT run on a standard x86
box for purposes of prototyping router configurations? Bring
it up and debug it on a spare PC, measure pps an cpu requirements,
and then (maybe) replace with tiny router box for esthetic reasons?)
Anything I can do on a hardware router I can do in FreeBSD, it's just
that the nice web interface formulates the routing rules for me.
Unfortunately (or fortunately) I'm no expert at throwing packets around.
Back "in the day" (8-10 years ago) there were many single-floppy linux
distros that would turn your old 486 into a NAT router. This was when
the Linksys style routers would cost you $300.
I think the best solution is to setup BIND on the FreeBSD server (which
is separate from the comcast router, BTW)
Enter it as the DNS server for the DHCP server and I should be all set,
with fingers crossed.
> addition to improving security by implementing your "DMZ" lan.
> And routers are awfully cheap these days. I haven't tried to
> do something like this with the available low-end router software
> that's out there these days.
>
> (Hmm. Interesting question: does DDWRT run on a standard x86
> box for purposes of prototyping router configurations? Bring
> it up and debug it on a spare PC, measure pps an cpu requirements,
> and then (maybe) replace with tiny router box for esthetic reasons?)
>
> BillW
>
> It seems to be like a second router should make this "easy" in
> We just had "business" cable installed with a few static IPs.
> There is a server behind the comcast-supplied cable/router on a local
> IP: 10.1.10.253. I set up a static NAT on the router so that one of our
> public IPs is translated to this private IP. From outside, on the
> internet, everything works great.
>
> The problem is the clients on the inside. They have a local IP of the
> same network (10.0.0.0) our domain name, of course, points to the public
> IP of our server. The comcast router will not route the public IP from
> the local interface back to the local IP of the server. - so if someone
> on the LAN goes to our domain, say "ourdomain.com", they get a public
> IP, say: 75.144.162.81 (not real).
>
> I can't figure out how to get this public IP to route to the server.
> Does anyone have any recommendations? The server is running FreeBSD so I
> can use any ipfw rules that I want.
>
>
> Thanks
> Martin
>
Problem is your router isn't doing hairpin redirection.
The simplest answer is just to add an entry to the hosts file on your
client PC's such that http://www.foo.com points to 10.1.10.253.
Alternately use a spare box and put PFsense on it as your firewall.
Even if you install a DNS server on your local network you still need to
get the clients to use it which might not be easy in any given modem
firmware. Your better off bridging the modem and sticking the data into
something that can actually deal with it.
> You don't need bind for that, there are several lightweight options for that.
> BIND can be run as cache-only server (forwarding to the ISP's DNS).
>
But the whole point of the internal dns server is it runs as both an
"authoritive" and a cache, that way the internal clients get normal
results for most domains but different ones for your domain.
A server that does only authoritive or only caching (as a lot of the
lighter weight ones do) is useless for this.
On Nov 1, 2007, at 10:48 AM, Martin Klingensmith wrote:
> We just had "business" cable installed with a few static IPs.
> There is a server behind the comcast-supplied cable/router on a local
> IP: 10.1.10.253. I set up a static NAT on the router so that one of
> our
> public IPs is translated to this private IP. From outside, on the
> internet, everything works great.
Why did you set up the static NAT at all and not just use the public
address directly on the server?
I'm using Comcast's Business-class service here, and systems that need
to be public are given their public IP's directly with the router's
public address as their router interface, and they work fine.
> The problem is the clients on the inside. They have a local IP of the
> same network (10.0.0.0) our domain name, of course, points to the
> public
> IP of our server. The comcast router will not route the public IP from
> the local interface back to the local IP of the server. - so if
> someone
> on the LAN goes to our domain, say "ourdomain.com", they get a public
> IP, say: 75.144.162.81 (not real).
>
> I can't figure out how to get this public IP to route to the server.
> Does anyone have any recommendations? The server is running FreeBSD
> so I
> can use any ipfw rules that I want.
I think I'd go the above route (no pun intended) first -- why bother
with the added overhead of the NAT when it's not necessary?
natetech.com