Windows 11에서 VMware 가상 머신 인터넷이 안 될 때 — NAT·Bridged·VMnet·DHCP 점검

작성자:
Windows 11에서 VMware 가상 머신 인터넷이 안 될 때 — NAT·Bridged·VMnet·DHCP 점검

Windows 11에서 VMware Workstation 가상 머신은 정상적으로 실행되는데 인터넷만 연결되지 않는 경우가 있습니다.

Host Windows에서는 인터넷이 정상인데 Guest Windows 또는 Linux에서는 웹사이트가 열리지 않거나, IP 주소 자체를 받지 못하는 상황입니다.

이때 VMware를 바로 재설치하거나 Windows 방화벽을 전부 끄기보다 먼저 어느 네트워크 단계까지 정상인지를 구분하는 것이 중요합니다.

VMware 가상 머신의 네트워크는 단순히 Guest OS 안에서만 동작하지 않습니다.

Guest Network Adapter
↓
VMware 가상 네트워크
↓
NAT 또는 Bridged
↓
Windows Host의 물리 네트워크
↓
Gateway / DNS / 외부 네트워크

여러 계층이 연결되어 있습니다.

따라서 이 글에서는 Guest IP부터 확인하고 NAT·Bridged·VMnet·DHCP·DNS 상태를 순서대로 점검합니다.

먼저 확인할 내용

확인 기준 환경

  • OS: Windows 11 25H2
  • VMware Workstation: VMware® Workstation Pro 26H1, 26.0.0.25388281
  • Host OS: Windows
  • Guest OS: Windows 또는 Linux
  • 네트워크 모드: NAT 또는 Bridged 기준

Windows 11 25H2는 이 글의 확인 기준 OS이며, 아래에 설명한 모든 VMware 네트워크 오류를 동일 환경에서 직접 재현했다는 의미는 아닙니다.

공식 문서 확인일: 2026-08-25

대표 증상

다음과 같은 상황을 대상으로 합니다.

  • VMware 가상 머신은 실행되지만 인터넷이 안 됨
  • Host Windows는 인터넷 정상, Guest만 연결 실패
  • Guest가 169.254.x.x 주소를 사용함
  • Guest에 IP 주소는 있지만 인터넷이 안 됨
  • Default Gateway가 없음
  • Gateway까지는 통신되지만 외부 인터넷이 안 됨
  • IP 주소로는 연결되지만 도메인 접속이 안 됨
  • NAT에서는 정상인데 Bridged에서 실패함
  • Bridged에서는 정상인데 NAT에서 실패함
  • VPN 연결 후 VMware 네트워크가 동작하지 않음
  • VMware 업데이트 후 Guest 네트워크가 연결되지 않음
  • VMnet8 또는 VMware NAT 관련 문제가 의심됨

결론

전체 진단 순서는 다음과 같습니다.

VM Network Adapter 확인
↓
Guest IP 확인
↓
Default Gateway 확인
↓
NAT / Bridged 모드 구분
↓
VMnet 상태 확인
↓
VMware NAT / DHCP 서비스 확인
↓
Host 인터넷 상태와 비교
↓
DNS와 외부 TCP 연결 구분
↓
Bridged 대상 물리 NIC 확인
↓
Firewall / VPN 확인
↓
필요한 설정만 수정
↓
동일 조건으로 재검증

핵심은 인터넷이 안 된다는 하나의 증상만 보고 모든 네트워크 설정을 동시에 바꾸지 않는 것입니다.

1. VMware Network Adapter 설정부터 확인

먼저 문제가 발생한 가상 머신을 선택하고 다음으로 이동합니다.

VM → Settings → Network Adapter

현재 어떤 네트워크 모드를 사용하는지 확인합니다.

대표적인 방식은 다음 세 가지입니다.

Bridged

Guest 가상 머신을 Host가 연결된 실제 네트워크에 직접 연결하는 방식입니다.

일반적으로 VMware의 기본 Bridged 네트워크는:

VMnet0

과 연결됩니다.

NAT

Guest가 Host의 네트워크 연결을 이용해 외부로 통신하는 방식입니다.

기본 NAT 네트워크는 일반적으로:

VMnet8

입니다.

Host-only

Host와 Guest 사이에 격리된 사설 네트워크를 구성할 때 사용합니다.

기본 Host-only 네트워크는:

VMnet1

입니다.

인터넷 연결이 필요한 VM인데 의도하지 않게 Host-only로 설정돼 있다면 외부 인터넷 연결이 되지 않는 것이 정상일 수 있습니다.

2. NAT와 Bridged의 차이를 먼저 이해하기

두 모드를 같은 네트워크 방식으로 생각하면 문제 해결이 복잡해집니다.

NAT

구조는 다음과 같습니다.

