이번 글에서는 OPNsense를 이용해 서로 다른 두 네트워크를 IPsec으로 연결했던 과정을 정리해보려고 합니다.
앞서 홈랩에는 Proxmox 위에 OPNsense를 올리고, 내부망을 구성했습니다.
그리고 WireGuard를 이용해 제 맥북에서 홈랩 내부망으로 접근할 수 있는 구조도 만들었습니다.
하지만 이번에 구성하려던 것은 개인 노트북에서 홈랩으로 들어가는 원격 접속이 아니었습니다.
한단계 더 나아가,
이번 목표는 서로 다른 두 장소의 내부 네트워크를 하나의 연결된 네트워크처럼 통신하게 만드는 것이었습니다.
제 홈랩 네트워크와 다른 장소의 네트워크를 IPsec Site-to-Site VPN으로 연결하는 작업이었습니다.
1. 왜 IPsec을 사용했는가
WireGuard는 개인 장비에서 홈랩 내부망으로 접속할 때 매우 편리했습니다.
예를 들어 제 맥북에서 WireGuard를 켜고,
OPNsense를 통해 Proxmox나 CML에 접근하는 구조에서는 WireGuard가 잘 맞았습니다.
하지만 이번에는 맥북 한 대가 아니라, 서로 다른 두 네트워크 전체를 연결해야 했습니다.
예를 들어 다음과 같은 구조입니다.
내 홈랩 내부망
→ 192.168.20.0/24
상대편 내부망
→ 192.168.10.0/24
이 두 네트워크가 서로 통신하려면 단순히 개인 VPN 클라이언트를 연결하는 것보다,
방화벽과 방화벽 사이에 Site-to-Site VPN을 구성하는 것이 더 자연스럽습니다.
그래서 OPNsense와 OPNsense 사이에 IPsec 터널을 구성하기로 했습니다.
2. IPsec이란?
IPsec은 네트워크와 네트워크 사이의 통신을 암호화해서 안전하게 연결하는 VPN 기술입니다.
쉽게 말하면 서로 떨어져 있는 두 내부망 사이에 암호화된 터널을 만드는 방식입니다.
예를 들어 서울에 있는 네트워크와 대전에 있는 네트워크가 있다고 가정하면, 두 네트워크는 인터넷을 통해 연결됩니다.
하지만 그냥 인터넷으로 통신하면 중간 구간에서 패킷이 노출될 수 있습니다.
IPsec은 이 구간을 암호화해서, 외부에서는 내용을 알 수 없도록 보호합니다.
정리하면 IPsec의 역할은 다음과 같습니다.
서로 다른 두 네트워크를 연결
인터넷 구간의 통신을 안전하게 암호화
지정한 내부망 대역끼리만 (LocalNetwork 처럼) 통신 허용
방화벽과 방화벽 사이의 Site-to-Site VPN 구성에 자주 사용
3. 전체 네트워크 설계
이번에 연결하려는 구조는 다음과 같았습니다.
Site A
→ 내 홈랩 OPNsense
→ 내부망 192.168.20.0/24
Site B
→ 상대편 OPNsense
→ 내부망 192.168.10.0/24
두 사이트는 각각 OPNsense를 사용하고 있고, 각자의 WAN은 인터넷에 연결되어 있습니다.
목표는 다음과 같습니다.
192.168.20.0/24 대역의 장비가 192.168.10.0/24 대역으로 접근 가능
192.168.10.0/24 대역의 장비가 192.168.20.0/24 대역으로 접근 가능
두 내부망이 IPsec 터널을 통해 서로 통신할 수 있게 만드는 것입니다.
구조를 단순하게 표현하면 다음과 같습니다.
192.168.20.0/24
→ Site A OPNsense
→ IPsec Tunnel
→ Site B OPNsense
→ 192.168.10.0/24
4. 설정 전 정리한 정보
IPsec을 설정하기 전에 양쪽 정보를 먼저 정리했습니다.
IPsec은 양쪽 설정이 서로 맞아야 터널이 정상적으로 올라옵니다.
그래서 다음 정보를 미리 정리했습니다.
Site A 정보
역할: 내 홈랩 OPNsense
WAN 주소: 공인 IP 또는 DDNS 주소
LAN 대역: 192.168.20.0/24
Site B 정보
역할: 상대편 OPNsense
WAN 주소: 공인 IP 또는 DDNS 주소
LAN 대역: 192.168.10.0/24
공통 정보
VPN 방식: IPsec Site-to-Site
인증 방식: Pre-Shared Key
IKE 버전: IKEv2
Local Network: 각 사이트의 내부망
Remote Network: 상대 사이트의 내부망
여기서 Pre-Shared Key는 양쪽 장비가 함께 사용하는 비밀키입니다.
쉽게 말하면 "우리끼리만 알고 있는 암호"입니다.
양쪽 OPNsense에 같은 PSK를 입력해야 IPsec 협상이 정상적으로 진행됩니다.
5. IPsec 설정에서 헷갈렸던 개념
IPsec을 처음 설정할 때 가장 헷갈렸던 부분은 Phase 1, Phase 2 또는 Connection, Child SA 같은 용어였습니다.
간단하게 정리하면 다음과 같습니다.
Phase 1 또는 IKE 설정
→ 두 방화벽이 서로를 인증하고, 암호화 통신을 시작하기 위한 기본 터널을 만드는 단계
Phase 2 또는 Child SA 설정
→ 실제로 어떤 내부망 대역끼리 통신할 것인지 정하는 단계
쉽게 말하면 Phase 1은 "너와 내가 안전하게 대화할 수 있는 상대가 맞는지 확인하는 단계"이고,
Phase 2는 "그 터널 안에 어떤 네트워크 트래픽을 태울 것인지 정하는 단계"입니다.
예를 들어 이번 구성에서는 다음과 같이 생각할 수 있습니다.
Phase 1
→ Site A OPNsense와 Site B OPNsense가 서로 IPsec 터널을 맺음
Phase 2
→ 192.168.20.0/24와 192.168.10.0/24 트래픽을 터널에 태움
이 둘을 구분하지 못하면 IPsec 설정이 매우 헷갈립니다.
터널 자체가 올라오는 것과, 내부망끼리 실제 통신이 되는 것은 다른 문제입니다.
추가로 IPsec에는 Policy-based 방식과 Route-based 방식이 있습니다.
Policy-based IPsec은 출발지와 목적지 네트워크를 기준으로 트래픽을 터널에 태우는 방식입니다.
예를 들어 192.168.20.0/24에서 192.168.10.0/24로 가는 트래픽이면
IPsec 터널을 사용하도록 정책을 정하는 구조입니다.
반대로 Route-based IPsec은 IPsec 터널을 하나의 가상 인터페이스처럼 만들고,
특정 목적지 대역으로 가는 경로를 라우팅으로 지정하는 방식입니다.
이번 구성에서는 연결할 네트워크가 192.168.20.0/24와 192.168.10.0/24로 명확하게 정해져 있었기 때문에
Policy-based 방식을 사용했습니다.
6. Site A OPNsense 설정
먼저 제 홈랩 OPNsense에서 IPsec 설정을 진행했습니다.
OPNsense 웹 관리 페이지에서 IPsec 메뉴로 이동한 뒤, 새로운 연결을 생성했습니다.
기본 방향은 다음과 같습니다.
Remote Gateway
→ 상대편 OPNsense의 WAN 주소
Local Network
→ 192.168.20.0/24
Remote Network
→ 192.168.10.0/24
Authentication
→ Pre-Shared Key
IKE Version
→ IKEv2
여기서 Remote Gateway는 상대편 OPNsense의 공인 IP 또는 DDNS 주소입니다.
Local Network는 내 쪽 내부망입니다.
Remote Network는 상대편 내부망입니다.
Site A 입장에서 보면 다음과 같습니다.
내부망: 192.168.20.0/24
상대망: 192.168.10.0/24


