How to Validate an Enterprise Networking Fundamentals Task in TCP/IP

Enterprise networks rely on TCP/IP to move data reliably between hosts that may be separated by routers, firewalls and administrative boundaries. Underneath every file transfer, web request or backup

job sits a stack of addressing, routing and transport decisions that determine whether traffic arrives, is blocked, or silently disappears. Understanding how these layers cooperate, and where trust boundaries such as routing tables and firewall policies sit, is the difference between guessing at a connectivity problem and diagnosing it with evidence.

This guide teaches you to design, apply and safely validate one bounded enterprise networking change: enabling TCP connectivity between two isolated subnets that are currently unreachable from one another, proving the change worked with direct evidence, and then rolling it back cleanly. You will work only in an isolated lab, using read-only diagnostic commands to gather evidence and clearly scoped state-changing commands to apply and reverse the change. By the end, you will be able to reason about routing, firewall filtering and the TCP three-way handshake well enough to validate similar changes safely in a real environment.

#Learning Objectives

• Explain how IP addressing, routing and TCP transport cooperate to deliver data between hosts on different subnets.
• Identify the trust boundaries, including the routing table and firewall chain, that a connectivity change must cross.
• Apply a bounded routing and firewall change in an isolated lab and gather direct evidence that it succeeded.
• Distinguish ICMP reachability from TCP port reachability and explain why each proves something different.
• Roll back the change safely and confirm the environment has returned to its documented baseline.

#Prerequisites

• Use an isolated or non-production validation environment with at least two hosts on separate subnets and one Layer 3 device between them.
• Confirm the operating system version, available networking utilities (ip, iptables or nftables, ping, nc, tcpdump) and your permission level before applying any change.
• Basic familiarity with IPv4 addressing and subnet notation, for example recognising that 10.0.1.0/24 and 10.0.2.0/24 are distinct address ranges.
• Administrative access on the lab hosts, used only inside the isolated environment.

#Content

#

The mental model: addressing, routing and transport

IP is responsible for addressing hosts and choosing a path between them across routers. It does not guarantee delivery or ordering on its own. TCP sits above IP and adds reliability: it establishes a connection through a three-way handshake (SYN, SYN-ACK, ACK), tracks sequence numbers, and retransmits lost segments. A port number identifies which application on the destination host should receive the data. When a connectivity task fails, the fault usually sits at one of three points: the route between subnets, a firewall or access control list evaluating the traffic, or the destination application not listening on the expected port.

#

Terminology

A subnet is a contiguous block of IP addresses treated as one network segment. A routing table is the set of rules a host or router uses to decide which interface and next hop to send a packet through. A default gateway is the route used when no more specific entry matches. A firewall chain, such as iptables’ FORWARD chain, evaluates traffic that a device is routing on behalf of other hosts, separately from traffic destined for the device itself. A socket is the combination of IP address and port that identifies one end of a TCP connection.

#

Components, dependencies and trust boundaries

In this workflow, three components must agree before traffic flows: the router’s routing table must contain a path to the destination subnet; the router’s firewall must permit the specific traffic to be forwarded; and the destination host must have an application listening on the target port. Each of these is a trust boundary. The routing table determines where traffic is allowed to go at all. The firewall chain determines whether traffic that could go there is actually permitted. Changing either without evidence of the other’s state risks either an ineffective change or, worse, a wider opening than intended. This is why the exercise below scopes the firewall rule to one protocol, one port and one subnet pair rather than a blanket permit.

#Examples

#

Worked example: diagnosing baseline unreachability

Input: ping -c 4 10.0.2.20 run from Host A (10.0.1.10) before any change is made.

Output: 4 packets transmitted, 4 received, 100% packet loss.

Interpretation: Total packet loss tells you the destination is currently unreachable, but not why. It could be a missing route, a firewall drop, or the destination host being offline. This single result is not enough evidence to diagnose the cause; it only establishes the baseline you will compare against after the change.

Input: after adding the route and firewall rule described in the exercise, nc -vz 10.0.2.20 8080 run from Host A.

