Testing VPC Connectivity

Debug and prove your VPC works by testing SSH, ping, and internet access.

Introduction

30 Second Summary

You have built a network with subnets, security layers, and routing rules. Until you send real data and watch what happens, your setup is just theory.

In this project, you will test your VPC by sending three types of traffic through it. You will SSH into your Public Server, ping between your servers, and fetch web pages from the internet.

What You'll Build

Picture typing ping into a server terminal and watching reply packets stream back from another server in a completely different subnet.

By the end of this project, you'll have:

  • A working SSH connection to your Public Server through EC2 Instance Connect, debugged from a failed first attempt.
  • Verified two-way ICMP communication (ping) between your Public and Private Servers, after fixing both NACL and security group blocks.
  • Confirmed internet access from your Public Server using curl, proving the full VPC traffic path works end-to-end.
  • Secret Mission: Explore NACL rule ordering by adding a DENY rule that overrides your existing ALLOW rule.

Are there any prerequisites?

This project is Part 5 of the NextWork AWS VPC series. You need all resources from Parts 1-4 still running in your AWS account, including your NextWork VPC, subnets, EC2 instances, security groups, and NACLs.

Before We Start

You have built a full VPC with subnets, servers, security groups, and NACLs. Before you start running tests, let's lock in exactly what you are about to prove and why connectivity testing matters.

Verify Your Existing VPC Resources

Your VPC resources from Part 4 should still be running in your AWS account. Before you start testing connectivity, you need to confirm everything is in the right state.

A missing subnet or stopped instance would cause confusing failures in later steps. This step is a quick health check of your full VPC architecture.

In this step, get ready to:
  • Confirm your VPC, subnets, route tables, and internet gateway are all present in the VPC console.
  • Verify both EC2 instances are in the Running state.
  • Confirm your Public Server has a public IPv4 address assigned.
Confirm your VPC architecture in the Resource map
  • Sign in to the AWS Management Console.
  • In the search bar at the top, type VPC and select VPC from the results.
  • In the left navigation pane, select Your VPCs.
  • Select NextWork VPC from the list.
  • Select the Resource map tab.

You should see your full VPC architecture: the public subnet, private subnet, route tables, and internet gateway all connected to NextWork VPC.

What does the Resource map show?

The Resource map is a visual diagram of everything inside your VPC. It shows how subnets, route tables, internet gateways, NACLs, and security groups are connected.

If any component is missing from this view, it means a previous step did not complete correctly. You would need to recreate the missing resource before continuing.

Verify both EC2 instances are running

Your two EC2 instances need to be in a Running state for the connectivity tests ahead. A stopped instance cannot send or receive traffic.

  • In the search bar at the top, type EC2 and select EC2 from the results.
  • In the left navigation pane, select Instances.
  • Check that both NextWork Public Server and NextWork Private Server show Running in the Instance state column.

Both instances should display a green circle with the word Running next to them.

Is one of your instances stopped?

If either instance shows Stopped instead of Running, you need to start it back up.

  • Select the stopped instance by clicking its checkbox.
  • Select Instance state in the top menu bar.
  • Select Start instance.
  • Wait for the instance state to change to Running before continuing.

If you don't see either instance at all, you may need to go back to Part 4 and recreate it. Help me find my missing EC2 instance.

Verify the Public Server has a public IPv4 address

EC2 Instance Connect provides browser-based SSH access through the AWS Console. It requires the instance to have a public IPv4 address to establish the connection.

  • Select NextWork Public Server from the instance list.
  • Select the Networking tab in the details panel below.
  • Confirm that a Public IPv4 address is listed in the networking details.

You should see an IP address displayed next to Public IPv4 address. This confirms your Public Server is reachable from outside the VPC.

Why does the Public Server need a public IP?

EC2 Instance Connect uses SSH to open a terminal session to your instance from the browser. For this to work, the instance needs a public IPv4 address so the AWS Console can reach it over the internet.

Your Private Server does not have a public IP. That is by design. You will reach it indirectly by connecting to the Public Server first, then communicating across subnets from there.

No public IPv4 address listed?