7. Site B OPNsense 설정
다음으로 Site B, 즉 상대편 OPNsense에서도 IPsec 설정을 진행합니다.
여기서 가장 중요한 점은 Site A와 반대로 입력해야 한다는 것입니다.
Site B 입장에서는 자신의 내부망이 192.168.10.0/24이고, 상대편 내부망이 192.168.20.0/24입니다.
Site B에서는 다음과 같이 설정해야 합니다.
Remote Gateway
→ Site A OPNsense의 WAN 주소
Local Network
→ 192.168.10.0/24
Remote Network
→ 192.168.20.0/24
Authentication
→ Site A와 동일한 Pre-Shared Key
IKE Version
→ Site A와 동일하게 IKEv2
정리하면 양쪽 Local과 Remote는 서로 반대로 들어가야 합니다.
Site A 기준
Local: 192.168.20.0/24
Remote: 192.168.10.0/24
Site B 기준
Local: 192.168.10.0/24
Remote: 192.168.20.0/24

8. WAN 방화벽 룰 설정
IPsec 터널이 맺어지려면 WAN 쪽에서 IPsec 관련 트래픽이 허용되어야 합니다.
IPsec에서 주로 사용하는 것은 다음과 같습니다.
UDP 500
→ IKE 협상에 사용
UDP 4500
→ NAT-T 환경에서 IPsec 통신에 사용
ESP
→ 실제 암호화된 IPsec 데이터 전달에 사용
여기서 헷갈렸던 부분은 ESP입니다.
ESP는 TCP나 UDP 포트 번호가 아닙니다.
ESP는 IP 프로토콜 번호 50을 사용하는 별도의 프로토콜입니다.
그래서 방화벽 룰에서 ESP를 열 때는 포트 번호 50을 여는 것이 아니라, 프로토콜을 ESP로 선택해야 합니다.
WAN에서 허용해야 할 대표적인 룰은 다음과 같습니다.
Protocol: UDP
Destination Port: 500
Protocol: UDP
Destination Port: 4500
Protocol: ESP
다만 실제 환경에서는 OPNsense IPsec 설정이나 자동 룰 생성 여부에 따라 필요한 룰 구성이 달라질 수 있으므로,
WAN에서 IPsec 트래픽이 막히지 않는지 확인하는 것이 중요합니다.

