OPNsense 에서 기존 레거시 VPN 흔적을 정리한 뒤 OpenVPN 을 새로 구성하고, 원격 클라이언트가 <LAN1_SUBNET> · <LAN2_SUBNET> 에 안정적으로 접근하도록 만드는 실무형 가이드다. 실제로 수행한 정리·재구축 흐름을 기준으로 정리했다. VPN 기술 자체의 개념과 비교는 VPN 문서를 본다.
| 항목 | 값 |
|---|---|
| OPNsense | 26.1.6-amd64 (2026년 테스트 됨). 현행 릴리스는 26.7 계열[1] |
| FreeBSD | 14.3-RELEASE-p10 |
| OpenSSL | 3.0.20 |
| WAN | igc3 |
| LAN1 | igc0 → <LAN1_SUBNET> 게이트웨이 |
| LAN2 | igc1 → <LAN2_SUBNET> 게이트웨이 |
시스템은 24 이전 버전에서 업그레이드된 이력이 있어 레거시 OpenVPN · WireGuard · IPsec · mpd 흔적이 남아 있을 수 있었다. self-signed CA 와 서버 인증서 기반으로 운용한다.
이 환경은 레거시 VPN 흔적이 남아 있었고, 사용자 · 인증서 · 정책 기반 운영 체계를 먼저 안정화할 필요가 있었다. OpenVPN 은 OPNsense 에서 인증서 중심 운영, 사용자별 통제, CRL, Client Export, OTP 확장성이 좋아 첫 번째 재구성 대상으로 적합했다. Source Source
업그레이드된 시스템은 구버전 pseudo-interface, 서비스 잔재, 비활성 섹션이 남을 수 있다. 재구성 전에 상태를 깨끗하게 만들어야 장애 원인 분리가 쉬워진다.
config.xml 에서 잔재가 없는지 확인한다레거시 VPN 흔적과 비활성 인스턴스 · 파일 · 인터페이스를 식별한다. 예시 파일명은 audit_vpn_legacy_all.sh 이며 read-only 로 설정을 바꾸지 않는다.
ifconfig 기반 VPN-like 인터페이스 확인/conf/config.xml 내 OpenVPN · WireGuard · IPsec · mpd 마커 검사sh audit_vpn_legacy_all.sh
어떤 OpenVPN · WireGuard · IPsec · mpd 섹션과 파일이 제거될지 실제 적용 전에 확인한다.
sh cleanup_unused_vpn_artifacts.sh
레거시 VPN 섹션을 실제로 제거한다. /conf/config.xml 백업이 필수이고, 실제 적용 전 preview 검토가 필요하다.
APPLY=YES PURGE_OPENVPN=YES PURGE_WIREGUARD=YES PURGE_IPSEC=YES PURGE_MPD=YES sh cleanup_unused_vpn_artifacts.sh
정리 후 OpenVPN · WireGuard · IPsec · mpd 흔적이 남지 않았는지 확인한다.
ifconfig -l | grep -E 'wg|ovpn|tun|tap|enc'
grep -niE 'openvpn|wireguard|ipsec|mpd' /conf/config.xml
enc0 만 남는 것은 정상일 수 있다. OpenVPN · WireGuard 관련 활성 흔적은 없어야 한다.
OpenVPN 은 PKI 기반 신뢰 모델을 사용한다. CA 가 서버 · 클라이언트 인증서를 발급하고, 인증서 및 사용자 매핑을 통해 접속 권한을 통제한다. 인증서 기반 운영은 사용자 추적, 폐기, 재발급, 감사 측면에서 유리하다. Source
<CA_NAME> 확인 또는 생성<SERVER_CERT_NAME> 준비<CLIENT_USER> 생성<CLIENT_CERT_NAME> 발급VPN → OpenVPN → Instances → Add 에서 만든다.
| 항목 | 값 |
|---|---|
| Role | Server |
| Protocol | UDP (IPv4) |
| Port | <OPENVPN_PORT> |
| Interface Type | TUN |
| Topology | subnet |
| Server (IPv4) | <OPENVPN_TUNNEL_NET> |
| Certificate | <SERVER_CERT_NAME> |
| TLS Static Key | 생성 후 선택 |
| Authentication | Local Database |
| Strict User/CN Matching | 초기 테스트 후 Yes 권장 |
| Local Networks | <LAN1_SUBNET>, <LAN2_SUBNET> |
| Redirect Gateway | 내부망 전용이면 비움 |
Firewall → Rules → WAN 에서 UDP <OPENVPN_PORT> 를 허용한다. 인터넷에서 OpenVPN 서버 포트 접근을 허용해야 한다. Source
초기 검증용으로 OpenVPN net -> any 또는 최소한 <LAN1_SUBNET>, <LAN2_SUBNET> 허용 규칙을 만든다. 터널 내부 트래픽이 내부 자원에 도달할 수 있어야 한다.
OpenVPN assigned interface 를 만들면 reply-to 가 붙어 Road Warrior 응답이 깨질 수 있다. 초기 구성은 OpenVPN 탭 규칙 위주가 안전하다. Source
VPN → OpenVPN → Client Export 에서 내보낸다. 클라이언트 배포를 표준화하고 사용자별 설정 혼선을 줄인다. Source
<WAN_PUBLIC_IP> 또는 FQDN<CLIENT_USER> 용 .ovpn export이전 작업에서 다음 경고를 관찰했다.
터널 내부 패킷 이상, 설정 mismatch, MTU · 클라이언트 문제 가능성을 우선 의심한다. 인증 자체는 일부 진행되었을 수 있으므로 서버 완전 불능과는 구분해야 한다.
치명 오류보다는 transport family 추론 경고에 가까우며, 명시적 IPv4 설정으로 줄일 수 있다.
즉시 실패 원인은 아닐 수 있으나 세션 안정화를 위해 keepalive 설정이 권장된다.
사용자명과 인증서 CN 일치를 요구하고, 사용자별 인증서를 분리한다. Source
System → Trust → Authorities 에서 CRL 을 생성해 OpenVPN 인스턴스에 연결한다. 분실 · 퇴사 · 유출 시 즉시 인증서를 차단한다. Source
예: keepalive 10 60. 죽은 세션을 더 빨리 정리한다.
초기 검증 후에는 OpenVPN net -> any 를 축소하고, 필요한 경우 <LAN1_SUBNET>, <LAN2_SUBNET> 만 허용한다.
OpenVPN hardening 문서는 tls-auth HMAC 서명을 통한 스캔 · DoS 완화와 조기 드롭 이점을 설명한다. OPNsense 인스턴스 구성에서는 TLS static key 가 유사한 hardening 포인트가 된다. Source
<LAN1_SUBNET> 게이트웨이 ping 가능 여부<LAN2_SUBNET> 게이트웨이 ping 가능 여부config.xml 백업이 환경에서 OpenVPN 은 레거시 흔적 제거 후 가장 안정적으로 재구축 가능한 첫 번째 VPN 이었다. 사용자 · 인증서 · 정책 기반 운영을 먼저 안정화하고, 이후 WireGuard 를 병행 설계하는 순서가 운영상 합리적이다.
최신 버전 26.7.3 — 2026-09-20 확인. https://docs.opnsense.org/releases/CE_26.7.html ↩︎