Guest VM
↓
VMnet8 사설 네트워크
↓
VMware NAT
↓
Windows Host
↓
외부 네트워크

Guest는 Host와 별도의 VMware 내부 IP를 사용합니다.

외부 네트워크에서는 일반적으로 Guest가 Host와 별도의 물리 장비처럼 직접 보이지 않습니다.

인터넷 접속 위주라면 NAT가 비교적 단순합니다.

Bridged

구조는 다음과 같습니다.

Guest VM
↓
VMnet0 Bridge
↓
Host의 Ethernet 또는 Wi-Fi
↓
물리 LAN

Guest가 같은 LAN의 다른 PC처럼 동작합니다.

예를 들어 Host가:

192.168.0.10

이고 Bridged Guest가:

192.168.0.20

을 받을 수 있습니다.

단, 실제 IP 할당은 네트워크의 DHCP 정책과 구성에 따라 달라집니다.

3. 먼저 Guest의 IP 주소 확인

네트워크 문제가 발생하면 가장 먼저 Guest가 어떤 IP를 사용하는지 확인합니다.

Windows Guest

CMD 또는 PowerShell에서:

ipconfig /all

또는:

Get-NetIPConfiguration

을 실행합니다.

확인할 항목은 다음과 같습니다.

  • IPv4 Address
  • Subnet Mask 또는 Prefix
  • Default Gateway
  • DNS Server
  • DHCP Enabled

Linux Guest

다음 명령을 사용할 수 있습니다.

ip addr

조금 더 간단하게 보려면:

ip -br addr

Route는:

ip route

로 확인합니다.

Guest 안에서 IP 주소를 먼저 확인해야 VMware 문제인지 Guest TCP/IP 문제인지 구분할 수 있습니다.

4. 169.254.x.x 주소가 할당된 경우

Windows Guest에서 다음과 같은 주소가 보일 수 있습니다.

169.254.x.x

Windows가 DHCP Server에서 정상적으로 주소를 받지 못했을 때 사용하는 APIPA 주소일 가능성을 먼저 확인해야 합니다.

예를 들어:

169.254.30.15

가 설정되어 있고 Default Gateway도 없다면 외부 인터넷 연결이 되지 않을 가능성이 높습니다.

이 경우 DNS보다 먼저 DHCP 단계를 확인합니다.

NAT 환경이라면

다음 영역을 확인합니다.

  • VMware Network Adapter가 NAT인지
  • VMnet8 상태
  • VMware DHCP 기능
  • VMware NAT 기능

Bridged 환경이라면

다음 영역을 확인합니다.

  • 실제 LAN DHCP Server
  • Bridged 대상 물리 NIC
  • Wi-Fi 또는 Ethernet 연결
  • 네트워크의 MAC Address 정책

IP를 받지 못하는 상황에서는 브라우저나 DNS 설정을 먼저 바꿀 필요가 없습니다.

5. Default Gateway 확인

IP 주소가 정상적으로 보이더라도 Default Gateway가 없다면 외부 네트워크로 나갈 수 없습니다.

Windows Guest에서는:

ipconfig /all

또는:

Get-NetIPConfiguration

으로 확인합니다.

Route 정보를 더 자세히 보려면:

route print

을 사용할 수 있습니다.

Linux에서는:

ip route

결과에서 다음과 같은 기본 Route를 확인합니다.

default via 192.168.x.2 dev eth0

환경에 따라 Gateway 주소는 달라집니다.

중요한 것은 Guest에 Default Route 자체가 존재하는지입니다.

6. Gateway까지 통신되는지 확인

Default Gateway가 확인됐다면 Guest에서 해당 주소까지 통신되는지 확인합니다.

예를 들어 Gateway가:

192.168.100.2

라면 Windows Guest에서:

ping 192.168.100.2

를 실행할 수 있습니다.

Linux에서는:

ping -c 4 192.168.100.2

를 사용할 수 있습니다.

다만 ICMP Echo를 차단하는 환경도 있으므로 Ping 실패 하나만으로 Gateway가 완전히 단절됐다고 단정해서는 안 됩니다.

Ping은 여러 확인 방법 중 하나로 사용합니다.

7. 외부 TCP 연결 여부 확인

Gateway까지 확인했다면 외부 네트워크 연결을 확인합니다.

Windows Guest에서는:

Test-NetConnection www.microsoft.com -Port 443

를 사용할 수 있습니다.

특히 다음 결과를 확인합니다.

TcpTestSucceeded : True

정상이라면 외부 HTTPS 서비스까지 TCP 연결이 가능한 상태입니다.

하지만 이 테스트는 Hostname을 사용하므로 DNS도 함께 필요합니다.

DNS를 별도로 분리해서 확인하려면 다음 단계로 넘어갑니다.

8. DNS 문제인지 먼저 구분