9. IPsec 인터페이스 방화벽 룰 설정
IPsec 터널이 올라왔다고 해서 내부망 통신이 무조건 되는 것은 아닙니다.
이 부분이 처음에 가장 헷갈렸습니다.
IPsec 설정에서 Local Network와 Remote Network를 지정하면,
해당 대역이 터널에 올라갈 대상이라는 뜻입니다.
하지만 방화벽 입장에서는 실제로 그 트래픽을 통과시켜도 되는지 별도로 판단합니다.
IPsec Child 설정은 "어떤 대역을 터널에 태울 것인가"이고, 방화벽 룰은 "그 트래픽을 통과시킬 것인가"입니다.
그래서 IPsec 인터페이스 또는 IPsec Rules 쪽에 허용 룰을 추가해야 합니다.
예시는 다음과 같습니다.
Site A 기준
Interface: IPsec
Source: 192.168.10.0/24
Destination: 192.168.20.0/24
Action: Pass
Site B 기준
Interface: IPsec
Source: 192.168.20.0/24
Destination: 192.168.10.0/24
Action: Pass

10. 터널 상태 확인
양쪽 설정을 마친 뒤 IPsec 터널 상태를 확인했습니다.
정상적으로 연결되면 IPsec 상태 화면에서 터널이 올라온 것을 확인할 수 있습니다.
여기서 중요한 것은 터널이 올라온 것과 내부망 통신이 되는 것은 구분해야 한다는 점입니다.
터널 상태가 Connected 또는 Established로 보인다면, 기본적인 IPsec 협상은 성공한 것입니다.
하지만 ping이나 웹 접속이 안 된다면 그 다음에는 라우팅, 방화벽 룰, 내부 장비의 응답 경로를 확인해야 합니다.

