Network Security: Firewalls, NAT, and VPN Questions

Sample ACL configuration

ip access-list extended WAN-IN
 remark Allow HTTPS from 10.1.1.0/24 to 172.16.0.0/16
 permit tcp 10.1.1.0 0.0.0.255 172.16.0.0 0.0.255.255 eq 443
 remark Deny Telnet and log
 deny tcp 10.1.1.0 0.0.0.255 172.16.0.0 0.0.255.255 eq 23 log
 remark Permit DNS (UDP and TCP)
 permit udp 10.1.1.0 0.0.0.255 any eq 53
 permit tcp 10.1.1.0 0.0.0.255 any eq 53
 remark Deny everything else and log
 deny ip any any log
!
interface GigabitEthernet0/0
 description WAN-facing interface
 ip access-group WAN-IN in

Order of ACL processing

• ACLs are evaluated top-to-bottom. The first matching ACE (access control entry) is applied and processing stops.
• If no ACE matches, implicit "deny ip any any" at the end would drop the packet. Here we explicitly deny-and-log remaining traffic.

Performance & operational considerations

• Logging on every denied match can be CPU-intensive and flood buffers during attacks or scans. Avoid logging high-frequency matches.
• Use targeted logging (only on critical denies), rate-limit syslog, or sample/aggregate with NetFlow/IPS for analytics.
• Consider using ACL counters (show access-lists) for monitoring instead of verbose logging.
• For stateful needs or complex policies, use a firewall or zone-based firewall rather than large router ACLs.

Answer (brief CLI + explanation)

1. Numbered standard ACL (ACL 10) and apply inbound on Gi0/0:

access-list 10 permit 10.1.1.5
access-list 10 deny any
interface GigabitEthernet0/0
 ip access-group 10 in

2. Named standard ACL alternative:

ip access-list standard TRUSTED_HOSTS
 permit 10.1.1.5
 deny any
interface GigabitEthernet0/0
 ip access-group TRUSTED_HOSTS in

Why this works

• Standard ACLs match source IP only; permit 10.1.1.5 allows that host to send to any destination reachable via Gi0/0. The explicit deny any is optional because implicit deny exists, but shown for clarity.

Limitations of standard ACLs

• Match only on source IP (cannot filter by destination, ports, or protocols).
• Order matters (first match wins).
• Applied close to the source is recommended, but lack of destination filtering can be coarse.
• Can accidentally block management/monitoring traffic if applied on management interface.

Safe testing method (avoid lockout)

• Always test from an out-of-band path (console or serial) or have an alternate management path (out-of-band mgmt VLAN, console server).
• Before applying, verify with show access-list and simulate traffic from a permitted and denied host.
• If you must test in-band, first create the ACL but do not apply it; test with packet capture or with extended ACL on a lab interface. Or apply during maintenance window and keep console access; if locked, remove with console:

no ip access-group 10 in   (on the interface)
no ip access-group TRUSTED_HOSTS in

• Optionally, apply a temporary permit for your admin host before strict rules:

access-list 10 permit <your-admin-ip>

Stateful vs Stateless

• Traditional ACLs on routers/switches are typically stateless: each packet evaluated independently (permit/deny by IP, protocol, ports). This requires explicit return rules for bidirectional flows.
• Cloud security groups (e.g., AWS, Azure NSG variants) are usually stateful: an allowed inbound flow implicitly permits the corresponding outbound response, simplifying rules.

Rule Ordering

• On many routers/switches ACLs are processed top-to-bottom; first match wins—order is critical.
• Cloud security groups often treat rules as unordered sets where all rules are evaluated (no first-match). Some cloud firewalls do use priority-based rules (e.g., Azure NSG priorities).

Scale Considerations

• Hardware ACLs limited by TCAM size and line-rate performance; complex rule sets impact throughput. Managing many ACLs across devices requires automation (Ansible, templates).
• Cloud SGs scale horizontally and are applied at VM/subnet level; large numbers of SGs or rules can hit provider quotas and produce management complexity but not TCAM constraints.

Implications for Hybrid Architectures

• When bridging on-prem and cloud, mismatch in statefulness and ordering can cause asymmetric troubleshooting: e.g., an on-prem stateless ACL blocks return traffic while cloud SG allows it.
• Policy translation needed: explicitly add return rules on devices or rely on cloud stateful behavior; synchronize rule intent across domains.