Output: Connection to 10.0.2.20 8080 port [tcp/*] succeeded!.

Interpretation: This confirms TCP-layer reachability on the specific port, which is a stronger claim than ICMP reachability alone. It shows the route, the firewall rule and a listening application are all correctly aligned for this one port.

#Exercises

#

Exercise: enable and validate a scoped TCP path between two subnets

Objective: enable TCP connectivity from Host A (10.0.1.10) to Host B (10.0.2.20) on port 8080 only, gather direct evidence of success, then roll back to the original state.

Setup: confirm the lab topology has Host A and Host B on separate subnets with a Linux

router between them acting as the default gateway for both. On Host B, start a temporary listener with nc -l 8080 before testing.

Steps: capture the baseline with the ping command above, then apply the route and firewall commands listed in the technical reference for this guide, in that order, confirming each with a read-only check before moving to the next.

Expected evidence: ip route show lists the new subnet route; iptables -L --line-numbers shows exactly one ACCEPT rule scoped to tcp/8080 between the two subnets; nc -vz reports success; a concurrent tcpdump capture shows the SYN, SYN-ACK and ACK sequence.

Pass condition: all four pieces of evidence above are present and the handshake in the capture is complete and correctly ordered.

Stop condition: if the packet capture shows traffic to or from addresses outside the two lab subnets, or if the firewall rule appears more than once or in the wrong chain, stop immediately and investigate before continuing; do not layer further changes on top of an unclear state.

Cleanup: apply the rollback commands, stop the listener on Host B, and re-run the baseline ping and nc tests to confirm the environment matches its pre-exercise state.

#Validation Guidance

Validation in this workflow means comparing observed evidence against an explicit expectation at each step, not simply confirming that a command ran without an error message. ICMP success and TCP success prove different things and should never be treated as interchangeable. Firewall rule presence should always be checked with the rule listing itself, not inferred from a successful test alone, because an unrelated earlier rule in the same chain can produce a misleading result. The packet capture is the strongest evidence available here because it shows the actual handshake rather than an application-level summary.

#Common Mistakes

• Treating a successful ping as proof that a TCP service is reachable, when only the network layer has been confirmed.
• Adding a firewall rule to the wrong chain, for example INPUT instead of FORWARD, when the device is routing traffic on behalf of other hosts.
• Not checking for a return route on the destination side, leading to asymmetric routing where requests arrive but responses cannot get back.
• Leaving a firewall rule scoped more broadly than the task requires, rather than matching the exact protocol, port and subnet pair needed.
• Assuming a working test result will persist after a reboot, when the route or rule was never written to a boot-time configuration.

#Warnings

The commands in this guide change how traffic is routed and filtered. Apply them only in an isolated lab, and keep the scope as narrow as the task allows.

#Production Bridge

Repeating this workflow against production infrastructure requires more than technical correctness. Routing and firewall changes on shared infrastructure typically require a documented change request, approval from whoever owns that network segment, and a defined maintenance window if other services share the same router or firewall. Scope any production rule to the specific hosts, ports and direction required, never to whole subnets by default, and confirm who has permission to modify the routing table or firewall chain before you touch either. If a test in production produces evidence you did not expect, such as traffic outside the intended subnets or a rule appearing in an unexpected position, stop and escalate to the team that owns the network boundary rather than attempting a wider fix yourself.

#Key Takeaways

• A connectivity task in TCP/IP typically depends on three things being simultaneously correct: the route, the firewall rule and a listening application.
• ICMP and TCP reachability are different claims and require separate evidence.
• Scoping a firewall rule narrowly is both a safety practice and a diagnostic aid, since a narrow rule is easier to verify and easier to remove cleanly.
• A packet capture of the handshake is stronger evidence than an application-level success message alone.
• Every lab change in this guide has a matching rollback command, and the environment should be returned to its documented baseline before you consider the exercise complete.

Before repeating this workflow against production infrastructure, treat every finding here as provisional until it is confirmed against your organisation’s current routing and firewall change records: rerun the read-only validation steps against the live environment, obtain explicit sign-off for the specific ports and subnets involved, and keep the rollback commands ready as your immediate recovery path if the change produces unexpected forwarding behaviour.