Guest에서 인터넷이 안 되는 것처럼 보여도 실제로는 DNS만 실패할 수 있습니다.

Windows Guest에서 다음 명령을 실행합니다.

Resolve-DnsName www.microsoft.com

정상적으로 IP 주소가 반환되는지 확인합니다.

Linux Guest

systemd-resolved를 사용하는 환경이라면:

resolvectl status

또는:

resolvectl query www.microsoft.com

을 사용할 수 있습니다.

환경에 따라 다음 파일도 확인할 수 있습니다.

cat /etc/resolv.conf

IP 연결은 되는데 DNS만 실패한다면

VMware Adapter를 재설치하기 전에 다음을 확인합니다.

  • Guest DNS Server
  • DHCP에서 전달된 DNS
  • VMware NAT DNS Proxy
  • Host의 DNS 설정
  • VPN DNS
  • 사내 DNS 정책

9. Host와 Guest 결과를 비교

VMware 네트워크 문제를 빠르게 구분하는 방법 중 하나가 같은 테스트를 Host와 Guest에서 비교하는 것입니다.

Windows Host에서:

Resolve-DnsName www.microsoft.com

Test-NetConnection www.microsoft.com -Port 443

를 실행합니다.

Guest에서도 같은 명령을 실행합니다.

Host 정상 + Guest 실패

VMware 가상 네트워크 또는 Guest 네트워크 설정을 우선 확인합니다.

Host + Guest 모두 실패

VMware만의 문제라고 보기 어렵습니다.

다음 영역을 먼저 확인합니다.

  • 실제 인터넷 회선
  • Host DNS
  • Host Gateway
  • VPN
  • Firewall
  • Proxy

이렇게 Host와 Guest를 비교하면 불필요한 VMware 재설치를 줄일 수 있습니다.

10. NAT 모드에서 실패한다면 VMnet8 확인

NAT 모드를 사용하는 경우 VMware Workstation의 기본 NAT 네트워크는 일반적으로 VMnet8입니다.

Windows Host에서 VMware 가상 Adapter 상태를 확인할 수 있습니다.

PowerShell에서:

Get-NetAdapter |
Where-Object {
    $_.InterfaceDescription -like '*VMware*'
} |
Select-Object Name, InterfaceDescription, Status

환경에 따라 다음과 같은 Adapter를 확인할 수 있습니다.

VMware Network Adapter VMnet1

VMware Network Adapter VMnet8

VMnet8이 비활성화되어 있거나 예상하지 못한 상태라면 NAT 네트워크에 영향을 줄 수 있습니다.

11. VMnet0는 Windows Host Adapter 목록에 안 보일 수 있음

여기서 자주 혼동하는 부분이 있습니다.

기본적으로:

  • VMnet0 → Bridged
  • VMnet1 → Host-only
  • VMnet8 → NAT

로 사용되지만 Windows의 네트워크 Adapter 목록에서 항상:

VMware Network Adapter VMnet0

가 보여야 하는 것은 아닙니다.

Bridged 네트워크의 VMnet0는 Host의 물리 NIC와 연결되는 가상 Bridge 네트워크로 이해하는 편이 정확합니다.

따라서 Windows Get-NetAdapter 결과에 VMnet0라는 Host 가상 Adapter가 없다는 이유만으로 바로 오류라고 판단하지 않습니다.

12. VMware NAT와 DHCP 서비스 확인

Windows Host에서 NAT가 동작하려면 VMware 네트워크 구성 요소가 정상적으로 실행되고 있어야 합니다.

먼저 전체 VMware 관련 서비스를 확인합니다.

Get-Service |
Where-Object {
    $_.DisplayName -like 'VMware*'
} |
Select-Object Status, Name, DisplayName

환경에 따라 다음과 같은 서비스를 확인할 수 있습니다.

  • VMware NAT Service
  • VMware DHCP Service

설치 버전이나 구성에 따라 표시되는 서비스는 다를 수 있습니다.

Broadcom의 네트워크 Troubleshooting 문서에서도 Windows Host에서 NAT/DHCP 관련 vmnat.exe, vmnetdhcp.exe 프로세스 상태를 확인하도록 안내합니다.

프로세스는 다음과 같이 확인할 수 있습니다.

Get-Process vmnat, vmnetdhcp -ErrorAction SilentlyContinue

NAT에서만 인터넷이 안 된다면

특히 다음 부분을 확인합니다.

VMnet8 → DHCP → NAT Service

이 흐름이 정상적인지 확인합니다.

서비스가 중지되어 있다면 무조건 재설치하기보다 먼저 서비스 상태와 최근 변경 사항을 확인합니다.

13. Virtual Network Editor에서 VMnet8 확인

VMware Workstation에서 다음으로 이동합니다.

Edit → Virtual Network Editor

변경 권한이 필요한 경우 Change Settings를 선택합니다.

