DMZ routing issues - HELP PLEASE

I have set up two firewalls and created a DMZ. The layout is as follows:

LAN ====> Firewall1 =====>DMZ =====>Firewall2 =====>Internet

The LAN is on a 10.0.0.0/24 private range
The DMZ is on a 192.168.100.0/24 private range

From the LAN I can ping the internal NIC of firewall2.
From the DMZ I can browse the Internet.

Machines in the LAN cannot see anything past the internal NIC of firewall2.
I suspect that I need to set up routes on firewall2 to point back to the
LAN.

I have added the following route on firewall02:

route add -net 10.0.0.0 netmask 255.255.255.0 dev eth0

This does not seem to help. Where am I going wrong?

By bypassing the second firewall, this works:
LAN ======> Firewall1======>Internet

By connecting to the DMZ, this works:
DMZ======>Firewall2======>Internet

But when I put it all together, it does NOT work.
LAN ======> Firewall1======>DMZ======>Firewall2======>Internet

I believe that there is a route missing?



"Davide Bianchi" <davideyeahsure@onlyforfun.net> wrote in message
news:slrnd4vmg2.190.davideyeahsure@fogg.onlyforfun .net...
> On 2005-04-03, news.uunet.co.za <pjtdownes@hotmail.com> wrote:
> > I suspect that I need to set up routes on firewall2 to point back to the
> > LAN.
>
> I suspect that you misconfigured your firewall, so all the connection are
> dropped by your second firewall.
>
> > Where am I going wrong?
>
> In not investigating the problem. Start by using a packet inspector
> on the external firewall to see if packests sent by your lan are routed
> to the internet and if you get an answer, if you do, see which answer
> and follow it to wherever is routed to.
>
> Davide
>
> --
> C:\WINDOWS>DEL *.*
> I feel better now.

news.uunet.co.za wrote:

[please, don't top post or edit/drop info. makes answering a pain]

[re-arranged]
>
>
> "Davide Bianchi" <davideyeahsure@onlyforfun.net> wrote in message
> news:slrnd4vmg2.190.davideyeahsure@fogg.onlyforfun .net...
> > On 2005-04-03, news.uunet.co.za <pjtdownes@hotmail.com> wrote:
> > > I suspect that I need to set up routes on firewall2 to point back
to the
> > > LAN.

You'll need network routes for all subnets on all IS routers.

> > I suspect that you misconfigured your firewall, so all the
connection are
> > dropped by your second firewall.
> >
> > > Where am I going wrong?

Don't worry about firewalls till you have basic connectivity (ping)
working.

> > In not investigating the problem. Start by using a packet inspector
> > on the external firewall to see if packests sent by your lan are
routed
> > to the internet and if you get an answer, if you do, see which
answer
> > and follow it to wherever is routed to.

$ ping and $ traceroute (and excess brain cells;) should be all you
need to establish proper connectivity. Right now you just need to find
out _where_ your packets are being dropped.

> By bypassing the second firewall, this works:
> LAN ======> Firewall1======>Internet
>
> By connecting to the DMZ, this works:
> DMZ======>Firewall2======>Internet
>
> But when I put it all together, it does NOT work.
> LAN ======> Firewall1======>DMZ======>Firewall2======>Internet
>
> I believe that there is a route missing?

Your belief is likely (multiply) well founded ;)

If you can disconnect from the internet easily, do so.

Turn off _all_ firewalls.

Choose one host in lan and slowly, tediously get connectivity working.

$ ping the following:

127.0.0.1
local host's IP address
local host's GW router (lan nic on FW1)
DMZ nic on FW1
DMZ nic on FW2
Internet nic on FW2

Where does it fail to return?

Check $ /sbin/route -n
and confirm that there is an entry for _all_ subnets you wish to reach
(directly or indirectly) from/through this machine.

Continue nic-by-nic, machine-by-machine. Ie., get the lan host to
successfully $ ping all the way to Internet nic on FW2. Move on to FW1
and confirm $ ping to all other nic IPs, using the same tedious
process. Repeat on DMZ machine and FW2.

Once you can $ ping from anywhere to anywhere (that you desire), you
might want to connect to DMZ servers/daemons just to confirm all is
well and as expected.

If there are any glitches, you might try to $ traceroute to the IPs.

Now, you can bring up firewalls one at a time, starting at lan host,
then FW1, then DMZ, then FW2. Confirm that connectivity continues
working at each stage as it should. Now you know why disabling $ ping
(ECHO) replies out of a misguided sense of "added security" will
eventually cause grief ;)

Here is where a packet sniffer may be handy. Iptables' logs can also
be helpful if you configure/turn them on and know what you're looking
for.

Remember, that you can have only one _default_ route (normally), but
there is no reason why you cannot have multiple gateway/network routes.
It might be good to review the networking howtos and add/confirm the
needed route entries one-by-one as you are establishing connectivity.

Yes, it is tedious and a pain-in-the-arse to be so anally methodical,
but if you don't keep the number of changes (varibles) to a minimum as
you go, you can really confuse yourself -- doesn't take much for me ;)

BTW, presumably, you are NATing only at FW2 and you are not running DNS
on the lan.

hth,
prg

news.uunet.co.za wrote:
> I have set up two firewalls and created a DMZ. The layout is as follows:
>
> LAN ====> Firewall1 =====>DMZ =====>Firewall2 =====>Internet
>
> The LAN is on a 10.0.0.0/24 private range
> The DMZ is on a 192.168.100.0/24 private range
>
> From the LAN I can ping the internal NIC of firewall2.
> From the DMZ I can browse the Internet.
>
> Machines in the LAN cannot see anything past the internal NIC of firewall2.
> I suspect that I need to set up routes on firewall2 to point back to the
> LAN.
>
> I have added the following route on firewall02:
>
> route add -net 10.0.0.0 netmask 255.255.255.0 dev eth0
>
> This does not seem to help. Where am I going wrong?
>
In not having a proxy server in the DMZ that arranges internet access
for LAN clients? I'd say that if you go through the trouble of setting
up a DMZ, you don't allow *anything* from LAN to Internet, not even
related traffic, in case someone tricks your FW into seeing something as
'related' that shouldn't be

detha