Charles Steinkuehler wrote:
>
> > > > So, in Dachstein, we do something like this:
> > > >
> > > > wan1_IP_EXTRA_ADDRS="x.y.z.64/26"
> > >
> > > This is not what you really want to do...see below
> >
> > Yes, but what about the NAT'ed internal network? Does it need a public
> > ip address on the customer's domain? Or, once the domain points
> > entirely to the DMZ, does it *not* matter what public ip address is
> > NAT'ed to the internal network?
>
> You're confusing me...what domain? How does the domain point entirely to
> the DMZ? Are you possibly talking about routes and IP addresses? If so,
> there's not really a problem. The firewall/router has two public IP's, one
> on the upstream link and one on the DMZ interface. All traffic from the
> internal net will be masqueraded behind the public IP of the firewall.
> Internal net access to DMZ sytstems will masquerade behind the public IP of
> the firewall DMZ interface.
Here's the issue:
a.b.c.156/30 wan network (domain: ISP.com)
a.b.c.157 local wan address (wan1)
a.b.c.158 remote wan address (peer)
x.y.z.64/26 public ip block (domain: customer.com)
x.y.z.64/26 dmz network
For example, when I ssh out to somewhere on the Internet from
192.168.1.101 and invoke `w' I see that I am FROM a.b.c.157.
This is OK for most situations, because all network traffic, originating
from the Internet, through the firewall should have destination on the
dmz.
However, what if I want to run ftpd on 192.168.1.101 and I want users to
use ftp://myhost.customer.com, *not* by ip or myhost.ISP.com ???
Yes, I know about port forwarding, &c.
*HOW* can I take one (1) address out of x.y.z.64/26, let's say x.y.z.72,
and have that address also bound to wan1?
Or, is this a matter of leaving x.y.z.72 unused by any actual system on
the dmz and portforwarding x.y.z.72:80 to 192.168.1.101:80? Since dmz
hosts cannot/should not have access to private, internal hosts, we
anticipate this to be a problem . . .
> Also, despite the fact that you have a route sending traffic for the whole
> /26 net out the DMZ interface, the way routing works in linux, more specific
> routes take precidence over less specific routes, so the route to your
> gateway IP via the T1 will override the /26 route, and the fact that a local
> interface is configured with a particular IP will cause any packets recieved
> for that IP to be directed to anything locally attached to that IP
> (netstat -ln).
>
> > Will this cause problems if somebody on the internal network wants to
> > run www or ftpd from the internal network?
>
> Well, they won't be visible from the outside world unless you port-forward
> or static-NAT...
>
> > > Let me know how this works out...I can only talk to our T1 through an
> aging
> > > Cisco 4000 that can't even ssh (IOS 11.2...but it does do nice protocol
> > > based priority queueing :)
> >
> > We're going to try this in a couple hours and we'll let you know.
>
> Oh...I almost forgot. If the proxy-arp thing doesn't work with your T1 link
> for some reason, you should be able to use static-NAT as a fall-back. This
> isn't quite as user friendly as proxy-arp (it's hard to get machines on the
> DMZ to talk to each other, and there's constant confusion when configuring
> regarding the public/private IP's, and which ones to use where), but if you
> can assign multiple IP's to your T1 and get packets on all of them, a
> static-NAT DMZ should definatly work.
>
> I'm pretty sure proxy arp will work properly, however, and do just what you
> need...
Actually, we are very pleased with the results using ProxyArp!
The only issue we had with your instructions were converting:
<intern>_PROXY_ARP=YES --> <dmz>_PROXY_ARP=YES
<intern>_ROUTES="x.y.z.64/26" --> <dmz>_ROUTES="x.y.z.64/26"
Once we understood this, everything worked as expected.
Thank you!
--
Best Regards,
mds
mds resource
888.250.3987
Dare to fix things before they break . . .
Our capacity for understanding is inversely proportional to how much we
think we know. The more I know, the more I know I don't know . . .
_______________________________________________
Leaf-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