VMnet8을 선택합니다.

다음 항목을 확인합니다.

  • Type이 NAT인지
  • Subnet 주소
  • DHCP 사용 여부
  • NAT Settings
  • Gateway 설정

Broadcom 공식 문서에서도 VMnet8을 기본 NAT 네트워크로 설명합니다.

네트워크를 직접 변경한 적이 없다면 기본값과 지나치게 다른 설정이 있는지도 확인합니다.

14. DHCP 설정 확인

Virtual Network Editor에서 VMnet8 또는 사용하는 Custom VMnet을 선택합니다.

DHCP를 사용하는 구성이라면:

Use local DHCP service to distribute IP address to VMs

관련 설정이 활성화되어 있는지 확인합니다.

Guest가 계속 169.254.x.x 주소를 받는다면 DHCP 기능과 Guest의 DHCP 사용 여부를 함께 확인합니다.

Windows Guest에서는:

ipconfig /all

결과에서:

DHCP Enabled

상태를 확인할 수 있습니다.

Static IP를 사용하고 있는 VM이라면 VMware DHCP 문제로 판단하면 안 됩니다.

15. Guest에서 DHCP 주소 다시 요청

Guest가 DHCP 환경인데 IP 할당이 이상하다면 Windows Guest에서 다음과 같이 다시 요청할 수 있습니다.

ipconfig /release

그다음:

ipconfig /renew

을 실행합니다.

새 주소가 정상적으로 할당되는지 확인합니다.

하지만 계속 169.254.x.x가 할당된다면 반복해서 renew만 실행하지 말고 VMnet과 DHCP Server 상태를 확인해야 합니다.

16. NAT에서는 정상인데 Bridged에서만 실패하는 경우

이 결과는 매우 유용합니다.

NAT 정상 + Bridged 실패

라면 Guest OS 자체의 TCP/IP 문제일 가능성보다 Bridged 네트워크 영역을 우선 확인할 수 있습니다.

다음 항목을 확인합니다.

  • VMnet0
  • Bridged 대상 물리 NIC
  • Automatic Bridging
  • Wi-Fi / Ethernet
  • VMware Bridge Protocol
  • 물리 LAN DHCP
  • MAC Address 제한
  • 회사 네트워크 정책

즉 Guest OS를 다시 설치할 단계가 아닙니다.

17. Bridged가 어떤 물리 Adapter를 사용하는지 확인

Host에 다음 Adapter가 동시에 있을 수 있습니다.

  • Ethernet
  • Wi-Fi
  • VPN Adapter
  • Bluetooth Network
  • Loopback Adapter
  • VirtualBox Adapter
  • Hyper-V vEthernet
  • 기타 가상 NIC

Automatic Bridging 상태에서는 VMware가 의도하지 않은 Adapter를 선택하는 문제가 발생할 수 있습니다.

다음으로 이동합니다.

Edit → Virtual Network Editor

Bridged 네트워크를 선택합니다.

Bridged to

항목에서 실제 인터넷 연결에 사용하는 물리 Adapter를 확인합니다.

예를 들어 Host가 Wi-Fi를 사용 중이라면 현재 활성화된 Wi-Fi Adapter를 명시적으로 선택해 비교할 수 있습니다.

Broadcom 공식 Troubleshooting 문서에서도 Automatic Bridging이 잘못된 물리 Adapter를 선택하는 경우 직접 정상 Adapter를 지정하도록 안내합니다.

18. Host의 물리 Adapter 상태 확인

Windows Host에서는 다음 명령으로 실제 Network Adapter 상태를 확인할 수 있습니다.

Get-NetAdapter |
Sort-Object Status, Name |
Format-Table Name, InterfaceDescription, Status, LinkSpeed

현재 인터넷 연결에 사용하는 Adapter를 확인합니다.

예를 들어 Wi-Fi가 실제 인터넷 연결인데 VMware Bridge가 Ethernet 또는 사용하지 않는 가상 Adapter를 선택하고 있다면 Bridged Guest가 정상적으로 통신하지 못할 수 있습니다.

19. VMware Bridge Protocol 확인

Bridged 모드에서만 문제가 발생한다면 Host의 물리 Adapter에 VMware Bridge Protocol이 정상적으로 연결돼 있는지도 확인합니다.

Windows에서:

Win + R

을 누르고:

ncpa.cpl

을 실행합니다.

현재 사용하는 Ethernet 또는 Wi-Fi Adapter의 속성을 엽니다.

구성 요소 목록에서:

VMware Bridge Protocol

이 있는지 확인합니다.

Broadcom 공식 네트워크 Troubleshooting 문서에서는 Bridged 문제가 지속될 경우 VMware Bridge Protocol을 복구하는 절차도 안내합니다.

하지만 처음부터 Protocol을 삭제하고 다시 설치하지 말고 먼저:

