Boundary Routers

[config t]

Are boundary routers relevant or can they be entirely replaced by firewalls?

It wasn't until recently that we started using a MBL on the FW (updated by threat feed) to replace manual Null0 routes on our exterior (Screen) routers. So now I am questioning the usefulness of our outer routers. We have an inbound ACL on the outer routers that blocks some stuff and things like spoofed interior networks and we use them for BGP peering and TACLANE connections to black core. Other than the TACLANE connections I have a hard time deciding if they are even necessary anymore.

[Otanx]

As always it depends. Our edge routers are getting full tables from a couple different up streams, and partial tables from others. Our firewalls wouldn't be able to handle that. Palo routing limits are 100K each of IPv4 and IPv6. So I can't accept everything there. Even a single full feed for IPv4 is like 800K routes now. Also if you have a non-ethernet hand off. We still have a production T1 circuit on one of our networks. I am not aware of a firewall with anything except ethernet interfaces. Finally, if you connect to the firewall directly how do you handle HA on the firewalls? I would rather have a single router instead of a single firewall. There are probably other use cases, but if you don't have a use case then it is just another point of failure, and extra cost.

-Otanx

[icecream-guy]

Boundary routers are also very good for creating tunnels to cloud environments, AWS, Azure, etc..   You don't want them inside, nor outside, so at the boundary is a good place, especially if one is hosting public services in the cloud.

[deanwebb]

Bulk traffic discards. For traffic that's a no-brainer to block, why burden the firewall with processing it?

[Dieselboy]

I've never used them except when needing BGP pairing.

However QoS is better on routers compared to ASA where it's almost non-existent in the new ASA code. Whereas in older ASA code you could at least police traffic.

Boundary routers are also very good for creating tunnels to cloud environments, AWS, Azure, etc..   You don't want them inside, nor outside, so at the boundary is a good place, especially if one is hosting public services in the cloud.

I really like this consideration. I am terminating the VPN tunnel on the ASA at the moment.

[icecream-guy]

Boundary routers are also very good for creating tunnels to cloud environments, AWS, Azure, etc..   You don't want them inside, nor outside, so at the boundary is a good place, especially if one is hosting public services in the cloud.

I really like this consideration. I am terminating the VPN tunnel on the ASA at the moment.

The routers have more tunnel configuration capability than the ASA.

[config t]

This is the kind of input I was looking for (and expected )  I never considered or encountered routing table entry size limitations. Thinking about it, I wouldn't want my firewall to be handling edge routing unless it was a small environment and not expected to grow. I also didn't consider non-ethernet handoffs or HA configurations since we don't terminate to either of those at the moment.

Based on what I have I think I could never do without it simply because I terminate HAIPE connections to the provider there. I've never heard of anyone connecting a TACLANE directly to a FW and I feel like that would be a science experiment.

Dean, when you say bulk traffic discards, are you talking about Null0 routes? We do stuff like discards of inbound multicast, private networks, spoofed interior stuff, etc.

We don't do any cloud tunneling, although I have been wondering how these connections are made to physical infrastructure. The end point (cloud connection), is this AWS/Azure? What does the tunnel configuration look like? Is it just a GRE/IPSEC in cloud syntax?

[Otanx]

KGs can go behind firewalls. They just need the IPSec ports open both directions. In my world this is the more common configuration. You don't want to expose them to the world.

Tunnel configs are going to depend on use cases. You can terminate IPSec to firewalls, some will do basic GRE. You want DMVPN, or other advanced tunneling stuff? You will need a router.

Bulk traffic drop is a good use case. Like Dean said if you can drop it early it reduces the load on the firewall. We actually do this with a server configured to grab blacklists from different sources, generate a route list, and the server uses BGPd to peer with our edge routers. A route-map on the edge router sets those to Null0 route. Combined with uRPF we drop any inbound traffic from those IPs.

Also even if you do BGP on the firewalls a lot of advanced BGP features are just not implemented. If you want to set communities, or prepend AS, etc. you will probably need a router.

-Otanx

[deanwebb]

Side note: I first learned about bulk routers doing Null0 routing about 7.5 years ago on a forum with a name very similar to this one...

[config t]

KGs can go behind firewalls. They just need the IPSec ports open both directions. In my world this is the more common configuration. You don't want to expose them to the world.

Tunnel configs are going to depend on use cases. You can terminate IPSec to firewalls, some will do basic GRE. You want DMVPN, or other advanced tunneling stuff? You will need a router.

Bulk traffic drop is a good use case. Like Dean said if you can drop it early it reduces the load on the firewall. We actually do this with a server configured to grab blacklists from different sources, generate a route list, and the server uses BGPd to peer with our edge routers. A route-map on the edge router sets those to Null0 route. Combined with uRPF we drop any inbound traffic from those IPs.

Also even if you do BGP on the firewalls a lot of advanced BGP features are just not implemented. If you want to set communities, or prepend AS, etc. you will probably need a router.

-Otanx

We definitely have KGs behind our boundaries. Now that you mention that though, since we are a tenant, so we do not see the world, anything that comes in for GRE is very specific on the in/out ACL on the routers sitting on either side of the FW. I think the only reason we really have that outer router at this point is to terminate with the Black Core TACLANE and pair BGP. We use it for some other secret shizz but it's super specific.

[wintermute000]

There are definitely FWs that can handle full tables. Ask me how I know.

Now if you wanted to build an ISP edge with 4x full dual stack feeds across 2 different locations then I would probably tell you to buy MX/ASR and stick your FWs behind them yeah.

But if you had just a simple edge design with 1 or 2 internet links (and why in this case would you do full feeds anyway?) then its not uncommon, seen it many times, works fine as long as you use a FW that can do real BGP.
The only drawback is that they are all stateful so you won't be doing asymmetric routing e.g. the multiple ISP full table scenario, though there are ways around this e.g. turning off symmetry in a virtual domain so you basically carve out a dumb virtual router. Again, ask me how i know lol.

In fact some FWs can do some pretty sophisticated load balancing which for an enterprise customer may get more value than any amount of fancy schmancy full tables. As user traffic is all NAT this actually works quite well to spread the load, and unlike full tables you can actually control what is going on e.g. prefer circuit 2 for O365.

@Otanx if you think communities and route maps and prepends and route reflectors are sophisticated then be prepared to be amazed. This is all par for the course for Fortinet or PAN. Even the more obscure knobs like always-compare-MED. OFC there is still a gap, for example PAN still can't do local-as. Both PAN and Forti can run multiple virtual 'contexts' AND route between them internally. And within those contexts run VRFs again.

Ultimately you are going to need the fWs anyway so if they can handle it and your design is fit for purpose, why not (again see my high end example above of when i would suggest going with routers at the edge).

Also because firewalls run HA pairs the design can actually look a lot simpler compared to 2 separate traditional routers doing separate routing. i.e. its one logical box going to 2 links, not two logical boxes going to 2 links and each other.

[Otanx]

Looks like I am behind the times on firewall routing. I just looked up the config guide for PAN. Looks like they have done quite a bit in this area. You do bring up a good point with asymmetric routing. That is always a pain.

-Otanx

[config t]

Looks like I am behind the times on firewall routing.

-Otanx

Same. And boundary routing apparently. This was all really good info.

[wintermute000]

With a Forti, you can create an asymmetrical-enabled VDOM (i.e. basically like an SRX in packet mode) to act as a 'dumb' router in front of your security VDOM. And then run a HW accelerated inter-VDOM link between the two. So you don't even have to buy the dumb router you might need in front if you have an asymmetrical requirement. Its a nice trick, esp. as the throughput on those boxes in L4 mode is frankly quite ridiculous!