[pfSense] 12. NAT : pfSense 포트포워딩으로 내부 서버 공개하기

(pfSense 홈랩 방화벽 ⑫)

지금까지는 안에서 밖으로 나가는 얘기였다. 이번엔 반대다. 집에 있는 웹서버나 NAS를 바깥에서 접속하게 하려면 NAT 포트포워딩이 필요하다. WAN의 어떤 포트로 온 요청을 내부의 특정 기기로 넘겨 주는 거다.

이번 편에서는 pfSense 포트포워딩(NAT 설정)의 개념을 잡고, 내부 웹서버 공개 시나리오 하나를 필드 입력부터 외부 확인까지 끝까지 따라간다. 포트포워딩 안 될 때의 진단 순서도 내가 실제로 짚는 흐름 그대로 정리했다.

NAT의 세 종류

• 포트포워딩 — WAN:포트 → 내부 IP:포트. 제일 흔하다.
• 1:1 NAT — 공인 IP 하나를 내부 기기 하나에 통째로 매핑.
• Outbound NAT — 내부→바깥 나갈 때 출발지를 WAN IP로 바꾸는 것(기본 자동).

graph LR
  U([외부 사용자]) --> W[WAN : 8080]
  W --> N[NAT 변환]
  N --> S[내부 웹서버 192.168.10.20 : 80]

포트포워딩 만들기

Firewall > NAT > Port Forward에서 규칙을 추가한다. Interface는 WAN, 목적지 포트는 외부에 열 포트(예 8080), 리다이렉트 대상은 내부 서버 IP와 포트(예 192.168.10.20:80). 저장하면 pfSense가 대응하는 방화벽 허용 규칙을 자동 생성해 준다('Add associated filter rule'). WAN은 기본 차단이라 이 허용 규칙이 있어야 실제로 열린다.

실전 시나리오 — 내부 웹서버(192.168.10.20:443) 외부 공개

말로만 하면 감이 안 오니, 시나리오 하나를 끝까지 가 보자. 내부에서 HTTPS로 서비스 중인 웹서버(192.168.10.20:443)를 외부에서 https://공인IP로 접속하게 만드는 게 목표다. Firewall > NAT > Port Forward에서 Add(위쪽 화살표 버튼)를 누르고 이렇게 채운다.

여기서 제일 헷갈리는 게 Destination이다. “내부 서버 주소를 넣어야 하나?” 싶지만 아니다. Destination은 변환 전 패킷이 향하던 곳, 즉 우리 WAN 주소고, 내부 서버는 Redirect target에 들어간다. 그리고 외부 포트와 내부 포트가 같을 필요도 없다 — WAN:8443 → 내부:443처럼 바꿔 받는 것도 흔한 NAT 설정이다. Save 후 상단의 초록 Apply Changes까지 눌러야 실제 적용된다. 적용되면 Firewall > Rules > WAN 탭에 연동 규칙이 하나 생겨 있는 게 보인다 — 설명 앞에 NAT가 붙어 있으면 그게 자동 생성된 규칙이다.

외부에서 진짜 열렸는지 확인

확인은 반드시 네트워크 바깥에서 해야 한다. 같은 와이파이 안에서 공인 IP로 접속하는 건 별개 문제라(아래 NAT reflection 참고) 테스트가 안 된다.

• 모바일 LTE/5G — 폰의 와이파이를 끄고 https://공인IP로 접속해 본다. 제일 확실한 방법이다.
• 외부 포트체커 — canyouseeme.org 같은 포트 체크 사이트에 443을 넣고 Success가 뜨는지 본다.
• pfSense 쪽 확인 — Diagnostics > States에서 443으로 필터하면 공인IP:443 → 192.168.10.20:443으로 변환된 상태 항목이 보인다. 이게 보이면 NAT 자체는 동작 중이라는 뜻이다.

✅ 확인 — LTE로 접속했을 때 내부 서버의 페이지가 뜨고, Diagnostics > States에 변환된 상태가 잡히면 성공이다. 규칙을 비활성화하면 즉시 다시 막히는 것까지 확인하면 완벽하다.

⚠️ 홈랩에서 조심할 것

