[네트워크 보안 트러블슈팅] OPNsense/pfSense 장애 진단 가이드

홈랩이나 소규모 사무실에서 OPNsense/pfSense를 메인 방화벽으로 올려두면, 평소에는 정말 든든합니다. 근데 한 번 꼬이기 시작하면 이야기가 달라지죠. 인터넷은 살아 있는 것 같은데 특정 서비스만 안 되고, VPN은 붙었다 끊겼다 하고, 내부 DNS는 멀쩡한데 외부 접속만 실패하고요. 이런 상황에서 제일 무서운 건 설정을 이것저것 바꾸다가 문제를 더 키우는 겁니다. 그래서 오늘은 네트워크 보안 트러블슈팅 관점에서 OPNsense 문제 해결, pfSense 오류 확인, 방화벽 디버깅 순서를 어떻게 잡아야 하는지 제가 실제로 쓰는 방식대로 정리해보겠습니다.

저도 처음엔 장애가 나면 로그부터 무작정 뒤졌었는데요. 실제로 써보니까 순서가 더 중요하더라고요. 물리 계층 → IP 계층 → 라우팅 → 방화벽 룰 → NAT → DNS → 애플리케이션 순서로 좁혀가면 생각보다 빨리 답이 나옵니다. 삽질 좀 했습니다 ㅎㅎ 그래서 이 글은 이론보다도, 막혔을 때 어디부터 봐야 하는지에 집중해보겠습니다.

홈랩 네트워크에서 OPNsense/pfSense가 WAN, LAN, VLAN, VPN 사이에서 어떤 위치를 차지하는지 한눈에 보여주는 개요 이미지입니다.

1. OPNsense/pfSense 장애가 유독 헷갈리는 이유

방화벽 장비의 문제는 겉으로 보이는 증상과 실제 원인이 다른 경우가 많습니다. 예를 들어 사용자는 “인터넷이 안 된다”고 말하지만, 실제로는 DNS Resolver(디엔에스 리졸버, 이름 해석기)만 죽어 있는 경우가 있거든요. 반대로 ping은 되는데 웹만 안 열리면 TLS, MTU, 정책 기반 라우팅(Policy-based Routing) 문제일 수도 있습니다.

• 증상은 단순한데 원인은 여러 계층에 걸쳐 있을 수 있습니다.
• 룰(Rule), NAT, 게이트웨이(Gateway), DNS가 함께 얽히면 체감 난도가 확 올라갑니다.
• 특히 홈랩 네트워크에서는 VLAN, WireGuard/OpenVPN, Reverse Proxy까지 얹히면서 더 복잡해집니다.

혹시 이런 경험 있으신가요? 어제까지 잘 되던 포트 포워딩(Port Forwarding, 포트 전달)이 오늘 갑자기 안 됩니다. 근데 내부에서는 접속이 되고, 외부에서는 안 되고, 로그에는 딱히 에러도 안 보입니다. 이런 게 전형적인 방화벽 디버깅 케이스입니다.

2. 계층별 문제 진단: 어디서 막히는지 먼저 파악하세요

쉽게 말해 네트워크 보안 트러블슈팅은 “패킷(Packet, 네트워크 데이터 조각)이 어디까지 갔는지”를 찾는 과정입니다. 이걸 감으로 하면 오래 걸리고, 체크리스트로 하면 빨라집니다.

여기서 중요한 포인트! 네트워크 보안 트러블슈팅은 “인터넷 됨/안 됨”으로 판단하면 안 됩니다. 반드시 출발지, 목적지, 포트, 프로토콜, 인터페이스, 시간대를 같이 적어두세요. 예를 들면 “VLAN 30의 192.168.30.10에서 TCP 443으로 외부 접속 실패, 오전 9시부터 시작” 이런 식입니다. 이 한 줄이 디버깅 속도를 정말 많이 올려줍니다.

3. 실제로 하는 1차 점검 루틴 (방화벽 디버깅 기초)

장애가 나면 저는 설정 화면부터 안 들어갑니다. 먼저 증상을 최소 단위로 쪼갭니다. 아래 순서가 기본입니다.

1. 문제를 재현합니다. 어떤 클라이언트에서, 어떤 목적지로, 어떤 포트가 실패하는지 확인합니다.
2. 게이트웨이 상태를 봅니다. WAN이 죽었는지, 특정 경로만 죽었는지 먼저 가릅니다.
3. 클라이언트에서 기본 테스트를 합니다. IP ping, DNS 조회, TCP 포트 접속을 나눠봅니다.
4. 방화벽 로그와 패킷 캡처를 같이 봅니다. 로그만 믿으면 놓치는 케이스가 꽤 있습니다.
5. 최근 변경사항을 떠올립니다. 룰 추가, VLAN 수정, DHCP 변경, DNS 설정 변경이 있었는지요.