If no public IPv4 address appears, the public subnet may not be configured to auto-assign public IPs. Check that the subnet's Auto-assign public IPv4 address setting is enabled in the VPC console under Subnets.

If you update this setting, you may need to stop and start the instance for it to pick up a new public IP. Help me fix my missing public IPv4 address.

Your VPC architecture is verified and both servers are running. Next up, you will connect to your Public Server via SSH and hit your first connectivity challenge.

Connect to Your Public Server

Your VPC resources are confirmed and both servers are running. To run connectivity tests from inside your VPC, you first need a way to get a terminal session on your Public Server.

EC2 Instance Connect lets you open a browser-based SSH session to your instance directly from the AWS Console. In this step, you'll use it to connect to NextWork Public Server.

In this step, get ready to:
  • Attempt to connect to your Public Server via EC2 Instance Connect.
  • Diagnose and fix a security group issue blocking your connection.
  • Establish a working terminal session on your Public Server.
Attempt to connect to your Public Server
  • Switch back to the EC2 console.
  • Select NextWork Public Server from the instances list.
  • Click Connect at the top of the page.
  • Select the EC2 Instance Connect tab.
  • Select Connect using a Public IP.

Before you click Connect, what do you expect to see?

  • Click Connect.

The connection attempt fails. Instead of a terminal window, you see an error.

This is exactly what should happen. Your NextWork Public Security Group currently only allows HTTP traffic on port 80. EC2 Instance Connect needs SSH access on port 22, which is blocked.

Why did the connection fail?

EC2 Instance Connect establishes an SSH session (port 22) between your browser and the instance. A security group acts as a virtual firewall that controls what traffic can reach the instance.

Right now, NextWork Public Security Group only has a rule allowing HTTP traffic (port 80). There's no rule for SSH, so the security group silently drops the connection attempt.

Diagnose and fix the missing SSH rule

You've confirmed the security group is the problem. Let's go look at the actual rules and add the missing SSH rule.

  • Switch to the VPC console.
  • In the left navigation pane, select Security groups.
  • Select NextWork Public Security Group.
  • Select the Inbound rules tab.

You can see the problem. The only rule allows HTTP (port 80). There is no rule for SSH (port 22).

  • Click Edit inbound rules.
  • Click Add rule.
  • Set Type to SSH.
  • Set Source to Anywhere-IPv4.
  • Click Save rules.

The inbound rules list now shows two rules: the original HTTP rule and your new SSH rule.

Why use Anywhere-IPv4 as the source?

EC2 Instance Connect uses various IP address ranges to initiate the SSH connection to your instance. Setting the source to Anywhere-IPv4 ensures Instance Connect works regardless of which IP it connects from.

In a production environment, you would restrict the source to the specific EC2 Instance Connect IP prefix list for your region. For this project, Anywhere-IPv4 keeps things simple.

Rule not saving?

Make sure you selected SSH from the Type dropdown, not a custom TCP rule. The SSH option automatically sets the port to 22.

Also confirm the Source field is set to Anywhere-IPv4 and not left blank. A blank source will prevent the rule from saving.

Help me fix my security group inbound rule

Connect to your Public Server again

The security group now allows SSH traffic. Let's try connecting again.

  • Return to the EC2 console.
  • Select NextWork Public Server.
  • Click Connect.
  • Select the EC2 Instance Connect tab.
  • Select Connect using a Public IP.

This time, do you expect the connection to succeed? Why?

  • Click Connect.

A browser-based terminal window opens. You can see a prompt showing ec2-user@ip-10-0-0-xxx, confirming you have SSH access to your Public Server.

What just happened?

Your SSH connection passed through two layers of security. First, the Public NACL checked the traffic at the subnet boundary and allowed it (your Public NACL allows all traffic). Then, the security group checked the traffic at the instance level and allowed it because of the new SSH rule you just added.

The ec2-user in the prompt is the default username for Amazon Linux instances. The IP address after the @ is the private IP of your Public Server.

Connection still failing?

Confirm that NextWork Public Server has a public IPv4 address under the Networking tab. EC2 Instance Connect requires a public IP to establish the connection.

