Dynamic routing on firewalls.

Mailman List Mirror (Read Only)
21

Of course you can find firewalls that are crappy routers and you can find
routers that are crappy firewalls, but generally, the two are not mutually
exclusive.

I completely disagree w/ such or similar statements.
On the vendor datasheet it says different. On books it says different.
And on real life it's different.

No, really it does not.

Firewalls are firewalls. Routers are routers. Routers should do some very
basic filtering (stateles, ACLs, data plane protection...) and firewalls
should do basic static routing. And things should not go far beyond that.

We can agree to disagree.

If you keep thinking like that you will soon believe an L3 switch is a
firewall too.

An L3 switch is just another kind of router and if it’s got the ability for its
switching matrix to include a packet classifier that can be preprogrammed for
the appropriate firewall functions at line rate in hardware, then, yes, it’s a
perfectly fine firewall, and, probably about the only solution that’s really going
to work in a high line-rate scenario, actually.

Firewalls and routers belong to different places in a serious topology.

You and I apparently have very different ideas of serous topologies.

Only small networks should have both functions in the same box. It raises
risks, makes different kernel tasks competing to each other for the same
resources. You may run out of states, memory and CPU specially if mixing
NAT & tunneling beyond firewalling and routing. A router nowadays has many
tasks to accomplish, from 6to4, dual stacking, to multiple routing services
(bgp, ospf, bfd). Don't add extra duties to the box.

If you are firewalling so far away from the edge that any of this matters, you have
already lost and your topology is very hard to consider “serious” in my opinion.

Multiple purpose systems that can act like both things (say, a Linux box),
but it's just not right to have more than one critical service in the same
box. They should be distributed along your network. A firewall in front of
the router, a firewall after the router in front of the servers.

I’m thinking more like a large Juniper with an ESPIC or other services
interface hardware solution.

I just had a huge problem with an engineer who decided that a router should
be his CGN, and when the number of translated sessions run above the
expected and planned capacity, the box just sit down unresponsive. All of
this company (and it's a banking company, not an ISP who just pays some SLA
debit and it's good to go) connectivity was offline due to this confusion
of service profiles on the same box, and all, means servers and hosts with
registered IP addresses, not only RFC1918 addresses that needed to be
translated.

You can always choose the wrong box for the job. I bet I can point to plenty of
routers that could have handled his CGN needs just fine and had plenty of memory
to hold all of his translated sessions.

This is no different than if he chose an incorrect CGN box that was purpose-built.

Your example is like saying “The 2514 was not adequate as a 100Mbps firewall,
so all routers are inadequate as firewalls”.

The 2514 was not adequate or even capable of being a 100Mbps router.

We just split the functions, distributed firewall and CGN to different
boxes and topologies in a much more logical way and the "auto DoS feature"
just went away.

That’s certainly one viable solution. Maybe even the right one for that particular
space. However, it does not change anything I said.

So, please, don't insist. A firewall is a firewall. A router is a router. A
translation box is another alien. Unless you are SMB or willing to pay over
dimensioned boxes to mix all duties up together, which will be more
expensive than distributing the services alongside the network.

Technically, a router is any device which takes an IP datagram on one interface
and delivers it to an interface with a different network number (whether the same
(hairpin) or another interface) after decrementing the TTL or Hop Count (depending
on whether IPv4 or IPv6).

Other than the (rather silly in virtually all circumstances) Layer 2 firewalls mentioned
earlier, every firewall is technically a router. Not every router is a firewall, though there
are plenty of routers that are also very capable firewalls.

I will grant you that there are virtually no purpose-built firewalls that make good routers,
but that’s yet another issue truly unrelated to what I said.

As to translation devices, well, those also have no place in a serious topology other
than dealing with limitations of an aging and hopefully soon to be deprecated protocol
that should have been obsoleted years ago.

Owen

22

Setup a multi tenant setup between Nexus 7K and Juniper Net screen 5400 FW
using OSPF.
It went OK and worked. However when under traffic load/ less than.
Desirable results... OSPF peer failure / bounces etc.

However using BGP with Juniper SRX FW has been working great. No issues
thus far.

23

I have some use cases where I have Fortinet firewalls running full ospf/ospfv3/bgp and it all pretty much just works without any issues. The CLI is a bit cumbersome, but apart from that its fine.

24

This is, at a network level, an echo of the "Software Tools" philosophy
that has served us exceedingly well for decades. Tools should do one
thing, they should do it well, and if/when we need to do more than one
thing, we should use tools in combination.

There's another advantage to this: if firewalls and routers &etc
are not the same system, then they can run different software on
different operating systems on different architectures -- providing
a significant measure of insulation against attacks unique to one
particular combination.

---rsk

25

> Firewalls are firewalls. Routers are routers. Routers should do some very
> basic filtering (stateles, ACLs, data plane protection...) and firewalls
> should do basic static routing. And things should not go far beyond that.

This is, at a network level, an echo of the "Software Tools" philosophy
that has served us exceedingly well for decades. Tools should do one
thing, they should do it well, and if/when we need to do more than one
thing, we should use tools in combination.

And then reality comes and disagrees with you :slight_smile:
I am a fan of the "use the right tool for the right job", but it is not
always possible due to economical/technical/political reasons.

I had situations where running dynamic routing on firewalls was the way to
go to allow for geographic distribution of traffic without having to touch
routers and/or firewalls when adding/deleting subnets. Devices would just
learn routes and if permitted by the firewalls, traffic would pass.

There's another advantage to this: if firewalls and routers &etc
are not the same system, then they can run different software on
different operating systems on different architectures -- providing
a significant measure of insulation against attacks unique to one
particular combination.

This is a bit of a fallacy, because considering all things equal, a router
looks at only Layer 3/4 headers to route a packet, whereby a firewall will
look more deeper up the stack (considering a simple scenario, not
considering MPLS stuff). Even if they run the same OS but with different
functions enabled, a firewall having a vulnerability because it mishandles
TCP packets with SYN/RST flags set, it does not mean it will be vulnerable
as a router.

I know companies running firewall back to back from different vendors just
to make sure that they are secure if someone "hacks" one of the firewalls.

My point is that:

1) you can run dynamic routing on a firewall without issues
2) it depends on the situation if it advisable to do so
3) there is no size fits all scenario whereby it is verboten to have
anything else than static routes on a firewall
4) you have to consider the pros/cons about doing it or not doing it