실제로 써보니까 장애 원인의 절반 이상은 “최근 내가 바꾼 것”에서 나오더라고요. 저도 처음엔 인정하기 싫었는데, 결국 제 설정이 원인인 경우가 많았습니다.

3-1. 클라이언트에서 먼저 보는 명령어

ping -c 4 192.168.1.1
ping -c 4 1.1.1.1
nslookup example.com
traceroute 1.1.1.1
nc -vz example.com 443

이 다섯 줄만 해도 꽤 많은 정보가 나옵니다. 첫 번째 ping이 실패하면 로컬 게이트웨이까지 못 가는 거고, 두 번째만 실패하면 WAN 또는 라우팅 문제일 가능성이 큽니다. nslookup이 실패하면 DNS 쪽을 보면 되고요. nc(netcat, 네트워크 디버깅 도구)로 443 포트 테스트까지 해보면 L3/L4를 빠르게 나눌 수 있습니다.

3-2. 방화벽 자체에서 확인하는 명령어

ifconfig
netstat -rn
pfctl -sr
pfctl -ss
tcpdump -ni em0 host 1.1.1.1
tcpdump -ni em1 host 192.168.1.10

인터페이스 이름은 환경마다 다르니 em0, em1은 실제 NIC 이름으로 바꿔서 보시면 됩니다. pfctl -sr은 로드된 필터 룰, pfctl -ss는 현재 상태 테이블(State Table, 연결 상태 추적 정보)을 보여줍니다. 상태 테이블에 세션이 생기지 않으면 룰 또는 경로 문제를 의심해볼 수 있습니다.

게이트웨이 상태, 인터페이스 상태, 실시간 로그, 패킷 캡처 흐름을 한 화면에서 정리한 설정 화면 예시 이미지입니다.

4. [방화벽 디버깅] 규칙은 맞는데 트래픽이 안 지나갈 때

이건 정말 자주 봅니다. 특히 OPNsense 문제 해결이나 pfSense 오류 문의에서 많이 나오는 패턴이 “Allow 룰을 넣었는데 왜 안 되죠?”입니다. 근데 자세히 보면 인터페이스 방향을 반대로 이해한 경우가 많아요.

pf 기반 방화벽은 기본적으로 들어오는 방향(Inbound) 기준으로 룰을 평가합니다. 예를 들어 VLAN 20에서 인터넷으로 나가는 트래픽을 허용하려면, WAN이 아니라 VLAN 20 인터페이스에 룰이 있어야 하는 경우가 대부분입니다. 저도 예전에 WAN 쪽에만 룰을 만지다가 한참 헤맸습니다.

• 룰은 어느 인터페이스로 들어오는가 기준으로 생각합니다.
• 상단 룰이 먼저 매칭되므로 룰 순서를 꼭 확인합니다.
• Floating Rule(플로팅 룰, 여러 인터페이스 공통 적용 룰)을 쓰는 경우 quick 옵션 해석도 주의가 필요합니다.

점검 포인트

1. 문제가 발생한 클라이언트가 어느 인터페이스에 속하는지 확인합니다.
2. 그 인터페이스의 규칙에서 목적지/포트/프로토콜을 다시 봅니다.
3. 상단에 더 넓은 차단 룰이 먼저 있는지 확인합니다.
4. Live View에서 실제 차단 로그가 찍히는지 봅니다.
5. 상태 테이블을 초기화해야 하는 상황인지 검토합니다.

pfctl -k 192.168.20.10
pfctl -Fs

첫 줄은 특정 호스트 관련 상태를 끊고, 두 번째는 상태 테이블 전체를 비우는 명령입니다. 다만 운영 중인 환경에서는 전체 상태 초기화가 영향이 크니 조심하셔야 합니다. 저는 홈랩에서 테스트하다가 가족들 인터넷까지 잠깐 끊겨서 혼난 적도 있습니다 ㅎㅎ

5. [pfSense 오류 해결] NAT와 포트 포워딩이 미묘하게 꼬일 때

포트 포워딩(Port Forwarding, 외부 포트를 내부 서버로 전달) 장애도 단골입니다. 외부에서 내부 서비스로 들어오게 만들었는데 접속이 안 되면, 단순히 포워드 규칙만 볼 게 아니라 연관된 방화벽 규칙, 대상 IP, 내부 서버의 리스닝 상태, 헤어핀 NAT(Hairpin NAT, 내부에서 공인 주소로 다시 접근하는 구조)까지 같이 확인해야 합니다.