NAT 비교 → 물리 NIC 확인 → Automatic Bridge 확인

순서로 진단하는 것이 좋습니다.

20. Wi-Fi Bridged 환경에서 DHCP가 안 되는 경우

VMware Workstation은 Wi-Fi에서도 Bridged 네트워크를 사용할 수 있습니다.

하지만 Bridged를 지원한다고 해서 Guest가 반드시 DHCP 주소를 받을 수 있다는 의미는 아닙니다.

회사·학교·공공 Wi-Fi처럼 네트워크 접근을 제한하는 환경에서는 새로운 MAC Address를 가진 Guest VM이 네트워크에 참여하지 못할 수 있습니다.

예를 들어 다음과 같은 정책입니다.

  • 등록된 MAC만 허용
  • 802.1X 기반 인증
  • NAC
  • Port Security
  • 장비 수 제한
  • 무선 AP 정책

이 경우:

NAT에서는 정상

이지만:

Bridged에서만 DHCP 실패

하는 상황이 생길 수 있습니다.

이때 Bridged 설정을 계속 수정하기보다 해당 네트워크가 추가 장치의 MAC Address를 허용하는지 확인해야 합니다.

21. Bridged 테스트를 NAT와 비교하기

Bridged 문제가 의심되면 진단 목적으로 잠시 NAT와 비교할 수 있습니다.

VM을 종료하거나 네트워크 변경이 안전한 상태에서:

VM → Settings → Network Adapter

로 이동합니다.

현재 Bridged라면 NAT로 변경한 뒤 Guest를 다시 확인합니다.

NAT 변경 후 인터넷 정상

다음 영역이 유력합니다.

  • VMnet0
  • Bridged 대상 NIC
  • VMware Bridge Protocol
  • LAN DHCP
  • 물리 네트워크 보안 정책

NAT에서도 동일하게 실패

Bridged만의 문제는 아닐 가능성이 커집니다.

Guest TCP/IP 또는 VMware 네트워크 공통 영역도 확인해야 합니다.

진단이 끝나면 원래 사용 목적에 맞는 네트워크 모드로 되돌립니다.

22. Bridged에서는 정상인데 NAT에서만 실패하는 경우

반대 상황도 가능합니다.

Bridged 정상 + NAT 실패

라면 다음 영역을 우선 확인합니다.

  • VMnet8
  • VMware NAT Service
  • VMware DHCP Service
  • VMnet8 Subnet
  • NAT Gateway
  • DNS Proxy
  • Custom NAT 설정

이 결과는 Guest NIC나 물리 인터넷 자체가 정상일 가능성을 보여주는 중요한 비교 자료가 됩니다.

23. Host의 VMnet8 IP 설정 확인

Windows Host에서 가상 Adapter까지 포함해 네트워크 구성을 확인하려면:

Get-NetIPConfiguration -All

을 사용할 수 있습니다.

VMware Network Adapter VMnet8의 IP 설정이 표시되는지 확인합니다.

또는:

ipconfig /all

로도 확인할 수 있습니다.

Guest NAT 주소와 VMnet8이 같은 VMware 사설 Subnet 범위에 있는지 비교합니다.

임의로 Host VMnet8 주소를 변경하지 말고 먼저 현재 값을 기록합니다.

24. DNS만 실패한다면 NAT DNS 동작도 확인

VMware NAT는 Guest DNS 요청을 Host가 알고 있는 DNS Server로 전달하는 구조를 사용할 수 있습니다.

따라서 NAT Guest에서:

  • IP 주소 정상
  • Gateway 정상
  • 외부 통신 일부 정상
  • Domain Name만 실패

한다면 DNS 영역으로 범위를 좁힙니다.

Windows Host에서:

Get-DnsClientServerAddress |
Where-Object {
    $_.ServerAddresses.Count -gt 0
} |
Select-Object InterfaceAlias, ServerAddresses

로 Host가 사용하는 DNS Server도 확인할 수 있습니다.

Guest에서는:

Resolve-DnsName www.microsoft.com

을 실행합니다.

Host DNS는 정상인데 NAT Guest에서만 실패한다면 VMware NAT DNS 또는 Guest DNS 설정을 추가로 확인합니다.

25. VPN 연결 후 VMware 네트워크가 안 되는 경우

Broadcom의 네트워크 Troubleshooting 문서에서도 VPN 소프트웨어가 VMware 가상 네트워크와 간섭할 수 있는 요소 중 하나로 안내됩니다.

VPN은 다음을 변경할 수 있습니다.

  • Default Route
  • DNS
  • Metric
  • 가상 Network Adapter
  • Firewall Policy
  • Split Tunnel
  • 전체 Tunnel 정책

따라서 다음 상황을 비교합니다.

VPN 연결 전 VMware 정상

↓