포트를 여는 건 곧 바깥에 문을 내는 일이다. 관리 페이지나 SSH를 아무 인증 없이 열어 두면 봇이 금방 찾아온다. 실제로 cozlab은 서비스를 이렇게 직접 포트포워딩으로 노출하지 않고, Cloudflare와 리버스 프록시 뒤에 둔다. 꼭 열어야 한다면 포트를 바꾸고, 강한 인증을 걸고, 다음 편의 Alias로 접근 출발지를 제한하는 게 좋다. 원격 접속만 필요하면 포트포워딩보다 VPN이 훨씬 안전하다.

직접 해보기

• 랩의 클라이언트 하나에 간단한 웹서버를 띄운다(예: python3 -m http.server 80).
• WAN:8080 → 그 내부 IP:80 포트포워딩을 만든다(연동 방화벽 규칙 포함).
• WAN 쪽에서 http://WAN_IP:8080으로 접속되는지 확인한다.
• 접속 직후 Status > System Logs > Firewall에서 8080 통과 로그가 초록으로 찍히는 것도 확인해 두자.

✅ 확인 — 외부(WAN) 쪽에서 내부 웹서버가 열리고, 포트포워딩을 끄면 다시 막히면 성공이다. 'WAN 기본 차단' 때문에 허용 규칙이 왜 필요한지 설명할 수 있는지도 확인하자.

안 될 때 — 체크리스트

• 포워딩과 함께 방화벽 통과 규칙이 생겼나.
• 내부 기기가 실제로 그 포트로 서비스 중인가(내부망에서 먼저 접속 테스트).
• 내부 기기 자체 방화벽이 막고 있지 않나.
• pfSense 앞에 통신사 공유기(이중 NAT)가 또 있지 않나.
• ISP가 그 포트(80·25 등)를 차단하지 않나.
• ‘내부에서 공인 IP로’ 접속하려면 NAT reflection이 필요하다 — 포워딩 규칙 편집 화면 맨 아래 NAT reflection을 Enable (Pure NAT)로 바꾸거나, System > Advanced > Firewall & NAT에서 전역으로 켠다. 내부 기기끼리는 내부 IP로 접속하는 게 원칙이지만, 공인 도메인 하나로 안팎을 통일하고 싶을 때 쓴다.

진단 순서 — 포트포워딩 안 될 때는 로그부터

체크리스트를 무작정 훑는 것보다, 패킷이 지나가는 순서대로 따라가면 원인이 훨씬 빨리 잡힌다. 나는 항상 방화벽 로그에서 시작한다.

graph TD
  A([외부에서 접속 실패]) --> B{방화벽 로그에 해당 트래픽이 보이나}
  B -->|안 보임| C[도달 자체가 안 됨 — 이중 NAT · ISP 차단 의심]
  B -->|빨간 차단| D[NAT 규칙 · 연동 방화벽 규칙 확인]
  B -->|초록 통과| E[서버 쪽 문제 — 서비스 · OS 방화벽 확인]

1. 로그에서 트래픽 확인 — Status > System Logs > Firewall을 열어 두고, 외부(LTE)에서 접속을 시도한 직후 새로고침한다. 필터에 목적지 포트(443)를 넣으면 찾기 쉽다. 시도한 시각에 WAN으로 들어온 항목이 보이는지가 첫 갈림길이다.
2. 아예 안 보이면 — 패킷이 pfSense까지 도달을 못 한 거다. 아래의 이중 NAT(WAN이 사설 IP인지), ISP 포트 차단, 공인 IP를 잘못 알고 있는 경우를 의심하자. 국내 ISP는 80·25 같은 인바운드 포트를 막는 경우가 있어서, 8080 등 다른 포트로 바꿔 다시 시도해 보면 구분된다.
3. 빨간 차단으로 찍히면 — 도달은 했는데 NAT나 방화벽에서 걸린 거다. NAT 규칙의 Interface·Protocol·포트가 맞는지, Firewall > Rules > WAN에 연동 허용 규칙이 살아 있는지 확인한다. 포워딩만 만들고 연동 규칙을 빼먹은 경우가 의외로 많다.
4. 초록 통과인데도 안 되면 — pfSense는 할 일을 다 한 거다. 이제 서버 쪽이다. 내부망에서 curl -k https://192.168.10.20으로 서비스 자체가 응답하는지 보고, 서버 OS 방화벽(ufw·firewalld·Windows Defender)이 다른 대역을 막고 있지 않은지, 서버의 기본 게이트웨이가 pfSense로 잡혀 있는지(아니면 응답이 다른 길로 새 버린다) 순서로 좁힌다.

