Application-aware enterprise firewall (zone-based)

Guests next to the corporate LAN

BR-02 has a corporate LAN in VPN 10 (10.10.2.0/24 in this example) and a guest network in VPN 30 (10.30.1.0/24). Both reach the internet through the same router. The routing is already separate. What is missing is a statement of what each side may do: guests may browse, corporate users may browse and reach the data centre, and nothing from the internet should start a connection into either. A firewall policy writes that down and enforces it. The VPN numbers and prefixes are examples from the lab, and the same ideas apply with any numbering.

Zones and zone pairs

A security zone is a named group of one or more service VPNs. A VPN can be in one zone. A zone pair joins a source zone to a destination zone and carries the rules for that one direction. GUEST to INTERNET is one zone pair, and INTERNET to GUEST is a different one.

• Traffic between VPNs inside one zone is normally allowed without a rule.
• Traffic between different zones is denied unless a zone pair has a rule that allows it.
• With no zone pair for a direction, the traffic in that direction is dropped. Check your release for the exact treatment, particularly for VPNs that you did not put in any zone.

The deny between zones is the point. It means a forgotten rule fails safe, and it also means a missing return-direction pair is the first thing to look for when a pass rule seems to break an application.

The policy as a table

The Manager builds this with lists and a policy editor, and the CLI it produces is long. The structure is easier to see as a table. This is an outline for the BR-02 example, not exact configuration.

Every rule has the same parts: what to match (source and destination addresses, protocols and ports, applications or application families), what to do, and whether to log. A zone pair also has a default action for traffic that matches none of its rules. Rules are read from the top and the first match wins, so a broad rule placed above a narrow one hides it.

Inspect, pass and drop

Inspect is usually the right choice because it needs one rule instead of two and it refuses replies that no session started. Pass is the exception, and its common fault is a rule in one direction with nothing in the other. The application works in one direction only, which looks like an application fault.

Matching on applications

An application rule can say, for example, drop a given streaming application from GUEST. The router can do this because of its application recognition engine, which classifies flows by looking at the first packets and at details such as the name in an HTTPS handshake. Two limits follow.

• Classification takes a few packets. Until it finishes, a flow has no application and matches only rules based on addresses and ports, or the default action.
• Some traffic is hard to classify, especially when it is encrypted and its server name is hidden. A flow that stays unidentified is handled by the later rules or the default.

Put address and port rules where precision matters, and use application rules for the policy you want to express in business terms. Test with real applications before relying on one.

The router itself and the underlay

Traffic sent to or from the router, such as management sessions, is not ordinary transit traffic. Cisco SD-WAN has a special self zone for the router itself, and the transport side (VPN 0, the global or underlay side) has its own treatment. Whether a zone pair is needed to reach the router, how the default applies, and which interfaces count as which zone differ between releases. Read your release's firewall guide on these two points before you protect a management interface with this feature, and test from both sides.

Checking the counters

BR-02#show sdwan zbfw zonepair-statistics
ZONE PAIR            SRC ZONE  DST ZONE  RULE/CLASS     ACTION   PACKETS  BYTES
GUEST-TO-INTERNET    GUEST     INTERNET  WEB            inspect  48210    39120344
GUEST-TO-INTERNET    GUEST     INTERNET  class-default  drop     133      9210
CORP-TO-INTERNET     CORP      INTERNET  class-default  inspect  120934   98211876
GUEST-TO-CORP        GUEST     CORP      class-default  drop     57       3420

BR-02#show sdwan zbfw drop-statistics
REASON                          PACKETS
no zone-pair                    12
policy drop (class-default)     190
return traffic without session  4

Where the firewall misbehaves

• One-way pass rule. The request leaves and the reply is dropped for want of a return pair. Use inspect, or add the return rule.
• VPN in no zone. The rules do not apply to it, or it is treated differently from a zoned VPN. Confirm every service VPN you care about is in a zone.
• Rule order. A broad inspect above a block rule means the block is not reached. Read the rules from the top.
• Application not yet identified. The first packets did not match the application rule. A rule that depends on an application also needs a sensible default for unclassified traffic.
• Policy not attached. The policy exists in the Manager but is not part of the device template, so the counters stay empty.

The next layer up, IPS, usually runs because a firewall rule passes traffic to it.

Test yourself on the firewall