제가 직접 해보니 여기서 제일 많이 헷갈리는 건 두 가지였습니다. 첫째, 내부 서버 서비스가 실제로 해당 포트에서 리스닝(listening, 접속 대기) 중인지 확인하지 않고 방화벽만 보는 경우. 둘째, 내부에서 공인 IP로 테스트하고 “안 된다”고 판단하는 경우입니다. 이건 NAT Reflection(내트 리플렉션, 내부에서 외부 주소로 우회 접속) 정책이 없으면 정상입니다.

sockstat -4 -l
nc -vz 192.168.10.20 443
tcpdump -ni wan port 443
tcpdump -ni lan host 192.168.10.20 and port 443

이렇게 WAN과 LAN 양쪽에서 같은 포트를 잡아보면, 패킷이 들어오기만 하고 내부로 못 나가는지, 아예 바깥에서 안 들어오는지 분리할 수 있습니다. 방화벽 디버깅에서 패킷 캡처는 정말 강력합니다. 로그에는 안 보여도 캡처에는 보이는 경우가 꽤 있거든요.

자주 실수하는 NAT 체크리스트

• 포트 포워딩 대상 IP가 DHCP로 바뀌지 않았는지 확인
• 자동 생성된 연동 룰이 실제로 활성 상태인지 확인
• Outbound NAT(아웃바운드 NAT)가 수동 모드일 때 필요한 규칙이 빠지지 않았는지 확인
• Split DNS 또는 NAT Reflection 정책이 환경에 맞는지 확인

WAN에서는 패킷이 보이는데 LAN에서는 사라지는 상황, 또는 양쪽 모두 보이는 상황을 비교하는 패킷 캡처 예시 이미지입니다.

6. [홈랩 네트워크 보안] DNS 문제를 방화벽 장애로 착각할 때

이건 생각보다 더 많습니다. 사용자는 “인터넷이 안 된다”고 느끼는데, 실제로는 1.1.1.1 같은 IP ping은 잘 되고 도메인만 안 풀리는 경우죠. 그럼 방화벽 디버깅보다 DNS부터 봐야 합니다.

OPNsense/pfSense에서는 보통 DNS Resolver나 DNS Forwarder 역할을 방화벽이 맡습니다. 그래서 이 서비스가 꼬이면 전체 장애처럼 체감됩니다. 특히 홈랩 네트워크에서 내부 도메인, 광고 차단 DNS, 로컬 호스트 오버라이드(Host Override)까지 쓰고 있으면 더 복잡해집니다.

drill example.com
drill @127.0.0.1 example.com
drill @1.1.1.1 example.com

같은 질의를 로컬 리졸버와 외부 공개 DNS에 각각 던져보면 차이를 바로 볼 수 있습니다. 로컬만 실패하면 방화벽 내 DNS 서비스 문제일 가능성이 높고, 둘 다 실패하면 WAN 또는 업스트림 문제일 수 있습니다.

네트워크 보안 트러블슈팅에서 DNS는 별도 축으로 다뤄야 합니다. 왜냐하면 이름 해석이 안 되면 사용자는 모든 서비스가 죽은 것처럼 느끼기 때문입니다. 저도 예전에 Unbound 계열 설정을 건드린 뒤 내부 서비스가 전부 죽은 줄 알고 한참 헤맸는데, 결국 DNS 오버라이드 한 줄이 문제였던 적이 있습니다.

7. 로그와 패킷 캡처는 같이 봐야 정확합니다

로그(Log, 기록)는 왜 차단됐는지 알려주고, 패킷 캡처(Packet Capture)는 어디까지 갔는지 보여줍니다. 둘 중 하나만 보면 반쪽짜리 진단이 되기 쉽습니다. 특히 pfSense 오류를 좁혀갈 때는 상태 테이블과 캡처를 같이 보는 습관이 중요합니다.

제가 자주 보는 항목

• Live firewall log에서 차단 인터페이스와 규칙 정보
• Gateway 모니터링 상태와 지연/손실 변화
• DHCP Lease 변동 여부
• ARP 테이블 이상 여부
• 상태 테이블에 세션이 생성되는지 여부

arp -an
netstat -rn
pfctl -ss | grep 192.168.30.10

특정 클라이언트 기준으로 세션이 생성되는지 보는 것만으로도, 룰 매칭 이후까지는 갔는지 판단할 수 있습니다. 상태가 생기는데 응답이 없으면 반대 방향 경로, 업스트림 필터링, 서버 응답 문제 쪽으로 시선을 돌려야 합니다.

