#!/bin/bash

iptables -F
iptables -t nat -F
iptables -X
iptables -t nat -X

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth1 -p tcp -s 192.168.167.0/24 --dport 22 \
-m state --state NEW -j ACCEPT
iptables -A INPUT -i eth1 -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT


iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -o eth1 -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT

iptables -t nat -A PREROUTING -i eth0 -p tcp -d 133.172.114.17 --dport 25 \
-j DNAT --to-destination 192.168.167.23:25
iptables -t nat -A POSTROUTING -o eth0 -p tcp -s 192.168.167.0/24 \
-j SNAT --to-source 133.172.114.17

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -A FORWARD -i eth1 -p tcp -s 192.168.167.0/24 --dport 80 \
-m state --state NEW -j ACCEPT
iptables -A FORWARD -i eth1 -p tcp -s 192.168.167.0/24 --dport 443 \
-m state --state NEW -j ACCEPT
iptables -A FORWARD -i eth0 -p tcp -d 192.168.167.23 --dport 25 \
-m state --state NEW -j ACCEPT
iptables -A FORWARD -p tcp -m state --state RELATED,ESTABLISHED -j ACCEPT

With this firewall script, I'm needing to answer this question:
For the following four groups of iptables commands, explain:
• the overall effect of each group of commands, and
• the purpose of each command within the group.

  1. lines 12 and 18,
  2. lines 13 and 19.
  3. lines 21, 32 and 34.
  4. lines 23, 28, 30 and 34.

Dani AI

Generated

Quick orientation for (and a nod to ): the script sets a deny-everything-by-default posture and then opens a small, explicit set of exceptions. Below are concise, exam-ready explanations of each requested group (overall effect first, then what each command in the group does).

  • Lines 12 & 18 — loopback allowance (overall effect): keeps all localhost communication working despite the global DROP policies.

    • Line 12: permits any packet coming into the host via the loopback interface so local services can talk to each other.
    • Line 18: permits packets leaving the host on loopback. Without both directions allowed, many local daemons and socket-based IPC break.
  • Lines 13 & 19 — SSH from the LAN (overall effect): lets LAN clients initiate SSH to the gateway and allows the gateway to send the replies.

    • Line 13: allows new TCP connections to the host’s SSH port, but only when arriving on the LAN interface and from the LAN address range (limits exposure).
    • Line 19: allows outgoing packets that belong to already-established or related connections on the LAN interface so SSH sessions can function while OUTPUT policy is DROP.
  • Lines 21, 32 & 34 — inbound SMTP DNAT + forwarding (overall effect): expose an internal mail server on the gateway’s public IP and allow the connection to be forwarded.

    • Line 21: rewrites incoming packets addressed to the gateway’s public SMTP port so they target the internal mail host (DNAT / destination NAT).
    • Line 32: permits forwarding of the initial (NEW) TCP connection from the outside interface to the internal mail server.
    • Line 34: permits the return traffic and any related flows by allowing RELATED,ESTABLISHED packets through the FORWARD chain.
  • Lines 23, 28, 30 & 34 — LAN web browsing + SNAT (overall effect): allow LAN clients to reach HTTP/HTTPS on the Internet and make their traffic routable by translating sources to the gateway’s public IP.

    • Line 23: rewrites outbound packets from the LAN so they appear from the gateway public address (SNAT / source NAT).
    • Lines 28 & 30: allow LAN hosts to start new TCP connections to remote port 80 and 443 via the FORWARD chain.
    • Line 34 (shared): lets the return packets for those connections pass.

Practical notes: enabling forwarding in the kernel (echo to /proc or persistent sysctl) is required for NAT to work. Because OUTPUT is DROP, add explicit OUTPUT accepts if the gateway itself must make new outbound connections (DNS, NTP, updates). To load rules early in boot use your distro’s persistent/boot hooks (iptables-restore or network pre-up hooks) — behaviour is distro-dependent. For debugging inspect rule counters and conntrack state (packet counts show whether rules are hit).

Recommended Answers

All 3 Replies

Topic question doesn't appear to match your question in the text that follows. Also, we state what we want the firewall to do then write the rules but you seem to have put the cart before the horse.

That is, you have the rules before you determined why you have these rules. Let's start over. What did you need iptables to do here?

I'm needing the iptables to run on the gateway machine before the gateway's interfaces are brought up

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.