이 순서로 가면 포트포워딩 안 될 때의 원인 대부분 — 규칙 문제, 이중 NAT, 서버 방화벽, ISP 차단 — 이 한 바퀴 안에 걸린다. 방화벽 로그 화면 자체를 읽는 법은 21편 로그 모니터링에서 자세히 다룬다.

내부에서 도메인으로 접속이 안 될 때 — NAT reflection vs Split DNS

포트포워딩이 멀쩡히 되는데, 정작 집 안에서 같은 도메인(공인 IP)으로 접속하면 안 되는 경우가 있다. 버그가 아니라 NAT의 구조적인 한계다. 내부 클라이언트가 공인 IP로 보낸 패킷은 WAN 밖에서 들어온 게 아니라 포워딩 규칙에 안 걸리고, 억지로 걸리게 해도 서버의 응답이 pfSense를 거치지 않고 클라이언트로 직행해 버려 연결이 깨진다. 해법은 두 갈래다.

급하면 reflection도 방법이다 — 위 체크리스트에 적었듯 규칙 편집 화면이나 System > Advanced > Firewall & NAT에서 켜면 된다. 하지만 도메인으로 서비스한다면 나는 Split DNS를 권한다. 7편에서 설정한 DNS Resolver가 있으니 한 줄이면 된다. Services > DNS Resolver 화면 맨 아래 Host Overrides에서 Add를 누르고 Host(예: www), Domain(예: example.com), IP Address에 내부 서버 IP(192.168.10.20)를 넣고 Save → Apply 하면 끝이다.

✅ 확인 — 내부 PC에서 nslookup www.example.com을 쳤을 때 공인 IP가 아니라 192.168.10.20이 나오면 Split DNS가 동작하는 거다. 이제 안에서도 밖에서도 같은 도메인으로 접속된다.

이중 NAT — 홈랩의 흔한 벽

pfSense 앞에 통신사 공유기가 또 있으면 NAT가 두 겹이라, pfSense의 WAN이 공인 IP가 아니라 사설 IP를 받는다. 이러면 바깥에서 아무리 포워딩해도 들어올 수 없다. 통신사 장비를 브리지 모드로 돌리거나, 그 장비에서 pfSense로 다시 포워딩(또는 DMZ)해야 한다. WAN IP가 192.168.x거나 100.64.x(CGNAT)로 잡히면 이 상황을 의심하자.

자주 묻는 질문 (FAQ)

포트포워딩을 열면 위험하지 않나요?

외부에 노출되므로 꼭 필요한 포트만, 가능하면 VPN 뒤에 두는 게 안전합니다. 웹서비스는 리버스 프록시(24편)와 함께 쓰길 권합니다.

포트포워딩을 했는데 접속이 안 돼요.

NAT 규칙과 함께 생성되는 방화벽 허용 규칙이 있는지, 그리고 내부 서버가 실제로 그 포트를 열고 있는지 확인하세요.

포트포워딩이 안 될 때 무엇부터 확인해야 하나요?

Status > System Logs > Firewall에서 해당 트래픽이 보이는지부터 확인하세요. 로그에 아예 없으면 이중 NAT나 ISP 차단, 빨간 차단이면 NAT·방화벽 규칙, 초록 통과인데도 안 되면 서버 자체 방화벽 순서로 좁혀 가면 됩니다.

외부에서는 되는데 내부에서 도메인으로 접속이 안 돼요.

NAT reflection이 필요한 상황입니다. 규칙에서 Pure NAT를 켜도 되지만, DNS Resolver의 Host Overrides로 내부에서는 도메인이 내부 IP로 바로 풀리게 하는 Split DNS 방식이 더 깔끔해서 권장합니다.