Double check that you added the SSH rule to NextWork Public Security Group, not to a different security group. Select the instance, check the Security tab, and confirm the attached security group has both the HTTP and SSH inbound rules.

Help me troubleshoot my EC2 Instance Connect session

You now have a live terminal inside your Public Server. Next up, you'll use this terminal to test whether your Public and Private Servers can communicate across subnets.

Test Connectivity to Your Private Server

Your Public Server now accepts SSH connections. Next, you'll test whether your two servers can actually communicate across subnets.

You'll use ping, a command that sends ICMP packets to another machine and waits for a reply. Right now, both your Private NACL and Private Security Group block ICMP traffic, so the first attempt will fail.

In this step, get ready to:
  • Test ICMP connectivity from your Public Server to your Private Server.
  • Fix the Private NACL to allow ICMP traffic across subnets.
  • Update the Private Security Group to allow ICMP from your Public Server.
Ping the Private Server

Before you can ping the Private Server, you need its private IP address. You'll grab that from the EC2 console in a separate browser tab so your Instance Connect terminal stays open.

  • Open a new browser tab and navigate to the EC2 console.
  • Select Instances in the left navigation pane.
  • Select NextWork Private Server.
  • Select the Networking tab and copy the Private IPv4 address: your Private Server's Private IPv4 address

Now switch back to your EC2 Instance Connect terminal tab. Before you run the next command, think about this: do you expect the ping to succeed or fail? Consider what security layers sit between your Public Server and your Private Server.

  • Run this command to ping your Private Server:
ping [[PRIVATE_IP="your Private Server's Private IPv4 address"]]

You see a line showing a ping packet was sent, but no replies come back. The terminal just hangs, waiting.

Why did the ping fail?

Your ping packets hit two walls on the way to the Private Server. First, the Private NACL denies all inbound traffic at the subnet boundary. Second, the Private Security Group has no ICMP rule at the instance level.

Both layers must allow ICMP for the ping to reach the Private Server and for the reply to come back. You'll fix each one now.

Leave the ping running. You'll switch to another browser tab to fix the NACL and Security Group, then come back to see the results live.

Update the Private NACL to allow ICMP

The Private NACL controls traffic at the subnet boundary. It currently denies everything, so your ICMP packets are blocked before they even reach the Private Server's security group.

  • Switch to your AWS console browser tab and open the VPC console.
  • Select Subnets in the left navigation pane.
  • Select NextWork Private Subnet.
  • Select the Network ACL tab.

The associated NACL denies all inbound and outbound traffic. This is the first layer blocking your ping.

  • Click the link to NextWork Private NACL to open it.
  • Select the Inbound rules tab.
  • Select Edit inbound rules.
  • Select Add new rule.
  • Set the rule number to 100.
  • Set Type to All ICMP - IPv4.
  • Set Source to 10.0.0.0/24.
  • Select Save changes.

Why 10.0.0.0/24 as the source?

The source 10.0.0.0/24 matches the public subnet's CIDR range. This means the NACL only allows ICMP traffic coming from your public subnet, not from the entire internet.

That covers inbound traffic. Now you need a matching outbound rule so the Private Server can send reply packets back.

  • Select the Outbound rules tab.
  • Select Edit outbound rules.
  • Select Add new rule.
  • Set the rule number to 100.
  • Set Type to All ICMP - IPv4.
  • Set Destination to 10.0.0.0/24.
  • Select Save changes.

Why does the NACL need both inbound and outbound rules?

NACLs are stateless. This means they do not remember whether a packet is part of an existing connection. Every packet is evaluated independently against the rules.

Without the outbound rule, your Private Server would receive the ping but its reply packet would be blocked on the way out. You need explicit rules in both directions.

Update the Private Security Group and verify connectivity

The NACL now allows ICMP at the subnet boundary. The second layer is the Private Security Group, which controls traffic at the instance level.

  • In the VPC console left navigation pane, select Security groups.
  • Select NextWork Private Security Group.
  • Select the Inbound rules tab.

The security group has an SSH rule but no ICMP rule. Even though the NACL now allows ICMP, the security group still blocks it at the instance level.

  • Select Edit inbound rules.
  • Select Add rule.
  • Set Type to All ICMP - IPv4.
  • Set Source to NextWork Public Security Group.
  • Select Save rules.

