Re: Dynamic routing on firewalls.

[Patrick Tracanelli <eksffa () freebsdbrasil com br>]

> On 08/02/2015, at 22:48, Owen DeLong <owen () delong com> wrote:
>
> > On Feb 8, 2015, at 06:02 , Patrick Tracanelli <eksffa () 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.

Hello Owen,

I didn’t get your point.

On a bridged firewall you can have the behavior you want, whatever it is. Passing packets with firewall is down, but 
the box still up. Dropping everything if packet is down. Combining bypass ports + STP you can have the set of 
availability you wish better for your scenario, from simply bypassing everything like you have no box there, if a 
software or power failure occurs, or having an active failover bridged together on the bypass port, allowing for full 
firewalling redundancy if the primary box fails. So you are no leaking options if you are doing it on L2 instead of L3. 
You have additional ease, redundancy won’t require VRRP or similar stuff since it’s not L3 related.

To clarify, I am not saying a bridged firewall is a better option for every sort of scenario. Usually I do L3 firewall 
with the box being an extra hop on the topology, doing CARP for IP reduncancy, etc. But back to the point that a 
firewall doesn’t need to L3 forward, I like the idea of having a L2 firewall whenever an extra routing hop is not 
desired, and still won’t lack features and redundancy options.

> > 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.

I’m still missing what you are pointing as failure modes or tradeoffs.

IPFW does a pretty decent job on L2 filtering, with a particular exception of “ipfw fwd” which won’t work by default 
under this setup. I can drop unwanted L2 traffic - in fact I like to only allow IPv4,v6 and ARP by default on LLC, 
cisco discovery and RARP when needed, everything else dropped on L2. Therefore whenever I decide to add it bright, I 
still don’t miss 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). 
>
> 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.

Sadly true just in theory. On real world, people still run weak and low power boxes as routers, ranging from old Cisco 
boxes to Routerboards, Edgerouters and x86 boxes without any special card or technologies such as DNA, DPDK, Netmap, 
and therefore boxes that can’t hardly protect themselves against simple DDoS, while they still can route and do their 
job on calm water, won’t behave well on storms. We are not always talking about big telcos and people who can rely on 
an efficient and well dimensioned Juniper box.

Frequently, the “routers vs firewall” or “stateful vs stateles on the same box” confusion discussed on other recent 
threads in this group, just happens, and we get relatively big companies adding stuff like sonicwalls, fortinets, with 
BGP + a mix of security features on the same box, and certainly those boxes can’t hardly protect itself (but people 
still believe they can protect the whole network behind it). So, whether it’s caused by low power boxes or bad 
projects, the need for router protection is more often than it should.

> > 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”.

Yes, I may refer to a linux box, a VyOS, Endian, OpenBSD PF or a sonicwall box 2 hops after the core router a bad 
option for accumulating router+firewall functions if they are not protected on upper hops. Not due to any kind of 
feature or scalability miss (except for OpenBSD’s kernel and therefore firewall not scaling beyond CPU0). But due to 
their default behavior ranging from not protecting data plane from simple problems like ARP storm, up to the fact they 
will, by default, waste state entries for ordinary stuff like filtering. So, yes, they are usually doing poor jobs of 
being a router and a firewall. We see it very often, co-location setups failing due to exhaustion of resources or 
inability to self protect when uncalm packet flows reach their racks on data centers, but still the whole DC and 
previous hops still run perfectly up, available and unaffected. Sure it’s when they will earn/charge extra by adding 
firewall services… because customer boxes where doing their poor jobs of being both. So, back to the point, unless very 
well projected or engineered, they will need earlier protection.

I have just recently run into a situation where a Fortigate box that should add protection and balancing on a data 
center colo, just died exhausted by simple memory starvation. No matter the real cause (people tend to use those boxes 
doing everything they can do at once, and expecting it to work under uncontrolled circumstances), for the customer it 
was their core node. For the datacenter it was an end host. For me it was just a box doing bad jobs of being more than 
it should at once, and it had to be protected.

A couple months ago I have run into another scenario where a Juniper MX5 box was suffering from UDP DDoS with low 
packet size. It’s still not clear for me why Juniper was not sustaining the attack traffic, if it was a bad 
configuration or because the pps rate was close to 1GbE ports line rate limit, and the company in question didn’t want 
to pay for MX series upgrade to have 10G ports just for attack contention. We added a netmap-ipfw in front of the 
Juniper box with T5 10GbE ports filtering the profiled packet sized, and filtering other UDP patterns, which lead the 
Juniper box to do it’s routing job again without ever being upgraded to 10G licensed MX versions.

Sure an off-site protection would do the job before upstream. But no need for that many gun powder to kill such a small 
sized animal :) And just like most DDoS, it didn’t least forever.

And again, it was a non L3 forwarding firewall; no extra hop or relevant change in the topology. Sure L3 firewalls are 
more usual, it’s always been, it’s not a “nowadays” momentum. But a bright firewall still have its relevant place in 
the network, and it’s a firewall with no missing piece of functionality, IMHE.

--
Patrick Tracanelli