Off-Path firewall with Traffic Engineering

Andrea Dainese
March 02, 2023
Post cover

I used to deploy a simple network architecture for two main reasons.

  • They are easy to debug/troubleshoot
  • Engineers who came after can easily understand and manage them.

With these rules in mind, I usually deploy in-line firewalls, meaning that traffic is routed through a firewall that is placed “in the path”:

Inline firewall (L3 diagram)

Sometimes things are complicated, and we need to deploy “off-path” firewalls, and traffic is partially routed through the firewall:

Off-path firewall (L3 diagram)

There are many reasons why we want to do so.

  • We want to test a new firewall
  • We do not have enough budget for a big firewall to manage the entire traffic.
  • We must exclude some latency-sensitive traffic.

In 99% of the scenarios, an in-line firewall is fine; let us examine how to approach the remaining 1%.

Local Internet connection

Requisite #1: We need to use the local Internet connection if available and use the MPLS if not.

Solving this requisite is easy: we must implement a conditional static default route. The firewall is used only if the Internet connection through it is working.

Depending on the firewall model, we can use native features and dynamic routing to accomplish the configuration. However, for the sake of this post, we want to solve the requisite by acting on the L3 switch only.

Network engineers are used to implement an ICMP probe, reaching 8.8.8.8, to test the Internet connection. I read even official documents suggesting that, but that’s a bad practice because Google apply rate limits:

We want to implement two DNS probes using at least two different DNS OpenDNS servers.

ip sla 1
 dns www.cisco.com name-server 208.67.222.222 source-ip 192.168.1.1
 timeout 5000
 frequency 10
ip sla schedule 1 life forever start-time now
ip sla 2
 dns www.google.com name-server 208.67.220.220 source-ip 192.168.1.1
 timeout 5000
 frequency 10
ip sla schedule 2 life forever start-time now
track 1 ip sla 1 reachability
track 2 ip sla 2 reachability

DNS providers can rate limit requests with unusual record types, excessive duplicate queries, excessive DNS records, or those sent from malicious client IPs to add entropy to our nameserver requests. Because we use a 10 s frequency, we can assume that it is safe.

We also need to couple the probes above using the OR logical operator

track 3 list boolean or
 object 1
 object 2
 delay down 12 up 30

To avoid flapping, we introduced a delay before changing the state.

Finally, we configured the default static route associated with the probe.

ip route 0.0.0.0 0.0.0.0 192.168.1.254 track 3

Active and backup Internet path (L3 diagram)

With this configuration, traffic to the Internet is routed through the firewall if the Internet connection via the firewall itself is working. Otherwise, the default route from the MPLS is used.

Attention should be paid to convergence time, especially when the local Internet connection goes down.

Off-path firewall filtering

Requisite #2: We must selectively filter some network conversations. We cannot forward anything to the firewall because it does not have sufficient bandwidth or computational resources.

Solving this requirement requires PBR or Policy-Based Routing. We use PBR when we need to make an exception to the normal routing. We want to select, based on protocol, source/destination IP, and port, network flows to be routed through the firewall. The firewall is configured “on-a-stick,” meaning that a single interface is used to receive and transmit the allowed network traffic.

Off-path firewall with flows (L3 diagram)

We must define the network traffic to be filtered using an ACL.

ip access-list extended FILTERED
 permit ip 192.168.20.0 0.0.0.255 any
 permit ip any 192.168.20.0 0.0.0.255

We must match both ingress and egress traffic. A route map forwards traffic through the firewall.

route-map FILTERED permit 10
 match ip address FILTERED
 set ip next-hop verify-availability 192.168.1.254

In a non-HA firewall configuration, we can implement the conditional PBR:

route-map FILTERED permit 10
 match ip address FILTERED
 set ip next-hop verify-availability 192.168.1.254 1 track 11

Finally, we need to apply the route map to any L3 interface, excluding the interface where the firewall is placed:

interface Ethernet0/1
 ip policy route-map FILTERED
interface Ethernet0/2
 ip policy route-map FILTERED

With this configuration, the ingress traffic matching the ACL is forwarded to the firewall.

Conclusions

Again, this design should not be used unless specific requirements exist. However, this works well. Automation tools should be considered to manage large environments properly. The more human dependent is, the more errors (and outages) will be.

References