여기서 팁 하나. 장애가 반복되면 체크리스트를 템플릿으로 만들어두세요.

incident_note:
  source_ip: 192.168.30.10
  source_vlan: vlan30
  destination: example.com:443
  protocol: tcp
  first_seen: "09:10 UTC"
  last_change:
    - "Added VLAN rule"
    - "Modified DNS override"
  symptoms:
    - "Ping gateway success"
    - "Ping public IP failed"
    - "DNS lookup timeout"

이런 식으로 적어두면 다음 삽질을 줄일 수 있습니다. 드디어 됐다! 하는 순간에 원인을 안 적어두면, 다음 달에 똑같이 다시 헤매게 되더라고요.

장애 해결 후 ping, DNS 조회, 상태 테이블, 서비스 접속이 모두 정상으로 돌아온 결과를 보여주는 검증 이미지입니다.

8. 검증은 반드시 단계별로 해야 합니다

설정을 고친 뒤 바로 “이제 됩니다”라고 끝내면 안 됩니다. 최소한 아래 항목은 다시 확인해야 합니다.

1. 클라이언트에서 게이트웨이 ping 성공
2. 공인 IP ping 또는 traceroute 정상
3. DNS 조회 정상
4. 문제였던 포트 접속 정상
5. 방화벽 로그에 더 이상 의도치 않은 차단 없음
6. 다른 VLAN 또는 다른 클라이언트에 부작용 없음

특히 마지막이 중요합니다. OPNsense 문제 해결을 하다가 특정 대역만 살리고 다른 대역을 죽여버리는 경우가 의외로 많거든요. 그래서 저는 항상 “원래 안 되던 것”뿐 아니라 “원래 되던 것”도 같이 확인합니다. 이게 진짜 실무적인 검증입니다.

간단한 결과 확인 예시

ping -c 2 192.168.1.1
ping -c 2 1.1.1.1
nslookup example.com
curl -I https://example.com

curl까지 성공하면 적어도 웹 계층에서의 기본 통신은 확인한 셈입니다. 물론 실제 서비스가 API, 게임, VPN, VoIP라면 그 프로토콜 특성에 맞는 추가 검증이 필요합니다.

9. 정리: 네트워크 보안 트러블슈팅의 핵심은 순서입니다

오늘 내용의 핵심은 단순합니다. 네트워크 보안 트러블슈팅은 센스보다 순서가 중요합니다. 물리, IP, 라우팅, 룰, NAT, DNS, 애플리케이션 순서로 좁혀가면 됩니다. OPNsense/pfSense는 강력한 만큼, 설정 요소가 많아서 겉증상에 속기 쉽습니다. 그래서 더더욱 “패킷이 어디까지 갔는가”를 기준으로 봐야 하죠.

제가 실제로 오래 써보니, 가장 시간을 아껴주는 건 세 가지였습니다. 첫째, 증상을 문장으로 정확히 적기. 둘째, 로그와 캡처를 같이 보기. 셋째, 최근 변경사항부터 의심하기. 이 세 가지만 지켜도 홈랩 네트워크 장애 대응 속도가 꽤 달라집니다.

이전 글에서 VLAN 분리와 기본 방화벽 정책을 다뤘다면, 이번 글은 그 위에서 장애를 푸는 방법에 가까웠습니다. 다음 글에서는 WireGuard VPN과 정책 기반 라우팅이 섞일 때 생기는 디버깅 포인트도 따로 다뤄볼 예정입니다. 그쪽은 진짜 한 번 꼬이면 오래 갑니다.

장애 진단 순서, 자주 나오는 원인, 추천 도구를 한 장으로 요약한 인포그래픽 이미지입니다.

자주 묻는 질문

Q1. ping은 되는데 웹만 안 열리면 방화벽 문제인가요?

반드시 그렇진 않습니다. TCP 80/443 차단, DNS 문제, MTU 문제, 서버 리스닝 문제, TLS 이슈까지 모두 가능성이 있습니다. ping 성공만으로 방화벽 정상이라고 보시면 안 됩니다.

Q2. 포트 포워딩이 외부에서는 안 되고 내부에서는 되면요?

내부 테스트가 사설 IP 기준인지, 공인 IP 기준인지 먼저 구분하셔야 합니다. NAT Reflection이나 Split DNS 구성이 없으면 내부에서 공인 주소 테스트는 실패할 수 있습니다.

Q3. 로그에 아무것도 안 찍히면 어떻게 하나요?

그럴 때일수록 패킷 캡처가 중요합니다. 아예 방화벽까지 패킷이 도달하지 않는지, 도달은 하는데 다른 인터페이스로 안 나가는지부터 확인해보세요.