Why Can a Workstation Reach the Internet but Not Internal Resources?

A network administrator is troubleshooting a network connectivity issue. The workstation can connect to the internet but not to internal network resources. Which of the following is most likely the cause of the issue?

APIPA address
Rogue DHCP server
Unreachable DNS server Source Reference Answer
Incorrect NAT settings

Community Votes

42%

16%

42% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The question tests your ability to map common network failures to symptoms; the trap is choosing unreachable DNS because internal resources often use hostnames, but an unreachable DNS server would also prevent normal Internet name resolution.

The most likely cause is a rogue DHCP server, which can assign an IP configuration that provides Internet access while breaking access to internal network resources. Community commenters are split, but a symptom-based analysis points to rogue DHCP as the only option that matches the asymmetric connectivity.

Unreachable DNS server (C) is the most common wrong answer because test-takers assume internal resource failures are DNS-related, but a DNS outage would also disrupt Internet access when using hostnames. A rogue DHCP server best explains why the workstation can reach the Internet yet cannot reach internal resources.

Community Discussion (11 comments)

ATrek 👍 6 Selected: B

A. Both internal and external would not work. B. Internal would not work, but external yes. C. Both internal and external would not work. D. Internal would work, but external would not. Therefore the only option is B.

ETQ 👍 2 Selected: C

NAT makes no sense in this context. It's meant to translate a local IP into a public one to get multiple local devices to access internet. This is literally the opposite of the question that states they can ONLY connect to the INTERNET. I think a rogue DHCP would most likely cut all connection, if you get in a completely wrong subnet, you obviously won't access internal, and NAT won't work, since the router won't expect it. C is probably the sensible answer. External names could be resolved and not internal ones.

interestingtimes 👍 2 Selected: C

C seems like the safest bet here to me.

Dadadagreat 👍 1

D NAT is my answer in here

veggietron9000 👍 2 Selected: B

Rogue DHCP server might not disrupt your external internet access. Rogue DHCP server would almost certainly mess up your LAN settings and make it so that you're out of your typical network segment, making internal communication impossible.

JB1705 👍 2 Selected: C

NAT is to allow private networks to communicate with the internet using a limited number of public IP addresses. while setting up Printers in my office, it does take DNS address. so i guess answer should be C. unreachable DNS

shacky 👍 2

A) Wrong - with APIPA address you can't connect to the Internet B) Correct - there is a possibility that workstation received IP address and default gateway from the rogue DHCP. In that case Internet access works, however access to internal resources is prohibited. C) Wrong - if the DNS would be unreachable, connectivity to the Internet resources would not be possible D) Wrong - NAT settings has nothing to do with accessing internal resources. With incorrect nat settings connectivity to the Internet resources would not work, but it's no the case in the example

TrebleSmith 👍 2 Selected: C

Going to have to go with C. I would say the safest bet is to say internal DNS servers could be at play.

Joshuac1392 👍 1 Selected: D

d for sure

RogerWu 👍 1 Selected: D

I think is D.

4ddc874 👍 1 Selected: D

A NAT error is more likely to cause this issue. If the NAT configuration doesn't properly map the workstation's internal IP address to the public IP address used for internet access, the workstation might be able to access the internet but not communicate with internal resources on the private network.

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

A rogue DHCP server can hand out a lease from the wrong subnet or with a default gateway that routes only to the Internet, not to the corporate internal network. In this situation, the workstation still gets an IP address, default gateway, and DNS, so Internet access may work through the rogue server’s NAT or forwarding, while internal servers become unreachable. Comment [1] correctly summarizes that option B causes “internal not working, but external yes,” and comment [6] also explains that a rogue DHCP server can provide Internet access while blocking internal resources.

Why the Other Options Are Wrong

APIPA addresses (169.254.0.0/16) have no default gateway, so a workstation using APIPA cannot reach the Internet. An unreachable DNS server would prevent name resolution for both internal and external hosts, so a user who can browse the Internet almost certainly has working DNS. Incorrect NAT settings would break outbound Internet access, not internal LAN access, and internal traffic does not normally traverse NAT. Only a rogue DHCP server fits the symptom of Internet working while internal resources fail.

Community Comment Notes

The comment section is split between B and C, and some commenters choose NAT. However, comment [1] and comment [6] provide the strongest reasoning by ruling out APIPA, DNS, and NAT based on whether internal and external access would both fail or only one would fail. Comment [2] argues that rogue DHCP would cut all connection, but that is not always true: a rogue DHCP server with its own gateway/NAT can provide Internet while isolating the workstation from the corporate LAN.

Official Reference

Exam Strategy

When troubleshooting, map each failure to its symptom before selecting an answer: APIPA breaks all routed traffic, NAT problems break only Internet access, DNS problems affect name resolution everywhere, and DHCP misconfiguration can create asymmetric connectivity. If a device can reach the Internet but not internal subnets, suspect the workstation received incorrect IP settings from a rogue DHCP server rather than blaming DNS or NAT.

Related Analysis

← Back to N10-008 Study Guide