VPN 연결 후 Guest 인터넷 실패

이 패턴이 명확하다면 VMware를 재설치하기보다 VPN Network Policy와 VMware 가상 Network의 상호작용을 확인합니다.

업무용 VPN이라면 임의로 보안 기능을 비활성화하지 말고 조직 정책에 맞게 확인해야 합니다.

26. Windows Firewall을 무조건 끄지 않기

VMware 네트워크 문제를 확인할 때 다음과 같은 방법은 피하는 것이 좋습니다.

Windows Defender Firewall 전체 OFF

방화벽을 완전히 끈 상태가 아니어도 원인을 확인할 수 있습니다.

먼저:

  • Host Firewall
  • Guest Firewall
  • Endpoint Security
  • VPN
  • 네트워크 Firewall

중 어느 영역이 영향을 주는지 구분합니다.

특히 Host에서 인터넷은 정상이고 Guest만 실패한다면 VMware 가상 Adapter 트래픽이 보안 프로그램에 의해 차단되는지도 확인할 수 있습니다.

회사 PC라면 보안 제품이나 방화벽 정책을 임의로 해제하지 않습니다.

27. Guest Firewall과 VMware 네트워크 문제를 구분

인터넷 연결 자체는 정상인데 Guest로 들어오는 SSH, RDP, Web Server 접속만 실패하는 경우에는 다른 문제일 수 있습니다.

예를 들어 Guest에서:

Test-NetConnection www.microsoft.com -Port 443

이 정상이고 웹사이트도 열린다면 기본적인 외부 연결은 동작합니다.

그런데 Host에서 Guest의 SSH Port만 접속되지 않는다면:

  • Guest Firewall
  • SSH Server
  • NAT Port Forwarding
  • Bridged 접근 정책

등을 확인해야 합니다.

즉:

Guest 인터넷 안 됨

과:

Guest에서 실행하는 서비스로 외부 접속 안 됨

은 서로 다른 문제입니다.

28. NAT Guest로 외부에서 접속하려면 별도 구성이 필요할 수 있음

NAT 네트워크를 사용하는 Guest는 외부 LAN에서 Guest로 직접 연결하는 구조와 다릅니다.

예를 들어 Guest에서 SSH Server 또는 Web Server를 실행하고 Host 외부의 다른 PC에서 접근하려면 NAT Port Forwarding이 필요할 수 있습니다.

VMware Workstation의:

Edit → Virtual Network Editor → VMnet8 → NAT Settings

에서 Port Forwarding을 구성할 수 있습니다.

예를 들어 Host의 특정 Port를 Guest의 TCP 22로 전달하는 방식입니다.

하지만 단순 인터넷 접속 장애를 해결하는 과정에서는 Port Forwarding을 먼저 구성할 필요가 없습니다.

외부로 나가는 연결 문제와 외부에서 Guest로 들어오는 연결 문제를 구분합니다.

29. VMware Tools 문제인지도 구분

Guest OS 자체에서 Network Adapter가 전혀 보이지 않거나 장치 인식 문제가 있다면 VMware Tools 또는 Guest Driver 상태도 확인해야 합니다.

Windows Guest의 경우:

장치 관리자 → 네트워크 어댑터

에서 VMware 가상 Network Adapter가 정상적으로 인식되는지 확인합니다.

Network Adapter 자체가 Guest에 존재하지 않는 상황은 NAT/DNS 문제와는 다른 계층의 문제입니다.

하지만 Guest가 정상 IP를 받고 있다면 VMware Tools부터 다시 설치할 이유는 적습니다.

30. Virtual Network Editor의 Restore Defaults는 마지막 단계에 가깝게 사용

Broadcom 공식 Troubleshooting 절차에는 VMware Workstation의 네트워크 구성을 기본값으로 복원하는 방법도 포함되어 있습니다.

경로는:

Edit → Virtual Network Editor → Restore Defaults

입니다.

하지만 이 기능을 처음부터 사용하는 것은 권장하지 않습니다.

Custom VMnet, 변경한 Subnet, DHCP 설정, NAT Port Forwarding 등 기존 네트워크 구성이 영향을 받을 수 있기 때문입니다.

실행하기 전 최소한 현재 Virtual Network Editor 화면과 Custom 설정을 기록합니다.

먼저 다음 항목을 모두 확인합니다.

Network Mode
↓
Guest IP
↓
VMnet
↓
NAT / DHCP Service
↓
Bridge Adapter
↓
Firewall / VPN

그래도 VMware 네트워크 구성 자체가 손상된 것으로 판단될 때 Restore Defaults를 검토합니다.

31. Restore Defaults 이후 다시 확인할 항목

네트워크 기본값을 복원했다면 단순히 VMware 창이 열리는지만 확인하면 안 됩니다.

다시 Virtual Network Editor를 엽니다.

