> On Feb 8, 2015, at 06:02 , Patrick Tracanelli <eks...@freebsdbrasil.com.br> > wrote: > > Hello, > >> >> Some Juniper models actually do a very good job of being both. >> >> In reality, a Firewall _IS_ a router, even if it's a bad one. Anything that >> moves packets from one interface to another is a router. > > Technically it’s quite not a precise assumption. While routing is much likely > an IP core need and OSI Layer 3 related mechanism, a firewall does not have > to basic L3 forwarding. It can be a bridged/bright firewall, may fit in front > of a router, protecting it, and carrying. Not routing anything. In fact in a > fail-safe scenario (from availability perspective) a bridged firewall may be > shut down completely and a Bypass por pair taking place will keep traffic > flowing, “moving packets from one port to another” without actually ever been > a router.
Technically true, but bridged firewalls are pretty much passe these days in the real world. As a general rule, when the firewall is shut down, one usually doesn’t want the packets flowing past un-hindered. The fact that this is kind of the default of what happens with bridged firewalls is just one of the many reasons hardly anyone still uses such a thing. > I have recently added netmap-ipfw in front of BGP routers protecting ‘em from > DDoS attacks, adding line-rate firewalling capabilities to a commodity x86/64 > box or a T5 card for 10GbE/40GbE, and netmap-ipfw itself acts like > mentioned, passing packets back and forth between interfaces without ever > routing anything. Sure, there are all kinds of things one can do. Some of them are good ideas, many of them are not. If it works in your environment and you’re OK with the failure modes and other tradeoffs, then more power to you. > >> Of course, the support for routing protocols is a useful feature in a router >> and one of the areas where firewalls often fall short. >> >> Where you want to put things (in front, behind, etc.) really depends on your >> topology and the problem you are trying to solve. >> >> Personally, I like to keep the firewalls as close to the end hosts as >> possible. This tends to greatly simplify security policies and make them >> MUCH easier (and more reliable) to audit. > > I agree. A firewall belongs better closer to the end hosts being protected. > Maybe protection of the router is the only exception when RTBH will not fit > the task (or just won’t be enough). DDoS mitigation on site is a questionable and usually losing proposition at best. Other than DDoS mitigation, any good router should be perfectly capable of protecting itself. For protecting a router from DDoS that it cannot properly protect itself, one needs to be able to control or alter the delivery of packets across the upstream link from the upstream side anyway. That is best done by an off-site service such as Akamai’s Prolexic. > Therefore, close to the end host usually means far from the core routers. > Unless one is really considering a CPE device doing poorly jobs of “a router > and a firewall”… Depends on the nature of your network. I know lots of datacenter networks where the end hosts are not more than one or two hops removed from the core routers. I would hardly refer to those networks as a CPE device doing a poor job of “router and firewall”. Owen