잘 올라와 있는 걸 확인 가능 했습니다.
11. 통신 테스트
터널이 올라온 뒤에는 실제 내부망끼리 통신이 되는지 테스트했습니다.
Site A 내부망에서 Site B 내부 장비로 ping을 보냅니다.
예시는 다음과 같습니다.
ping 192.168.10.1
또는 상대편 내부 서버 주소로 테스트할 수 있습니다.
ping 192.168.10.x

12. 최종 접속 흐름 정리
최종적으로 구성한 IPsec 흐름은 다음과 같습니다.
Site A 내부 장비
→ Site A OPNsense
→ IPsec Tunnel
→ Site B OPNsense
→ Site B 내부 장비
반대 방향도 동일합니다.
Site B 내부 장비
→ Site B OPNsense
→ IPsec Tunnel
→ Site A OPNsense
→ Site A 내부 장비
만약 WireGuard 클라이언트까지 IPsec 반대편으로 보내려면 다음 흐름도 가능합니다.
맥북
→ WireGuard
→ Site A OPNsense
→ IPsec Tunnel
→ Site B OPNsense
→ Site B 내부 장비
단, 이 경우에는 WireGuard 대역도 IPsec Child와 방화벽 룰에 포함되어야 합니다.
13. 마무리
이번 글에서는 OPNsense를 이용해 서로 다른 두 내부망을 IPsec Site-to-Site VPN으로 연결한 과정을 정리했습니다.
처음에는 단순히 양쪽 OPNsense에서 IPsec만 켜면 바로 통신될 줄 알았습니다.
하지만 실제로는
WAN 주소, 인증 방식, Phase 1, Phase 2, Child 설정, 방화벽 룰, 라우팅, NAT-T, ESP까지
여러 요소가 함께 맞아야 정상적으로 동작했습니다.
이번 구성의 핵심은 다음과 같습니다.
1. IPsec은 서로 다른 두 내부망을 암호화된 터널로 연결하는 기술
2. Phase 1은 터널 협상과 인증 단계
3. Phase 2 또는 Child 설정은 어떤 내부망 대역을 터널에 태울지 정하는 단계
4. Site A와 Site B의 Local Network와 Remote Network는 서로 반대로 설정해야 함
5. WAN에서는 UDP 500, UDP 4500, ESP 개념을 이해해야 함
6. ESP는 포트가 아니라 IP 프로토콜 번호 50에 해당하는 별도 프로토콜
7. 터널이 올라오는 것과 내부망 통신이 되는 것은 다른 문제
8. IPsec 터널이 올라와도 방화벽 룰이 없으면 내부망 통신이 막힐 수 있음
9. WireGuard 클라이언트가 IPsec 반대편까지 가려면 WireGuard 대역도 IPsec Child와 방화벽 룰에 포함해야 함
10. 문제 발생 시 IPsec 상태, 로그, 방화벽 로그, ping, traceroute를 단계적으로 확인해야 함
결국 IPsec 설정에서 가장 중요한 것은
"터널을 맺는 설정"과 "터널 안에 어떤 트래픽을 통과시킬지" 를 구분하는 것이었습니다.
IPsec 연결 자체는 Phase 1에서 만들어지고,
실제 내부망 대역 통신은 Phase 2 또는 Child 설정과 방화벽 룰을 통해 완성됩니다.
이 구조를 이해하고 나니
터널은 올라왔는데 통신이 안 되는 문제도 훨씬 차분하게 분석할 수 있었고 해결 할 수 있었습니다.
이렇게 해서 OPNsense 기반 홈랩과 상대편 네트워크를
IPsec Site-to-Site VPN으로 연결하는 작업을 마무리했습니다.
'Network' 카테고리의 다른 글
| MTR로 살펴보는 해외 웹사이트 네트워크 지연과 라우팅 경로 분석 (0) | 2026.06.01 |
|---|---|
| 케이블을 하나하나 따라가며 랩실 랙 네트워크 구조 파악하기 (0) | 2026.05.28 |
| BGP Hijacking (0) | 2026.05.21 |
| CML Teleport에 등록하기 (0) | 2026.05.15 |
| AI 바이브 코딩으로 구현한 TCP/UDP 영상 스트리밍 프로토콜 비교 분석 (0) | 2026.05.02 |