집 공유기 NAT 문제로 인한 VPN 연결 끊김과 해결 방법

집 공유기 NAT 환경에서 VPN 연결이 자주 끊기는 원인과 이를 해결하는 NAT-T(UDP 4500) 사용법, NAT 타임아웃 문제 등을 상세히 설명합니다. VPN 장애 시 NAT 존재 여부와 포트 설정을 점검하는 방법을 안내합니다.
Privacy Lab Editor's avatar
Mar 02, 2026
집 공유기 NAT 문제로 인한 VPN 연결 끊김과 해결 방법

VPN 쓰는데 왜 자꾸 끊기고, 접속이 이상하죠? 범인은 NAT일 때가 많습니다

집 공유기 뒤에서 VPN 연결했는데 “가끔 접속이 안 돼요”, “연결은 됐는데 특정 서비스만 먹통이에요”, “회사 VPN이 호텔 와이파이에선 죽어요” 같은 얘기, 꽤 흔하거든요. 이때 뒤에서 조용히 사고 치는 단골이 NAT입니다.

제가 2023년에 베트남 하노이 출장 중 호텔 와이파이에서 사내 IPsec VPN이 5~10분 간격으로 툭툭 끊기던 케이스를 잡아보니, 딱 NAT 타임아웃이 원인이었던 적이 있어요.

NAT(Network Address Translation)는 한마디로 “우리 집(사설 IP) 사람들 여러 명이, 밖에 나갈 땐 한 명(공인 IP)인 척” 해주는 변장술인데요. 이게 웹서핑엔 유능한데, VPN처럼 “서로의 주소를 정확히 알고 약속(암호화/인증)을 지키는 통신”에서는 문제를 만들기 쉽습니다. (NAT의 기본 개념과 VPN에서 이슈가 생길 수 있다는 언급은 나무위키 NAT 문서에도 정리돼 있어요: https://namu.wiki/w/NAT)

실무에서 이 개념이 중요한 이유는, VPN 장애의 절반은 “서버가 죽었나?”가 아니라 “중간에 NAT가 뭘 바꿔놨나?”를 먼저 의심해야 시간과 삽질을 확 줄일 수 있거든요.

집 공유기가 여러 기기의 사설 IP를 공인 IP 하나로 변환해 외부로 내보내는 NAT 개념도
집 공유기가 여러 기기의 사설 IP를 공인 IP 하나로 변환해 외부로 내보내는 NAT 개념도

NAT가 VPN을 괴롭히는 핵심 포인트 3가지

1) “주소가 바뀌면” VPN이 상대를 못 알아봅니다

VPN(특히 IPsec 계열)은 “너 누구야?”를 확인할 때 IP 주소 같은 정보가 꽤 중요하게 쓰이거든요. 그런데 NAT는 패킷이 지나가면서 출발지/목적지 IP를 바꿉니다. 그러면 VPN 입장에선 “아까 그 사람이 아닌데?” 같은 상황이 생겨요.

특히 지점-본사처럼 “이 IP에서만 접속”을 전제로 해둔 구성은, 회선이 바뀌거나(유동 IP), 중간에 NAT가 끼면 정적 구성이 깨지기 쉽습니다. IETF의 Auto Discovery VPN 문제정의 문서도 “엔드포인트 IP 변경이나 NAT 환경에서는 정적 구성이 불가능하다”는 식으로 이 이슈를 짚고 있어요( https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ad-vpn-problem-04 ).

NAT로 IP 주소가 바뀌어 VPN이 상대를 동일한 엔드포인트로 인식하지 못하는 상황
NAT로 IP 주소가 바뀌어 VPN이 상대를 동일한 엔드포인트로 인식하지 못하는 상황

2) IPsec은 원래 “그대로” 가길 좋아하는데, NAT는 “고쳐쓰기”가 직업입니다

