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. 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. > 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). 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”... -- Patrick Tracanelli