기본 구성이 생성됐는지 확인합니다.

일반적으로 다음 관계를 확인합니다.

VMnet0 → Bridged

VMnet1 → Host-only

VMnet8 → NAT

그다음 Guest를 실행하고 다시 IP를 확인합니다.

Windows Guest:

ipconfig /all

Linux Guest:

ip -br addr

정상적인 주소를 새로 받는지 확인합니다.

32. 재설치는 가장 마지막 단계로 두기

Broadcom의 공식 네트워크 Troubleshooting 문서도 여러 네트워크 확인 이후 최종 단계 중 하나로 VMware 제품 재설치를 제시합니다.

따라서 다음 순서는 권장하지 않습니다.

Guest 인터넷 실패

↓

VMware Workstation 삭제

↓

다시 설치

재설치 전에 적어도 다음을 확인하는 편이 좋습니다.

  • Guest IP
  • Network Mode
  • VMnet8 / VMnet0
  • NAT / DHCP
  • Bridged NIC
  • VMware Bridge Protocol
  • VPN
  • Firewall
  • Restore Defaults

원인이 LAN의 DHCP 정책인데 VMware를 다시 설치해도 같은 문제가 반복됩니다.

33. Wireshark로 Guest 네트워크 단계 추가 확인

기본 명령으로 원인을 찾기 어렵다면 Wireshark를 사용할 수 있습니다.

예를 들어 DHCP 주소를 받지 못한다면 다음 흐름을 확인할 수 있습니다.

DHCP Discover
↓
DHCP Offer
↓
DHCP Request
↓
DHCP ACK

Guest가 Discover를 보내지만 Offer를 받지 못한다면 DHCP Server까지의 경로를 확인해야 합니다.

DNS 문제라면:

DNS Query

↓

DNS Response

여부를 확인합니다.

TCP 연결 문제라면:

SYN

↓

SYN/ACK

↓

ACK

과정을 확인합니다.

Wireshark 기본 패킷 캡처 방법은 다음 글에서 먼저 확인할 수 있습니다.

Windows에서 Wireshark 설치 후 패킷 캡처 확인하기 — Npcap·인터페이스·필터 점검

자신이 관리하거나 분석 권한이 있는 시스템과 네트워크에서만 패킷을 캡처합니다.

34. 문제 유형별로 빠르게 구분

Guest가 169.254.x.x

우선 확인:

DHCP → VMnet → Network Mode

Guest IP는 정상, Gateway 없음

우선 확인:

DHCP 또는 Static Route 설정

Gateway까지 정상, 인터넷 실패

우선 확인:

NAT / Routing / Firewall / VPN

외부 연결 정상, Domain만 실패

우선 확인:

DNS

NAT 정상, Bridged 실패

우선 확인:

VMnet0 → 물리 NIC → Bridge Protocol → LAN DHCP/MAC 정책

Bridged 정상, NAT 실패

우선 확인:

VMnet8 → VMware NAT → VMware DHCP

Host와 Guest 모두 인터넷 실패

우선 확인:

VMware보다 Host / 실제 네트워크

이렇게 증상별로 범위를 나누면 불필요한 설정 변경을 크게 줄일 수 있습니다.

35. 수정 후 동일 조건으로 재검증

설정을 변경했다면 처음 사용한 명령으로 다시 확인합니다.

Windows Guest IP

ipconfig /all

또는:

Get-NetIPConfiguration

Route

route print

DNS

Resolve-DnsName www.microsoft.com

HTTPS 연결

Test-NetConnection www.microsoft.com -Port 443

Linux Guest

ip -br addr

ip route

resolvectl status

환경에서 resolvectl을 사용하지 않는다면:

cat /etc/resolv.conf

을 확인합니다.

최종적으로 Guest 브라우저 또는 필요한 서비스에서 실제 연결까지 정상적인지 확인합니다.

해결되지 않는 경우 추가 확인

문제가 계속된다면 다음 정보를 정리합니다.

  • Windows Host 버전
  • VMware Workstation 버전
  • Guest OS 종류 및 버전
  • Network Mode: NAT / Bridged / Host-only
  • Guest IPv4 Address
  • Default Gateway
  • DNS Server
  • DHCP 사용 여부
  • Host의 인터넷 정상 여부
  • ipconfig /all 또는 ip addr 결과
  • route print 또는 ip route 결과
  • Resolve-DnsName 결과
  • Test-NetConnection 결과
  • VMware NAT Service 상태
  • VMware DHCP Service 상태
  • VMnet8 상태
  • Bridged 대상 물리 NIC
  • VPN 사용 여부
  • Firewall 또는 Endpoint Security 사용 여부
  • VMware 업데이트 또는 네트워크 설정 변경 시점

이 정보를 기준으로:

Guest OS

VMware Virtual Network

