LPIC-2 System Security: Packet Filtering, Routing, and VPNs

By default a Linux machine is a host: it accepts packets addressed to itself and drops anything addressed to someone else. A router does the opposite — it accepts a packet on one interface and passes it out another toward its destination.

Think of a host as a private mailbox that only takes mail with your name on it. A router is the post office sorting room: a letter arrives, the clerk reads the destination, and forwards it on. A stock Linux kernel refuses to be that sorting room until you explicitly turn the behaviour on.

That switch is the kernel parameter net.ipv4.ip_forward. It is 0 (off) on every fresh install — a security default, because an accidental router can bridge networks you never meant to connect.

There are two states to set, and they are independent — exactly like active vs enabled for a service:

• the runtime value in /proc/sys (lost at reboot)
• the persistent value in a config file under /etc/sysctl.d/ (re-applied at every boot)

Start by reading the current value so you have a baseline.

To make it permanent, drop a .conf file into /etc/sysctl.d/. The kernel applies every file in that directory at boot, so your setting is reapplied automatically.

A Linux firewall is a set of rules the kernel checks each packet against, deciding accept or drop. Two front-ends exist for the same kernel machinery:

• nftables — the modern tool. One command, nft, one config file, /etc/nftables.conf. Rules live in named tables and chains with hooks (input, output, forward).
• iptables — the legacy tool. Built-in chains named in capitals: INPUT (packets for this host), OUTPUT (packets from this host), FORWARD (packets passing through, i.e. routed). Saved with iptables-save.

Think of a chain as a bouncer's checklist: rules are read top to bottom, the first match decides, and if nothing matches the chain's default policy applies.

A secure firewall uses a default-drop policy: deny everything, then allow only what you intend. But order matters, because rules apply the instant you commit them.

Two allows must come before you set the policy to drop:

1. loopback (iif lo) — countless local services talk to themselves over 127.0.0.1; drop it and they break in confusing ways.

2. established,related — your SSH session is an already-established connection. The kernel's connection tracking (ct state / conntrack) remembers it. Allowing established,related lets reply packets for connections you already opened flow back.

NAT (Network Address Translation) rewrites the addresses in packets as they pass through your router. Two directions, two jobs:

• Outbound — MASQUERADE / SNAT. Many internal machines on private IPs share one public address. The router rewrites their source address to its own on the way out, and untangles the replies on the way back. Think of an office switchboard: dozens of internal extensions, one public phone number to the world. Use MASQUERADE when the public IP is dynamic (DHCP/dial-up); use SNAT when it is static (slightly faster, you name the fixed IP).
• Inbound — DNAT. The reverse: a packet hits the router's public IP on a port, and DNAT rewrites the destination to an internal host — port forwarding. Like the receptionist routing an incoming call to extension 204.

A VPN builds an encrypted tunnel across the untrusted internet so two networks (or a roaming user and a network) behave as if directly wired together. It is not separate from what you just learned — it depends on it: the tunnel carries traffic the box must forward, so VPNs need ip_forward=1 and FORWARD rules just like any router. Two families dominate LPIC-2:

• OpenVPN — a userspace daemon built on TLS/PKI. Each peer holds a certificate signed by your CA; the server runs on a single UDP port (1194 by convention). Because it's one well-defined port, the firewall rule is simple. Think of it as HTTPS for your whole network: the same certificate trust model, applied to a tunnel.
• IPsec (strongSwan) — a kernel-level standard, the usual choice for site-to-site. It works in two phases: IKE (the UDP 500 / 4500 negotiation that authenticates the peers and agrees on keys), then ESP (the protocol that actually encrypts and carries the data). Think IKE as the handshake at the border, ESP as the armoured truck that then runs back and forth.

You have a real root shell. These commands only read state — none of them set a drop policy or apply a rule, so you can run them freely without risking a lockout. They're the exact first moves when you inherit an unfamiliar Linux router and need to understand it.