Why only an inbound rule for the security group?

Security groups are stateful. When a security group allows inbound traffic, the return traffic is automatically allowed. You only need the inbound ICMP rule because the outbound reply is handled for you.

This is the opposite of NACLs, where you needed explicit rules in both directions.

  • Switch back to your EC2 Instance Connect terminal tab.

Reply lines are now streaming in from your earlier ping. Each line shows a successful ICMP response with a time value and TTL.

  • Press Ctrl+C to stop the ping after confirming several reply lines have appeared.

Not seeing any replies?

  • Double check the Private NACL has both an inbound and outbound rule for All ICMP - IPv4. A missing outbound rule blocks the reply packets silently.
  • Confirm the Private Security Group's ICMP inbound rule uses NextWork Public Security Group as the source, not an IP address.
  • Verify the NACL rule source and destination are both 10.0.0.0/24. A typo in the CIDR block prevents the rule from matching your traffic.
  • If you stopped the earlier ping, run the ping command again with the Private Server's IP address.

Still stuck? Help me troubleshoot why my ping to the Private Server is not getting replies.

What just happened across both layers?

Your ping packet traveled from the Public Server, through the Public NACL (which allows all traffic), across to the private subnet where the Private NACL checked it against Rule 100 (allow ICMP), and then to the Private Server where the Security Group checked it against the ICMP inbound rule.

The reply took the reverse path. The Security Group allowed it automatically (stateful). The Private NACL checked it against outbound Rule 100 (allow ICMP). Both layers had to say "yes" for the round trip to work.

Your servers can talk to each other across subnets. Next, you'll test whether your Public Server can reach the public internet.

Test Internet Connectivity from Your Public Server

Your Public and Private Servers are communicating across subnets. Ping packets flow freely between them, proving your NACL and security group configurations work together as layered defenses.

Can your Public Server actually reach the public internet? This test validates the entire traffic path: your server sends traffic through the public subnet, the route table directs it to the internet gateway, and the response comes back.

In this step, get ready to:
  • Test internet access from your Public Server using curl.
  • Confirm outbound HTTP connectivity by fetching a second website.
  • Trace the full traffic path through every VPC layer.
Stop the ping and test internet access

The ping command from the previous step may still be running in your EC2 Instance Connect terminal. You need to stop it before running a new command.

  • In the EC2 Instance Connect terminal, press Ctrl+C to stop the running ping.

Before you run the next command, think about this: your Public Server has a public IP address, a route table entry pointing internet-bound traffic to the internet gateway, and a public NACL that allows all traffic. Do you think an HTTP request to the public internet will succeed or fail?

  • Test your Public Server's internet access by running this command:
curl example.com

The terminal outputs raw HTML content from example.com. You should see HTML tags like <html>, <body>, and text about "Example Domain". Your Public Server can reach the public internet.

What is curl?

curl is a command-line tool that sends HTTP requests to a URL and prints the response directly to your terminal. It comes pre-installed on Amazon Linux 2023.

Getting HTML back from example.com proves your Public Server can send traffic out to the internet and receive a response. That is your full VPC traffic path working end-to-end.

Not getting any output?

  • Make sure you pressed Ctrl+C to stop the previous ping before running curl.
  • If curl hangs with no output, check that your Public Route Table has a route from 0.0.0.0/0 to the internet gateway in the VPC console.
  • Confirm your Public Server still has a public IPv4 address under the Networking tab in the EC2 console. Without one, outbound internet traffic cannot be routed back.
  • Why can't my EC2 instance reach the internet with curl?
Fetch a second website to confirm connectivity

One successful request is good. A second confirms the pattern and proves your internet access is not a fluke.

  • Fetch a different website by running this command:
curl learn.nextwork.org

The output shows a redirect response containing the word "Found". This confirms HTTP traffic flows out to the internet and responses come back through all layers of your VPC.

Why does this work?

Three pieces line up to make outbound internet access possible:

  • NextWork Public Route Table has a route sending all internet-bound traffic (0.0.0.0/0) to the internet gateway.
  • NextWork Public NACL allows all inbound and outbound traffic, so nothing is blocked at the subnet boundary.
  • NextWork Public Security Group allows response traffic back to the instance.
