Thanx for the thoughtful response. It appears that we've got a good group of people on the list.
I would still venture that in most implementations, firewalls provide a superset of a router's functionality, because they look at packets, determine source/destination, and send the data on their merry way (within the context of a security policy, of course). In addition, a firewall can perform NAT. I look at my firewalls as routers with a cool GUI alternative to router ACLs, and a kick-ass L3+ state table. You know, similar to the argument that Unix is DOS on steroids (OK, OK, belay my last!). =8O I also stand behind my assertion that it's the firewall's *obligation* (whether or not you take advantage of it) to be able to communicate routes about which it *solely* has knowledge (sorry if the manufacturers "cringe" while facing that responsibility!). In my case, I have VPN gear and frame relay routers hanging off a second DMZ. Many of you probably are using your firewalls to terminate VPN tunnels. Aside from the easy cases, such as single-user aggressive-mode clients to whom you dole out IPs from a well-known pool (you probably have statics already in place in your internal routing environment), wouldn't you like to know when a branch office comes up? What about when the same branch decides to pop up on a different gateway? I'll venture that no one will fault me for wanting to firewall all of these types of connections, yet no one seems to think that the internal network needs to know how to reach hosts at the end of these connections? Perhaps I'm the only one trying to leave static-ville... Ideally, resources accessed by those connection types would be isolated, but that's simply not feasible for some resources (eg. a 2nd instance of our SAP environment would be *very* expensive to provide, and my sanity would be further questioned, but I digress...). BTW, how can *I* own my very own "Phillips hammer?" Dave Row CCNA, MCSE, CCSA Senior Network Analyst -----Original Message----- From: Brian Ford [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 12, 2002 4:09 PM To: Dave Row Cc: [EMAIL PROTECTED] Subject: Re: OSPF *on* Check Point FW-1 Dave, >I've been monitoring/researching threads re: OSPF neighbors >separated by a firewall. I've worked and worked on this, and have given up >on the notion (BTW, it boils down to hellos [both multicast and unicast] >being sent with a TTL of 1, *not* simply opening the right ports/protocols). >Too many people that have never touched a sniffer keep commenting on this >OSPF issue. Good stuff. I'd agree with your assessment. >For security reasons, I don't like the idea of tunneling OSPF through the >firewall (via GRE or whatever), because there's no way for the firewall to >apply policy to the tunnel traffic (if the tunnel were maliciously used to >pass non-OSPF traffic, the firewall would be oblivious). Your words imply that you view Firewalls as the only security mechanism or policy enforcement point in your network. That could be (in your case). Tunneling is a viable option for lots of scenarios. Policy enforcement and route pruning can be done elsewhere (on devices other than Firewalls). >Many contributors out there seem to feel that passing routing info across a >firewall is a "bad thing." A firewall *is* a router (and by virtue, it has >an obligation to participate in enterprise routing), but let's consider >real-life needs, such as bringing B2B connections through your firewall (a >"good thing"). If I have frame and VPN routers sitting on an isolated leg >of the firewall, I *certainly* need to know about those routes as they pop >up and down (static = "bad thing"). Although I do not terminate VPN >connections *on* my firewalls, the firewall should be able to inject those >routes into your routing environment, as well. A Firewall is not necessarily a router (But boy if it was you'd make lots of folks where I work happy). It's a policy enforcement point between two networks and a packet forwarder. It's not necessarily a router as not all forwarders perform all routing functions. I'm certain several Firewall manufacturers are cringing at your assertion that Firewalls have an obligation to participate in enterprise routing. I believe that much of the "bad thing" tag comes from the fact that in many environments security policies are enforced differently at different sites. Do you want every computer in a branch to know about all the routes to other branches as well as the entire HQ network? Well, maybe you do and maybe your security policies are up to securing that data. >Now, I'm now trying to locate an OSPF product that can be installed *on* the >firewall. Good luck. If you are ever looking for a hammer that also has a Phillips head screw driver built in; let me know. I know a place where you can buy those. Liberty for All, Brian At 12:01 PM 6/12/2002 -0700, [EMAIL PROTECTED] wrote: >Message: 1 >From: "Dave Row" <[EMAIL PROTECTED]> >To: <[EMAIL PROTECTED]> >Subject: OSPF *on* Check Point FW-1 >Date: Wed, 12 Jun 2002 11:06:43 -0400 > >Howdy, folks. I've been monitoring/researching threads re: OSPF neighbors >separated by a firewall. I've worked and worked on this, and have given up >on the notion (BTW, it boils down to hellos [both multicast and unicast] >being sent with a TTL of 1, *not* simply opening the right ports/protocols). >Too many people that have never touched a sniffer keep commenting on this >OSPF issue. Onward... > >For security reasons, I don't like the idea of tunneling OSPF through the >firewall (via GRE or whatever), because there's no way for the firewall to >apply policy to the tunnel traffic (if the tunnel were maliciously used to >pass non-OSPF traffic, the firewall would be oblivious). > >Many contributors out there seem to feel that passing routing info across a >firewall is a "bad thing." A firewall *is* a router (and by virtue, it has >an obligation to participate in enterprise routing), but let's consider >real-life needs, such as bringing B2B connections through your firewall (a >"good thing"). If I have frame and VPN routers sitting on an isolated leg >of the firewall, I *certainly* need to know about those routes as they pop >up and down (static = "bad thing"). Although I do not terminate VPN >connections *on* my firewalls, the firewall should be able to inject those >routes into your routing environment, as well. > >Now, I'm now trying to locate an OSPF product that can be installed *on* the >firewall. The Nokia implementation natively supports several routing >protocols, but I'm running v4.1 SP5 on NT Enterprise. I'm not concerned >about the security implications, because it's easy enough to block OSPF >on/from interfaces, hosts, nets, etc. GateD *sounded* cool, until I learned >that it's only available on Unix (comments withheld, so please point your >flame throwers elsewhere). > >So, does anyone out there have a recommendation for (or any successes with) >an OSPF module that can be installed under NT/2000? Much appreciated. > > >Dave Row >CCNA, MCSE, CCSA >Senior Network Analyst -- Firewalls mailing list - [ [EMAIL PROTECTED] ] To unsubscribe: http://www.isc.org/services/public/lists/firewalls.html
