Skip to main content

Validate ACL behavior using Invariant

ACLs sometimes don't behave as expected. Common issues include partially or fully shadowed lines, typos, and subtle misunderstandings of ACL commands. Use Invariant to confirm that ACL behavior matches your expectations.

Scenario: The firewall asa.cfg has access list internal-to-external applied inbound on its interfaces facing internal networks. It should permit SSH from VLAN10 (192.168.10.0/24) and deny SSH from all other VLANS.

configs/asa.cfg
interface GigabitEthernet0/1
 nameif INSIDE1
 ...
access-list internal-to-external remark allow-ssh-from-eng
access-list internal-to-external extended permit tcp 192.168.10.0 255.255.255.0 any eq ssh

access-list internal-to-external remark deny-internal
access-list internal-to-external extended deny tcp any 10.0.0.0 255.0.0.0
access-list internal-to-external extended deny udp any 10.0.0.0 255.0.0.0
! ... other deny rules ...

access-group internal-to-external in interface INSIDE1

Verification: Let's verify that ACL internal-to-external actually has these behaviors:

  • Permits SSH from VLAN10 (192.168.10.0/24)
  • Denies SSH from all other VLANs (192.168.0.0/16)
invariant/policies/asa_validation.yaml
access-policy:
  - name: asa-ssh-validation-VLAN10
    comment: Confirm VLAN10 SSH access
    owner: security-team@example.com
    egress-network: VLAN10
    rules:
      - type: egress-critical-flow
        comment: Ensure VLAN10 can SSH into the datacenter via ASA
        destination-address: DATACENTER
        destination-port: SSH # Built-in service name
        protocol: tcp
  - name: asa-ssh-validation-VLANS
    comment: Validate ACLs protecting the datacenter
    owner: security-team@example.com
    egress-network:
      source-address: VLANS
      source-exclude: VLAN10 # Select all VLANS excluding VLAN10
    rules:
      - type: egress-deny
        comment: Ensure other VLANS cannot SSH anywhere
        destination-port: SSH # Built-in service name
        protocol: tcp

Run Analysis: Execute Invariant on your snapshot directory.

$ invariant run --target /path/to/your/snapshot/ --condensed
snapshot: cf2bb04f-554f-4a84-a3e0-bf12a13c0e4e
outcome: All rules passed

# Passing rules are listed in policy_ok
$ invariant show policy_ok --json

# A log of reachability checks performed appears in policy_logs
$ invariant show policy_logs --json

# Violations, if present, would appear in policy_violations
$ invariant show policy_violations --json

# Traceroutes demonstrating segmentation violations, if found, appear in policy_details
$ invariant show policy_details --json

Similarly, details for the critical flow rule can be found in critical_flows_ok , etc.

See Access Policy for more details on rule types and reports.

See Output Overview for access policy output file reference.