일반 웹 트래픽(TCP/UDP)은 NAT가 포트까지 바꿔가며 잘 중개해요. 그런데 IPsec ESP 같은 프로토콜은 NAT가 상태를 추적하고 변환하기 까다로운 편입니다. 쉽게 비유하면, 택배 상자(패킷) 겉면 주소를 바꾸는데, 상자 봉인(암호화/무결성 검사)까지 건드리면 “봉인 훼손”으로 처리돼 버리는 느낌이죠.

그래서 NAT 환경에서 IPsec이 “협상은 되는데 데이터가 안 흐른다”, “특정 NAT에선만 안 된다” 같은 현상이 나옵니다. 환경마다 NAT 구현이 조금씩 달라서 증상이 들쭉날쭉할 수 있어요.

참고로 IETF 표준인 RFC 3947/3948에서도 IPsec을 NAT 환경에서 쓰려면 UDP 캡슐화(NAT Traversal)가 필요하다는 취지로 정리돼 있어서, 이게 “특정 벤더만의 변명”이 아니라 프로토콜 설계 레벨에서 다뤄지는 이슈예요.

3) “여러 사람이 한 명인 척” 하다 보니, 세션이 꼬이거나 끊깁니다

NAT는 내부 여러 기기의 연결을 테이블로 관리합니다. 문제는 VPN이 길게 유지되는 터널(세션)을 쓰는 경우가 많다는 점이에요. NAT 장비가 일정 시간 트래픽이 없다고 테이블을 지워버리면, VPN은 갑자기 길을 잃습니다. 사용자는 “가만히 두면 끊김”, “다시 연결하면 됨” 같은 체감으로 만나게 되죠.

IPsec은 그대로 가길 원하는데 NAT가 패킷을 고쳐 써서 무결성 문제가 생기는 비유 그림
IPsec은 그대로 가길 원하는데 NAT가 패킷을 고쳐 써서 무결성 문제가 생기는 비유 그림

NAT-T: “그럼 우회도로(UDP 4500)로 갑시다”

여기서 등장하는 게 NAT-T(NAT Traversal)입니다. 요지는 “IPsec 트래픽을 UDP로 한 겹 포장해서 NAT가 다루기 쉬운 형태로 만들자”예요. Juniper의 Junos OS 문서에 따르면 NAT-T는 NAT 장비를 통과하는 IPsec 트래픽의 주소 변환 문제를 해결하기 위해 UDP 포트 4500으로 캡슐화한다고 설명합니다( https://www.juniper.net/documentation/kr/ko/software/junos/vpn-ipsec/topics/topic-map/security-route-based-and-policy-based-vpns-with-nat-t.html ).

비유로 치면, 원래는 특수 화물(ESP)을 그대로 보내려다 검문소(NAT)에서 자꾸 걸리니까, “일반 택배(UDP)” 박스에 넣어서 통과시키는 거죠. NAT 입장에선 UDP는 워낙 흔하니 관리가 쉬워집니다.

다만 NAT-T가 만능열쇠는 아니고요.

  • 방화벽이 UDP 4500을 막으면 여전히 실패할 수 있고

  • 어떤 망/와이파이는 UDP 자체를 불안정하게 다루기도 하고

  • 이중 NAT(공유기 뒤에 또 공유기)면 문제 원인 찾기가 더 어려워집니다

참고로 NAT traversal 관련 위키피디아 문서에는 Windows XP 시절 “VPN 서버도 NAT 뒤에 있을 때” NAT traversal 기본 동작이 보안 논란 때문에 기본값이 바뀐 적이 있다고 언급돼요( https://en.wikipedia.org/wiki/NAT_traversal ). 이 얘기의 포인트는 하나입니다. NAT 통과는 “단순 편의 기능”이 아니라, 정책/보안/구현에 따라 동작이 달라질 수 있는 민감한 영역이라는 거죠.

문제 해결 루트: 사용자/운영자 입장에서 이렇게 접근하세요

1) 먼저 “NAT가 끼어 있나”부터 확인

  • 집/카페/호텔 와이파이: 거의 NAT 있다고 보시면 됩니다

  • 회사에서도 부서망 → 인터넷 경계에서 NAT 쓰는 경우 흔합니다

  • 휴대폰 테더링/모바일망: CGNAT(통신사 단 NAT)일 가능성이 있어요

확인은 간단하게 “내 PC IP(사설인지)”와 “외부에 보이는 IP”가 다른지 보면 감이 옵니다.

2) 증상별로 의심 포인트를 매칭

  • 연결 자체가 안 됨: UDP 500/4500 차단, NAT-T 미협상, 정책 불일치

  • 연결은 됐는데 트래픽이 안 감: ESP 처리 문제, NAT 테이블/세션 꼬임, MTU 문제(캡슐화로 패킷이 커짐)

  • 몇 분마다 끊김: NAT 타임아웃, keepalive 부족, 와이파이 절전/로밍