Trace the full traffic path

You have now proven that traffic flows from your Public Server to the internet and back. Take a moment to understand exactly how that happens.

How does traffic flow from your server to the internet?

When you ran curl example.com, the request passed through every layer of your VPC:

  • Your Public Server sends an HTTP request. The route table checks the destination and matches 0.0.0.0/0, directing the packet to the internet gateway.
  • The NACL checks the traffic at the subnet boundary. NextWork Public NACL allows all traffic, so the packet passes through.
  • The internet gateway translates the Private IP to the server's public IP and sends the packet out to the internet.
  • The response follows the same path in reverse. The internet gateway, NACL, and security group each check the returning traffic at their respective layers.

All layers must allow the traffic for the request to succeed. If any single layer blocks it, the entire request fails.

Secret mission

Explore NACL Rule Ordering

What happens when your NACL has both an ALLOW and a DENY rule for the same traffic? In this challenge, you will add a lower-numbered DENY rule to intentionally break ping connectivity between your servers. You will then diagnose why the DENY won and restore your setup.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project uses two EC2 instances that consume Free Tier hours while running.

Cost warning

For AWS accounts created before July 15, 2025, t2.micro instances are free for 750 hours per month during your first 12 months. For accounts created on or after July 15, 2025, t2.micro is NOT Free Tier eligible. Free Tier eligible types include t3.micro and others, free for 6 months or until credits are used.

If your Free Tier period has expired or your instances are not a Free Tier eligible type, running instances will incur charges. Terminate them when you are done to avoid unexpected costs.

Resources you used:

  • NextWork Public Server and NextWork Private Server (2x EC2 t2.micro instances running Amazon Linux 2023 AMI).
  • NextWork VPC and all associated resources (public and private subnets, route tables, internet gateway, NACLs, security groups).

Keep everything running

No action needed. Choose this if you are continuing to the next project in the VPC series (Part 6: VPC Peering) today.

  • Your two EC2 instances will continue to consume Free Tier hours while running.
  • All VPC resources (subnets, route tables, internet gateway, NACLs, security groups) remain in place at no additional charge.

Pause - I'll come back to this later

Stop both EC2 instances to free up compute charges while keeping your files and configuration intact. Stopped instances do not incur compute charges, but EBS storage charges still apply (covered under Free Tier).

  • In the EC2 console, select both NextWork Public Server and NextWork Private Server.
  • Choose Instance state, then Stop instance.
  • Confirm both instances show a Stopped state.
  • When you are ready for the next project, select both instances, choose Instance state, then Start instance.

Delete - I don't want to use this again

Remove all project resources and start fresh. You will rebuild the VPC in the next project if needed.

  • In the EC2 console, select both NextWork Public Server and NextWork Private Server.
  • Choose Instance state, then Terminate instance.
  • Confirm both instances show a Terminated state.
  • Navigate to the VPC console. Select Your VPCs in the left sidebar.
  • Select NextWork VPC, choose Actions, then Delete VPC. This removes all associated resources including subnets, route tables, the internet gateway, NACLs, and security groups.
  • Check each VPC console page (Subnets, Route tables, Internet gateways, Network ACLs, Security groups) to confirm cleanup is complete.

Nice Work!

Nice Work!

You just proved that your VPC actually works. You didn't just configure resources and hope for the best. You tested every layer of connectivity, diagnosed real failures, and fixed them by tracing traffic through security groups and NACLs.

You've learned how to:

  • Connected to your Public Server via EC2 Instance Connect by diagnosing and fixing a missing SSH inbound rule in your security group.
  • Established ICMP connectivity (ping) between your Public and Private Servers by updating both the Private NACL and Private Security Group to allow ICMP traffic.
  • Verified internet access from your Public Server using curl, proving the complete traffic path through route tables, NACLs, security groups, and the internet gateway.
  • Explored NACL rule evaluation order by adding a lower-numbered DENY rule that overrode an existing ALLOW rule, then restoring connectivity.

Ready to quiz yourself?