26

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

27

Owen's point is that passing packets if the firewall is down is really poor
security-wise. If you run in that configuration, I simply DoS your firewall
(probably from one set of IP addresses), and then once it has fallen over and
is being bypassed, I send my *real* malicious traffic from some other IP
address, totally uninspected and unhindered. Much hilarity, hijinks, and
pwnage ensues.

28

Hello Valdis,

If this is really the point, I don’t know what system you are talking about, that will behave like that. If I run a closed firewall, kernel-path, and it’s unable process, and therefore “allow” the traffic, it will drop. If I run it netmap-ipfw and it’s unable to move the packet from one port to the other, it will drop. So there’s no point where a bridge implicits traffic bypass upon starvation/exaustion, unless this is your option to do so, or a default system behavior, in this case a system that should not act for this purpose.

If I remember well (and I remember some effusive expressions like “L2 functions easily enabled at scale on a Junos Trio system”), on a Juniper box bridging is processed on Trio chip - even without IRB set up, as well as firewall (limited matching conditions in a bridged domain). If you can exhaust TRIO from your DoS approach (and the idea is that you can’t exhaust it without exhausting line rate first), you will have no bridging anyway, since L2 learning and forwarding will also be resource starved.

But this is just all theoretical, as I mentioned you will probably reach line rate limit first if the box is not configured wrong or wrongly planned.

29

>> 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.
>
> Owen's point is that passing packets if the firewall is down is really poor
> security-wise. If you run in that configuration, I simply DoS your firewall
> (probably from one set of IP addresses), and then once it has fallen over and
> is being bypassed, I send my *real* malicious traffic from some other IP
> address, totally uninspected and unhindered. Much hilarity, hijinks, and
> pwnage ensues.

Hello Valdis,

If this is really the point, I don’t know what system you are talking about

The one *you* mentioned - "passing packets with firewall is down". Owen
was pointing out that is a silly configuration:

30

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.

Owen's point is that passing packets if the firewall is down is really poor
security-wise. If you run in that configuration, I simply DoS your firewall
(probably from one set of IP addresses), and then once it has fallen over and
is being bypassed, I send my *real* malicious traffic from some other IP
address, totally uninspected and unhindered. Much hilarity, hijinks, and
pwnage ensues.

Hello Valdis,

If this is really the point, I don’t know what system you are talking about

The one *you* mentioned - "passing packets with firewall is down". Owen
was pointing out that is a silly configuration:

An explicit decision regarding bypass ports, as I mentioned if someone does not want a redundant approach and doesn’t want availability issues if power is down or system is overloaded.

Not an inherit behavior or a must. Not related to being L2 our L3. Just a mentioned possibility. Not a limitation, not a recommendation. In the previous e-mail I mentioned “whatever option you want” upon failure, traffic still flowing, traffic bypassed, traffic dropped, L2+STP redundancy, no redundancy at all. So please don’t refer to one single option and pointing it as a failure of the methodology nature if you consider a decision/project error, and in this case just do it the other way, opting out from bypass and dropping or failing over, upon exhaustion or failure. Back to the point, doesn’t have to be different or limited from what you get in L3 firewalling.