3) 운영자라면 “NAT 친화적 구성”을 기본값으로

  • IPsec이라면 NAT-T 사용을 전제로 설계(가능한 장비/클라이언트 설정 확인)

  • 방화벽에서 UDP 4500(및 협상에 필요한 포트) 정책 점검

  • 이중 NAT 구간 제거 또는 브리지/DMZ 등으로 경로 단순화(가능한 범위에서)

  • 터널 유지용 keepalive/DPD(Dead Peer Detection) 설정 점검

NAT 테이블이 시간 초과로 지워져 VPN 터널이 끊기는(유휴 시 끊김) 상황
NAT 테이블이 시간 초과로 지워져 VPN 터널이 끊기는(유휴 시 끊김) 상황

실행 체크리스트(현장용)

사용자(클라이언트) 체크

  • 다른 네트워크(집 ↔ 테더링 ↔ 다른 와이파이)로 바꿨을 때도 같은 증상인가?

  • VPN 앱/OS에서 NAT-T 관련 옵션이 있는가? (자동/활성화 여부)

  • “연결됨”인데 내부망 DNS/사내 서비스만 안 되면, 분기 터널(split tunnel) 정책 문제인지도 함께 확인(이건 NAT만의 문제는 아닐 수 있어요)

운영자(서버/게이트웨이) 체크

  • NAT-T 협상 여부 로그에서 확인(UDP 4500으로 전환됐는지)

  • 정책 기반/경로 기반 구성에서 NAT 뒤 피어 시나리오를 전제로 했는지(장비 벤더 가이드 참고)

  • 특정 ISP/특정 공유기에서만 실패한다면, 그 구간의 NAT/방화벽 제약(UDP 차단, 짧은 타임아웃)을 의심

NAT 환경에서 IPsec이 UDP로 캡슐화되어 통과하는 NAT-T 개념도
NAT 환경에서 IPsec이 UDP로 캡슐화되어 통과하는 NAT-T 개념도

마무리: NAT는 “나쁜 놈”이 아니라, VPN이 예민한 겁니다

다만, 이 글에서 말한 내용은 “공유기/통신사 NAT가 중간에 끼어 있는 일반적인 환경”을 기준으로 한 거라서, 기업 전용회선처럼 NAT 없이 라우팅만 타는 구간이거나 장비가 NAT-T를 강제로 최적화해주는 구성에선 체감이 다를 수 있습니다.

NAT는 원래 인터넷을 편하게 쓰게 해주는 실용적인 기술인데요. 문제는 VPN이 “주소/세션/암호화 무결성”에 예민하다는 점이고, NAT는 그중 주소와 세션을 건드리는 게 본업이라 충돌이 나는 겁니다. 그래서 NAT 환경에서 VPN이 말썽이면 “VPN이 불안정하다”로 끝내지 말고, NAT 존재 여부 → NAT-T(UDP 4500) → 포트/타임아웃/이중 NAT 순서로 차근차근 보면 해결 확률이 확 올라가요.

원하시면, 사용 중인 VPN 종류(IPsec/IKEv2/OpenVPN/WireGuard)랑 “어떤 네트워크에서, 어떤 증상인지”만 알려주시면 체크 포인트를 더 정확히 좁혀드릴게요. 환경마다 달라질 수 있거든요.

Share article

© 2026 Privacy Lab Korea. All rights reserved.