Software and versions used
This explanation applies to:
- Concepts: Packet filtering, connection tracking, stateful inspection
- Linux: Netfilter framework (Debian, Arch Linux)
- OpenBSD: Packet Filter (pf)
- Context: Distribution-independent firewall fundamentals
Packet filtering operates at the kernel level
Every network packet passes through filtering decisions before it reaches applications. The kernel checks the source IP, destination port, protocol type, and connection state against defined rules. Allowed packets are forwarded to the corresponding application—blocked packets are discarded or answered with error messages.
Article 1 explains IP addresses and ports as networking fundamentals. Firewall systems extend these concepts with access control: A web server on port 80 accepts only HTTP requests that pass the firewall rules. Without firewall protection, every network participant can reach every open port.
Operating systems use different firewall architectures while following the same fundamental principles. Linux uses the Netfilter framework in the kernel—tools such as iptables, ufw, and nftables are different user interfaces for the same Netfilter infrastructure. OpenBSD implements Packet Filter (pf) with a different architecture but the same filtering goals.
Two fundamentally different firewall philosophies
Linux Netfilter follows a chain-based architecture. Packets pass through defined hooks in a fixed order: PREROUTING, INPUT, FORWARD, OUTPUT, POSTROUTING. Each hook can accept, drop, or forward packets to subsequent hooks. Rules are organized into chains—the first matching rule determines the packet’s fate.
OpenBSD pf uses a declarative configuration. All rules reside in a single configuration file and are evaluated in one pass. pf rules define the action, direction, interface, and matching criteria using consistent syntax. The last matching rule wins—later rules can override previous ones.
Chain ordering and hook priorities frustrate many iptables newcomers—pf eliminates this confusion through consistent rule processing. Both approaches achieve identical security goals through different configuration methods.
Connection tracking enables stateful packet filtering
Modern firewall systems track connection states instead of looking only at individual packets. Connection tracking stores information about established TCP connections, UDP streams, and ICMP sessions in kernel memory. Connection tracking information enables intelligent filtering based on the connection context.
An outgoing HTTP connection to a web server creates a connection tracking entry with the state NEW. Response packets from the web server receive the state ESTABLISHED and are automatically allowed without explicit inbound rules. Stateful filtering greatly simplifies firewall configurations.
Connection tracking manages timeout-based state transitions. TCP connections move through the states NEW → ESTABLISHED → FIN_WAIT → CLOSE. UDP traffic without explicit connection semantics uses timeout-based pseudo-connections. ICMP ping requests and replies are managed as related connection tracking entries.
Connection tracking tables have size limits—full tables block new connections even when bandwidth is still available. Each connection tracking entry occupies kernel memory for the source and destination IP addresses, ports, protocol, and current state.
Docker automatically manipulates firewall rules
Docker containers require network connectivity for service communication and Internet access. Docker manipulates firewall rules directly when containers start without coordinating with user-configured firewalls. Docker rules completely bypass UFW configurations and can introduce security vulnerabilities.
Automatically generated container rules are created during port mapping and network creation. Docker creates NAT rules for port forwarding and bridge rules for inter-container communication. UFW-Docker integration requires an understanding of both systems to produce a working configuration.
Container networks use separate IP ranges with their own firewall chains. Docker-generated rules often have a higher priority than manually configured rules. Effective security requires user-defined rules to take the Docker networking architecture into account.
Packet filtering based on different criteria
IP address-based filtering blocks or allows traffic from specific source or destination addresses. Geographic filtering reduces the attack surface by restricting access to relevant countries or regions. Whitelist approaches allow only known, trusted IP ranges.
Port-based filtering controls access to specific services. Well-known ports (0-1023) identify standard services: port 22 for SSH, port 80 for HTTP, and port 443 for HTTPS. Port ranges allow filtering entire categories of services without defining every individual port.
Protocol-based filtering distinguishes between TCP, UDP, ICMP, and other protocol types. TCP connections require connection tracking for bidirectional traffic. UDP packets have no connection semantics—each packet is filtered individually.
Interface-based filtering handles traffic from different network interfaces differently. External interfaces (Internet connections) receive more restrictive rules than internal interfaces (LAN connections). The loopback interface (localhost) is usually excluded from filtering entirely.
NAT and port forwarding for service exposure
Network Address Translation solves the problem of limited public IP addresses by allowing multiple systems to share a single Internet address. Source NAT replaces the private source IP addresses of outgoing packets with the router’s public IP address. Destination NAT forwards incoming connections from public ports to internal services.
NAT implementations use state tables to perform correct reverse translation. Routers keep track of outgoing connections and translate incoming response packets back to the original internal IP addresses. NAT tables have size limitations similar to connection tracking tables.
Port Address Translation extends NAT by translating ports when port conflicts occur. Two internal hosts using identical source ports receive different external ports. NAT routers maintain mapping tables for the correct reverse translation between internal and external port numbers.
Default policies and defense-in-depth strategies
A default-deny policy blocks all traffic that is not explicitly allowed. Firewall rules define specific exceptions for required services. A default-allow policy permits all traffic except explicitly blocked packets. Default-deny provides stronger security through a restrictive default posture.
Defense in depth implements layered security across multiple levels. A network firewall filters external traffic, host-based firewalls protect individual servers, and application firewalls control service-specific access. Multiple security layers reduce the risk of failure if a single protective measure is compromised.
Service isolation limits inter-service communication to required connections. Database servers accept connections only from application servers, not directly from external clients. Web servers may be publicly accessible while backend services allow only internal access.
Logging and monitoring for security analysis
Firewall logs record blocked and allowed connections for security analysis. Log entries contain timestamps, source and destination IP addresses, ports, protocols, and actions. Structured logs enable automated analysis and anomaly detection.
Rate limiting restricts log entries to defined amounts within a given period. Without rate limiting, large-scale attacks generate millions of log entries and can impact storage or performance. Log rotation archives older entries and limits the size of active log files.
Selective logging records only security-relevant events without reducing performance. Routine traffic is ignored, while suspicious activity is logged in detail. Fail2ban automatically analyzes logs and blocks IP addresses after repeated attack attempts.
Performance optimizations for high throughput
Connection tracking tables consume kernel memory in proportion to the number of simultaneous connections. Web servers with thousands of concurrent visitors require appropriately sized tracking tables. Tables that are too small block legitimate connections, while oversized tables waste RAM.
Network interface queues can overflow under high packet throughput and drop packets before they reach the firewall rules. Queue sizes must be adjusted to the expected traffic volume. Multi-queue network adapters distribute packet processing across multiple CPU cores.
Hardware acceleration for cryptography and packet processing reduces CPU usage for encrypted traffic. Network interface cards with integrated firewall functionality process simple filtering rules without CPU involvement.
Backup and disaster recovery for firewall configurations
By default, firewall rules exist only in memory and are lost after a system reboot unless persistence mechanisms are used. Linux distributions use different approaches: systemd services, init scripts, or distribution-specific tools to load rules automatically during boot.
Configuration files enable version control and systematic change tracking. Git-based firewall management documents configuration changes with timestamps, authors, and change descriptions. Rollback mechanisms restore previous configurations when problems occur.
Rule export and import work through standardized formats or tool-specific syntax. Complete firewall snapshots contain all rules, chains, and counter values. Automated backups before configuration changes prevent data loss caused by misconfigurations.
Integration with self-hosted services
Self-hosting requires a precise balance between service accessibility and security. Typical setups expose only the necessary ports publicly and restrict administrative access to trusted sources. Web services remain publicly accessible, while database access is limited to local networks.
Reverse proxy setups require firewall rules for backend communication between the proxy and services. Localhost-specific rules implement service isolation: the reverse proxy can reach backend services, while external clients can contact only the proxy. Service isolation significantly reduces the attack surface.
Container-based services use separate network namespaces with their own firewall contexts. The host firewall and the container firewall operate at different network layers. Docker bridge networks require specific rule configurations for secure inter-container communication.
Perform troubleshooting systematically
Firewall problems appear as unreachable services despite correct configurations or blocked connections without an obvious cause. Systematic debugging traces packets through the entire network stack and identifies the exact point where they are blocked.
Packet tracing records the complete path of packets through all filtering hooks and rule chains. Every packet is documented together with every evaluated rule and matching result. Trace output shows every rule match and identifies exactly where packets are dropped.
Connection tracking inconsistencies cause seemingly unexplained connection problems. Stale entries in orphaned states block new connections using the same source and destination combination. Connection tracking table analysis shows state transitions and identifies problematic entries.
Packet captures on different network interfaces compare traffic before and after firewall processing. Packets that arrive on external interfaces but never appear on internal interfaces were dropped by firewall rules. Cross-interface traffic analysis pinpoints filtering problems precisely.
Next steps:
- Understand Reverse Proxy Fundamentals →
- Debian firewall with UFW (planned)
- OpenBSD firewall with pf (planned)
