Troubleshooting labcore7 steps~18 min5 devices

Fix the NAT that translates nothing

The shop's desks and tills cannot reach the internet, yet the router itself can. Find why nothing leaves translated.

What you'll be able to do: Both LANs reach the internet behind the shop's single public address, and you can work the NAT checklist — inside and outside on the right interfaces, the right sources in the list — from `show` output alone.

Open the broken network in the lab

Topics: Troubleshooting · NAT · PAT overload · RFC 1918

The network you're handed

Bakery-Edge — a router, the shop's edge router, which owns the only public address
Provider — a router, the provider's router, standing in for the internet
Web-Host — a server, a web server out on the internet
PC-Office — a pc, the back-office desk
PC-Till — a pc, the till at the shop counter

Step by step

1. Reproduce the outage from both LANs
Nothing in the shop can reach the web. Ping the web server from the office desk and from the till, then ping the office desk's own gateway to see how far a packet gets.
On PC-Office — Test the internet, then the local gateway
```
ping 198.51.100.50
ping 192.168.10.1
```
On PC-Till — Test the internet from the second LAN
```
ping 198.51.100.50
```
Why: The gateway answers, so the LAN and the router's inside ports work. Both LANs failing the same way points at what they share — the edge router's way out — rather than at either PC.
2. Prove the router itself can get out
Ping the web server from Bakery-Edge itself. It works: the router's own packets leave with its public address, 203.0.113.2. Then look at the translation table — after all those failed pings from the desks, it is empty.
On Bakery-Edge — Test the path from the router, then check the route and the translations
```
enable
ping 198.51.100.50
show ip route
show ip nat translations
```
Check: run show ip route on Bakery-Edge and look for S* 0.0.0.0/0 via 203.0.113.1, Se0/0/0.
Why: The router reaching the server proves the provider link, the default route and the far side all work. The only difference between its packets and the desks' is the source address: 192.168.x.x is private (RFC 1918), and providers drop private sources. So every inside packet must leave translated — and an empty translation table says nothing was translated at all.
3. Ask NAT which side it thinks is which
PAT needs three things: interfaces marked inside, an interface marked outside, and a rule. All three exist — so check WHICH interfaces carry which role. `show ip nat statistics` lists them, and `show ip interface Se0/0/0` says what the WAN port is.
On Bakery-Edge — List the inside and outside interfaces, then check the WAN port
```
enable
show ip nat statistics
show ip interface Se0/0/0
```
Check: run show ip interface Se0/0/0 on Bakery-Edge and look for Network address translation is enabled, interface in domain inside.
Why: NAT only translates a packet that enters an INSIDE interface and leaves an OUTSIDE one. Here the office port Gi0/0 is marked outside and the WAN port Se0/0/0 is marked inside, so the office's packets travel outside-to-inside and are never translated. A checklist that only asks "is there an inside and an outside?" passes — which interface has which role is what matters.
4. Put the markers on the right interfaces
The LAN ports are inside, the provider link is outside. Re-mark Gi0/0 as inside and Se0/0/0 as outside — typing the new role replaces the old one — then retest from the office.
On Bakery-Edge — Swap the two NAT roles back
```
enable
configure terminal
interface Gi0/0
ip nat inside
exit
interface Se0/0/0
ip nat outside
end
```
On PC-Office — Retest the internet
```
ping 198.51.100.50
```
Check: run show ip interface Se0/0/0 on Bakery-Edge and look for Network address translation is enabled, interface in domain outside.
Why: Inside means "the private side I translate FROM", outside means "the public side I translate TO". With the roles right, the office's packets cross inside-to-outside, the overload rule rewrites their source to 203.0.113.2, and the provider's filter lets them through.
5. The till is still offline — check who may be translated
The office works; the till does not. Gi0/1 was always marked inside, so the till's packets now reach the NAT decision. Look at the translation table after the till's ping, and at the access list the NAT rule consults.
On PC-Till — Retest from the till
```
ping 198.51.100.50
```
On Bakery-Edge — See what was translated, and which sources the rule allows
```
enable
show ip nat translations
show access-lists
```
Check: run show access-lists on Bakery-Edge and look for 10 permit 192.168.10.0 0.0.0.255.
Why: The translation table only ever shows the office's address, never the till's. The NAT rule translates a source only if access list 1 permits it, and the list names 192.168.10.0/24 alone; a source the list does not permit is forwarded untranslated — straight into the provider's filter.
6. Let the till's subnet be translated
Add the till LAN to access list 1. A numbered list is appended to line by line, so the office's entry stays where it is. Then retest from the till.
On Bakery-Edge — Permit the second LAN in the NAT list
```
enable
configure terminal
access-list 1 permit 192.168.20.0 0.0.0.255
end
```
On PC-Till — Retest from the till
```
ping 198.51.100.50
```
Check: run show access-lists on Bakery-Edge and look for 20 permit 192.168.20.0 0.0.0.255.
Why: The access list in a NAT rule is not a filter here — it only selects which sources get translated. With both LANs in it, every inside host leaves as 203.0.113.2.
7. Prove both LANs share one public address
Ping from both LANs and read the translation table: two inside local addresses, one inside global address, told apart only by port number. That shared address is what "overload" means.
On PC-Office — Traffic from the office
```
ping 198.51.100.50
```
On PC-Till — Traffic from the till
```
ping 198.51.100.50
```
On Bakery-Edge — Read the translations
```
enable
show ip nat translations
```
Check: run show ip nat translations on Bakery-Edge and look for 192.168.20.10:.
Why: Every row carries the same inside global address, 203.0.113.2, with a different port per conversation. The router keeps the table so each reply finds its way back to the right inside host — which is how a whole shop shares one address the provider will carry.

The theory behind it

Fix the broken office — Nobody in a two-desk office can reach the intranet server. Find the two faults and fix them, one layer at a time.
Fix the VLAN that stops at the trunk — Engineering's server is unreachable and the south desk is cut off completely. Find the wrong VLAN and the trunk that drops it.
Fix the desks DHCP forgot — The clinic's desks come up with no address. Find why the DHCP server never hears them — then why their leases still go nowhere.
Fix the OSPF adjacencies — Three routers run OSPF and nothing converges. Find the area mismatch and the network statement that matches nothing.
Fix the branch that fails four ways — A branch depot has lost head office, and two of its hosts have faults of their own. Find all four, one layer at a time.

Build it for real

The lab walks you through these steps and ticks each one off as your network starts working.

Open in the lab

The network you're handed

Step by step

1. Reproduce the outage from both LANs

2. Prove the router itself can get out

3. Ask NAT which side it thinks is which

4. Put the markers on the right interfaces

5. The till is still offline — check who may be translated

6. Let the till's subnet be translated

7. Prove both LANs share one public address

The theory behind it

More in Troubleshooting

Build it for real