When I set up the default gateway routing through our
firewall, I used the following commands on the Cisco router
that is between our firewall and our Intranet:
ip default-network 199.85.231.0
This identifies the default network, or route, which is the one
between the router and the firewall. This should work fine
regardless of whether you are using a Class B or a Class C
network number.
If you type the command 'show ip route' on any other Cisco
router in your Intranet after your routing protocol has had
time to update, you should see a similar entry to the
following:
Gateway of last resort is 198.135.216.223 to network
199.85.231.0
I have another Cisco router on the Internet side of the
firewall as well, with another default-network command in it
facing toward our ISP's network. Note that these default
network commands always face outward, into the Internet.
The firewall is set up the same as well, with the default-route
facing outward, not inward. The reason for this is that
inward, or toward the Intranet, all the network numbers are
known - it is only outward, or toward the Internet, where
network numbers and their route is not explicitly known. The
firewall and the routers have to be configured so they know
about all network numbers on your Intranet. Then, any ip
address on a network they don't explicitly know about they
will assume is on the Internet and use the default route.
I used static route entries on the firewall for all network
numbers in our Intranet, and IGRP on all our Intranet Cisco
routers. No need this way to run RIP between the firewall
and the Cisco router, configure the router to redistribute
RIP, etc. The single Cisco router between our firewall and
our ISP required no routing protocol, since the firewall we
purchased gives us address isolation. (The only ip address
visible from the Internet side of our firewall is the ip address
of the external interface of the firewall.) The Internet-side
router knows about the ip network between the firewall and
itself from the ip address configured on the interface, so
needs no additional routing declarations there, and an
address on any other ip network has to be on the Internet,
so the default-network routing command applies.
If your firewall doesn't give you address isolation, I
recommend you use static routing entries on your
Internet-side router for all your Intranet-side ip network
numbers. This will be much more secure than configuring
your firewall to allow IGRP or some other routing protocol to
pass to and from your Internet-side router. (I expect your
firewall does provide address isolation, since I see you've
listed the first of the 16 Class B Reserved Network numbers
in your example, but I decided to give complete information
here for Posterity.....)
One other consideration, in case you only have one ip
network number on your Intranet, is a default gateway
configuration on each PC, etc. If you only have been using
one network number until now you wouldn't have needed it
before. The default gateway ip address to use would be the
address of your Cisco router that connects them to the
firewall. As in all cases, the default gateway ip address must
be, a) on the same ip network as the host requiring it, and
b) a router that is part of the routing protocol you are using,
so it knows how to route to all other networks.
And finally, for security purposes, I recommend you
disallow telnet sessions to the Internet-side router as I did
on ours. This means you have to physically connect a
terminal or similar device to a TTY port on the Cisco router
to work on it yourself, but it makes it so no one from the
Internet can putz around on your router either. It's not really
that big of a deal if you permanently attach an async line off
a terminal server port to, say the console port of the Cisco
router. If you do connect it permanently, just make sure you
block incoming telnet connections on the async line too so
you don't have a backdoor around your firewall.
Hope this fixes it for you.
Rod C--
>>> John H. Kerr <jhkerr @
ashton .
csc .
com> 08/31/96
02:27pm >>>
I was wondering if anyone has a solution to this problem. I
have a Sun Sparc5 running SunOS 4.1.3, with this I have
Firewall-1 2.0 running on top of it. I also have a CISCO
4000 setup as an Internal router. The problem that I'm
having is that I'm unable to receive information back to my
machines sitting behind the Internal router. The exact
trouble seems to be the firewall does not know how to route
back into my "Internal" networks. The setup is like this:
Internet ------ ISP Router ----- FW ----- CISCO 4000 ------
Internal Nets
172.16.1.0 172.16.2.0 172.16.*
I intially set the routing table on the FW to be
DEST Nexthop
172.16.1 172.16.1.1 (local)
172.16.2 172.16.2.1 (local)
default ISP router
172.16.0.0 CISCO 4000
This didn't work.
I turned routed on within the Firewall, but when I did, the
default route (0.0.0.0) from the CISCO added a *new*
default route to the Firewall.
default Cisco
and it took precedence over the one I installed. Since the
FW and the CISCO ping-ponged packets all day, nothing
communicated. The default route of the CISCO router is
overriding the default route that I have set on the FW. I
have set the Metric Flag on the router to be higher that the
FW in hopoes that the FW would take precednece, but this
did not work. IS there a way to set something up on the
SUN to force its default route to be used or is there a way
to stop the CISCO's default route from taking over. I also
tried not setting the 'route of last resort' on the CISCO
hoping that the RIP update from the FW would fill in the
default route. It didn't. Shouldn't this work? Is there a way
on the CISCO to set a default route and not have it sent out
in a routing update? BTW, what is the proper way to set
the default route on a CISCO? I've been using:
ip route 0.0.0.0 172.16.2.1
Has anyone else with a class "B" address run into this
problem before? I know this can be solved if I obtained a
class C, subnet it, and use it on either side of the FW.
That way there would be an unambigious route to 172.16
from the FW's point of view. However that's not an option
right now. Any help is appreciated.
|
|