Windows Host

Physical Network

중 어느 영역의 문제인지 구분합니다.

주의사항

VMware 네트워크 문제를 해결할 때 다음 사항을 주의합니다.

  • 인터넷이 안 된다고 처음부터 VMware를 재설치하지 않기
  • Windows Firewall 전체를 장시간 비활성화하지 않기
  • 회사 VPN이나 Endpoint Security를 임의로 제거하지 않기
  • VMnet8 주소를 원인 확인 없이 직접 변경하지 않기
  • 169.254.x.x가 보이면 DNS보다 DHCP부터 확인하기
  • NAT와 Bridged를 같은 네트워크 방식으로 보지 않기
  • VMnet0 Host Adapter가 안 보인다는 이유만으로 오류라고 판단하지 않기
  • Bridged에서는 Host의 실제 물리 NIC 선택 상태 확인하기
  • 회사·학교 네트워크의 MAC Address 정책도 고려하기
  • Restore Defaults 실행 전 Custom VMnet과 NAT Port Forwarding 설정 기록하기
  • 여러 설정을 한꺼번에 변경하지 않기
  • 설정 변경 후 반드시 같은 조건으로 재검증하기

마무리

Windows 11에서 VMware 가상 머신의 인터넷이 연결되지 않을 때 가장 먼저 확인해야 할 것은 VMware 재설치 여부가 아닙니다.

먼저 Guest에서:

IP Address

↓

Default Gateway

↓

DNS

를 확인합니다.

그다음 VMware에서는:

Network Adapter

↓

NAT / Bridged

↓

VMnet

↓

NAT / DHCP

순서로 확인합니다.

NAT와 Bridged를 서로 비교하는 것도 중요합니다.

NAT 정상 + Bridged 실패

라면 VMnet0, 물리 NIC, VMware Bridge Protocol 또는 실제 LAN 정책을 우선 확인할 수 있습니다.

반대로:

Bridged 정상 + NAT 실패

라면 VMnet8과 VMware NAT·DHCP 영역으로 범위를 좁힐 수 있습니다.

Guest에 169.254.x.x 주소가 표시된다면 웹브라우저나 DNS 설정부터 바꾸기보다 DHCP 할당 단계부터 확인해야 합니다.

IP와 Gateway는 정상인데 Domain Name만 해석되지 않는다면 DNS 문제로 다시 범위를 좁힐 수 있습니다.

전체 흐름을 정리하면 다음과 같습니다.

VMware Guest 인터넷 실패
↓
Network Adapter 확인
↓
Guest IP 확인
↓
Default Gateway 확인
↓
NAT / Bridged 구분
↓
VMnet 확인
↓
NAT / DHCP 또는 Bridged NIC 확인
↓
DNS / 외부 TCP 연결 확인
↓
VPN / Firewall 확인
↓
필요하면 Wireshark 분석
↓
필요한 설정 하나만 수정
↓
동일 조건으로 재검증

결국 VMware 네트워크 장애를 빠르게 해결하려면 “인터넷이 안 된다”가 아니라 어느 계층까지 정상인지 확인하는 방식으로 접근하는 것이 중요합니다.

이 과정을 따르면 Guest OS, VMware, Windows Host, 물리 네트워크 중 실제 문제가 발생한 영역을 훨씬 명확하게 구분할 수 있습니다.

참고 자료

변경 이력

2026-08-25

  • 기존 VMware Workstation 설치·기본 사용 중심 콘텐츠를 VM 네트워크 장애 진단 중심으로 개편
  • Windows 11 25H2 확인 기준 환경 반영
  • NAT·Bridged·Host-only 네트워크 차이 추가
  • VMnet0·VMnet1·VMnet8 역할 구분 추가
  • Windows·Linux Guest IP 확인 절차 추가
  • 169.254.x.x DHCP 실패 진단 추가
  • Default Gateway 및 Route 확인 절차 추가
  • Host와 Guest 네트워크 결과 비교 추가
  • VMware NAT·DHCP 서비스 상태 확인 추가
  • Virtual Network Editor 기반 VMnet8 점검 추가
  • NAT 정상·Bridged 실패 및 반대 상황의 원인 분리 추가
  • Automatic Bridging과 물리 NIC 선택 점검 추가
  • VMware Bridge Protocol 확인 절차 추가
  • Wi-Fi·회사 네트워크의 DHCP/MAC 정책 관련 주의사항 추가
  • VPN·Firewall 영향 확인 추가
  • NAT Port Forwarding과 인터넷 연결 장애 구분 추가
  • Restore Defaults를 최후 단계로 사용하는 기준 추가
  • Wireshark를 이용한 DHCP·DNS·TCP 추가 분석 흐름 연결
  • 변경 후 동일 조건으로 정상 여부를 재검증하는 절차 추가
Post Views: 106