Hi,
We have used dynamic routing on firewall in the old days. We did experience several severe outages due to this setup (OSPF en Cisco). As you will understand i’m not eager to go back to this solution but I am curious about your point of views.
Is it advisory to so these days?
Kind regards,
David
Any specific firewall in mind? As this depends from vendor to vendor.
I've had some issues with OSPF and CheckPoint firewalls when the firewalls
would be overloaded and started dropping packets at the interface level
causing adjacencies to go down, but I solved this by using BGP instead and
the routing issues went away.
On Juniper things tend work OK.
Other than this, make sure you don't run into asymmetric routing as
connections might get dropped because the firewall does not know about them
or packets arrive out of order and the firewall cannot reassemble all of
them.
It all depends how much of the firewall functionality is implemented in CPU.
The biggest problem is that firewalls that implement functionality in
software usually saturate CPU when stressed (e.g. DOS) and routing
protocols start dropping.
I'm a strong believer in having a router that can do basic filtering
in hardware (specifically uRPF) as the first line of defense in a DOS
attack and then using a firewall behind that to reach your security
policy goals. We have a pretty large network so we've expanded the
concept of RTBH filtering internally and use a small ISR (currently
1841) to inject routes into our network to disable hosts using uRPF at
the first router they hit. The entire thing is scripted and works
very well at containing problematic hosts centrally.
The other thing to watch out for IMHO is the NGFW hype. I haven't
seen a NGFW that can actually do everything it claims to at the same
time and meet advertised performance levels. You're much better off
splitting up the workload and having a series of components
architected to work with each other.
Hi Eugeniu,
Agreed. Assymmetric routing is not your friend unless you plan accordingly.
I use OSPF and BGP quite a bit on Juniper SRX. Works great.
Hi Ray
Hi,
We are running Juniper SRX5000 family with around 40ish routing-instances,
most of them using OSPFv2 without any issues. The RIBs are not too big,
just a couple of them with thousands routes. I know that some guys are
testing a similar environment on Fortigates and I'm not aware of any issues
with routing so far.
We also have SRX's running BGP+BFD (srx240) and again no issues at all.
As Eugeniu mentioned, just be careful with the asymmetric routing, then is
straight forward.
Hope it helps.
Santiago
Hi David,
a router is a router and a firewall is a firewall.
Especially a Cisco ASA is no router, period.
A router in front of the firewall is my choice, it also keeps broadcasts from the firewall + can do uRPF.
rm
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. 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.
Owen
A router behind the firewall is nice too.
It insulates the firewall from direct end-user traffic.
It also makes for a cleaner cutover from one firewall to another. (Instead
of the edge getting stuck ARPs their perspective of the network remains
unchanged.)
It also allows for stateless ACLs on both ends of the firewall.
Man-o-man did I find that out when we had to renumber our network after we
got bought by the French.
Oh, I'll just pop on a secondary address on this interface... What?
Needed to go through fits just to get a hairpin route in the thing.
The ASA series is good at what it does, just don't plan on it acting like
router IOS.
Sorry, but I'm with Owen.
Square : Rectangle :: Firewall : Router
A firewall is a router, despite how much so many security folk try to deny
it. And firewalls that seem to try to intentionally be crappy routers
(ie, ASAs) have no place in my network.
If it can't be a decent router, then its going to suck as a firewall too,
because a firewall has to be able to play nice with the rest of the
network, and if they can't do that, then I have no use for them. I'll get
a firewall that does.
Just because a cat has kittens in the oven, you don't call them biscuits. A firewall can route, but it is not a router. Both have specialized tasks. You can fix a car with a swiss army knife, but why would you want to?
Is it a metric swiss army knife?
A good firewall can also be a good router.
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.
Owen
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.
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.
If you keep thinking like that you will soon believe an L3 switch is a
firewall too.
Firewalls and routers belong to different places in a serious topology.
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.
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 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.
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.
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.
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”...
You're missing the point.
I would never advocate for trying to deploy a Juniper MX in the role of a
firewall to provide a security boundary. I would never try to deploy a
Juniper SRX to provide a huge number of GRE tunnel terminations or other
sorts of aggregations of large numbers of connections or however you might
describe a typical router role.
But that SRX does have different IP addresses in different networks on its
various interfaces, and when traffic transits through the SRX, it looks at
the layer 3 addressing information to determine where the traffic needs to
be sent. Ergo, it is a router. You can deny it all you want, but you're
only shooting yourself in the foot by not acknowledging that and dealing
with its implications. And as a router, if a vendor wants me to put it on
my network, it better dern well be a well behaved router to begin with,
and in my network, that means OSPF and BGP. Only once it behaves as a
router can its efficacy as a firewall really be considered.
I completely agree that you don't want to overload any particular device
with too many functions. I've got MXes that terminate a large number of
GRE tunnels, but I've also SRXes terminating a large number of IPSec
tunnels that are basically acting as routers because they can handle the
large quantity of crypto operations involved better than an MX. But while
the SRXes that terminate the large number of IPSec tunnels do some amount
of firewalling, and I only did that grudgingly because of financial
reasons. The firewalling will probably be moved off to a separate set of
SRXes as this project grows.
You're missing the point.
I'm not missing, I'm just diverting the point.
As I mentioned from a Linux box example, the fact that it can both act as a
router and a firewall does not mean it should. I disagree with the
simplistic idea that if a firewall L3 forwards, it's a router, or if a
router has ACLs capabilities, it's a firewall.
Someone just illustrated how a mission-critical placed firewall protecting
a BGP router may do it bridged, without actually routing not a single extra
hop.
I would never advocate for trying to deploy a Juniper MX in the role of a
firewall to provide a security boundary. I would never try to deploy a
Juniper SRX to provide a huge number of GRE tunnel terminations or other
sorts of aggregations of large numbers of connections or however you might
describe a typical router role.
So we agree!
I completely agree that you don't want to overload any particular device
with too many functions. I've got MXes that terminate a large number of
GRE tunnels, but I've also SRXes terminating a large number of IPSec
tunnels that are basically acting as routers because they can handle the
large quantity of crypto operations involved better than an MX. But while
the SRXes that terminate the large number of IPSec tunnels do some amount
of firewalling, and I only did that grudgingly because of financial
reasons.
Yes, I understand budget restrictions sometimes takes to accumulating
functions on the same box. But the notion that matters is that although a
firewall *can* be, technically, implemented in the same node, it just
belongs to somewhere else, in a distributed / separed box.
The firewalling will probably be moved off to a separate set of
SRXes as this project grows.
Yeah, in the end we mostly agree.
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