[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [suse-security] DMZ Setup is killing me!!
On Friday 02 July 2004 21:05, you wrote:
> > So let's examine scenario two, with non-reallife IP numbers.
> > Here you have 22.22.22.10 on eth1, 192.168.0.x/24 on eth0 and you choose
> > another net for the DMZ which MUST NOT be the same as on eth0 !
> > So, let's take 192.168.99.0/24 in this example. So eth2 becomes
> > 192.168.99.1
> >
> > >From there on it's simple; you make a series of rules like you had,
> >
> > FW_FORWARD_MASQ="0/0,192.168.99.4,tcp,80" if you have a webserver in the
> > DMZ with IP 192.168.99.4. Add other statements for other ports and/or
> > other servers to that same line, between those quotes, separated with
> > space. You mustn't forget to set the right gateway on your DMZ boxes;
> > they must have the IP you set to eth2 as their default gateway:
> > 192.168.99.1.
> > You may also have to make special arrangements so that internal hosts can
> > connect to the DMZ IIRC, but I don't remember offhand. Just try it.
> >
> >
> > Good luck,
> > Maarten
>
> I tried this because it looked like what was needed a coulple of days
> ago. it didn't seem to work but maybe I had something set up wrong. if
> this indeed is the setup, it narrows the field of possible remaining
> issues.
>
> is the eth on the firewall to the DMZ set as FW_DEV_DMZ or because it's
> technically another masq'd net is it FW_DEV_INT ??
No no, its definitely FW_DEV_DMZ.
Be careful how you test it; you will probably NOT be able to test the
connection from within, so you'll have to have access to another internet
connection to test from (or a remote host). Also, if you know halfway how to
interpret it, a sniffer can be an invalueable help if things do not work from
the start. Even if you can't interpret it, just seeing where the packet gets
sent to (or not) can be enlighting. Tcpdump or Snort are your friends.
You can start multiple sessions, each attached to the different eth's.
Not very relevant now, but:
The caveat I forgot to mention in comparing the first with the second scenario
is that when masquerading as you will do now, you can only have 1 machine in
your DMZ for each service, i.e. one webserver, one mailserver, etc, maximum.
This stems from the fact that you cannot masquerade one port to two systems,
whereas in the real-life IP numbers scenario you don't masquerade, just
route. And that of course works just fine with multiple IP's.
Another thing, if it wasn't already obvious, is that for the outside world,
your server(s) appear to have the IP number your firewall has: the ISP
address. But seen from the inside LAN this isn't so. From there, you just do
plain routing, so you address the DMZ servers by their actual IP.
This is only valid in scenario two, the masquerading one. Otherwise everything
is just addressed by their actual IP number (22.22.22.18 etc.)
Confusing ? Nah. ;-)
One last advice: Keep it simple, and take small steps. For example, never
test it with a browser / webpage. Test it with ping or ssh first and go on
to other, more complex, services from there. Also, never ever use DNS names
(unless it's really setup well, and triple-checked), instead always connect
to the IP numbers. Don't know it this was too obvious but one never knows...
Maarten
> Thanks!! I'll give it another try.
>
> Mike
--
Yes of course I'm sure it's the red cable. I guarante[^%!/+)F#0c|'NO CARRIER
--
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here