Troubleshooting Guidance

• Check flow symmetry: capture on both sides to detect where responses are dropped.
• Verify rule order on devices and rule sets on cloud; confirm provider quotas/limits.
• Use connection tracking/state tables, logging, and packet captures; document mapping between on-prem ACLs and cloud SGs to reduce surprises.

Overview / goals
Designing HA for stateful firewalls means preserving connection state (sessions, NAT mappings) across failover so active flows continue with minimal disruption while maintaining security correctness.

Key considerations

• What to sync: per-conn state (5-tuple, TCP seq/ACK windows, timers), NAT translations, ALG/stateful protocol helpers, security policy counters.
• Sync latency & frequency: lower latency reduces lost packets but increases bandwidth and CPU.
• Failure detection: fast heartbeats (VRRP/HSRP for VIP; vendor heartbeats for state) vs false positives.

State/NAT sync methods & examples

• OS/protocol-based: pfsync (OpenBSD/FreeBSD), conntrackd with nf_conntrack (Linux) — transports delta/complete state over a secure channel.
• Vendor solutions: Cisco ASA SSO/NSR, Palo Alto HA session sync, Fortinet FGCP — proprietary, optimized for TCP window/sequence sync.
• Mechanisms: full state replication, incremental deltas, checkpointing, on-demand pull.

Active/passive vs active/active

• Active/passive: simpler, deterministic single-writer state; easier to guarantee consistency; briefly higher failover time but simpler conflict-free state.
• Active/active: better utilization and capacity; requires distributed state synchronization or session affinity; higher complexity (conflict resolution, split-brain concerns), potential for asymmetric routing and policy divergence.

Sticky sessions & load balancing

• Use client-source affinity at load balancer or firewall cluster to keep flows on the same node when active/active.
• Combine with flow hashing and health checks; avoid relying solely on IP NAT translation if client IPs change.

Minimizing session loss

• Use synchronous or low-latency incremental state sync; enable session checkpointing.
• Implement graceful shutdown/connection draining and TCP connection mirroring if available.
• Increase TCP keepalive/timeouts briefly during failover; use ARP/VRRP gratuitous announcements to speed re-route.
• Test failover under load; tune heartbeat and hold-down timers to balance speed vs stability.

Practical recipe

• For Linux-based boxes: nf_conntrack + conntrackd with high-frequency, encrypted sync channel; use VRRP for VIP.
• For enterprise: use vendor HA (ASA SSO, Palo Alto HA) in active/passive for simplest correctness; consider active/active only with proven session-distribution and stickiness.
• Monitor sync health, bandwidth, and session loss metrics; automate failback and post-failover reconciliation.

This approach balances reliability, performance, and operational complexity for network-grade stateful firewall HA.

Configuration (commands to enter in global config):

interface GigabitEthernet0/1
 description WAN - public IP
 ip address 198.51.100.2 255.255.255.0
 ip nat outside
!
interface GigabitEthernet0/0
 description LAN - inside
 ip address 192.168.10.1 255.255.255.0
 ip nat inside
!
access-list 10 permit 192.168.10.0 0.0.0.255
ip nat inside source list 10 interface GigabitEthernet0/1 overload

• The ACL matches the inside local network. The last command configures NAT overload (PAT) using the interface IP 198.51.100.2.

Interface directionality

• ip nat inside: applied to interfaces on the private/LAN side.
• ip nat outside: applied to the interface facing the public/Internet side.

Static NAT vs PAT/Overload

• Static NAT: 1:1 mapping (ip nat inside source static <local> <public>) — preserves a fixed public IP for an internal host; required for inbound reachability.
• PAT/Overload: many-to-one mapping using ports; multiple internal hosts share one public IP with different source ports — ideal for outbound Internet access.

Verification commands and what they show

• show ip nat translations
  • Lists active NAT translations (inside local/inside global and protocol/ports).
• show ip nat statistics
  • Shows NAT engine counters, overload pool info, and translation counts.
• show running-config | section ip nat
  • Confirms NAT config (ACL, pool/interface, overload).
• show access-lists 10
  • Verifies ACL matches the intended inside subnet.
• debug ip nat
  • Real-time NAT translation events (use carefully in production).

Use these to confirm translations, troubleshoot port exhaustion, and validate ACL matching.