Masalah Paling Umum di VPN Site-to-Site
VPN Site-to-Site MikroTik sudah connected. Di log muncul status "established". Tapi saat kamu coba ping dari LAN kantor pusat ke LAN cabang — tidak ada respons. Request Timeout.
Situasi ini sangat umum terjadi setelah setup awal VPN, dan hampir selalu disebabkan oleh 2-3 kesalahan yang sama.
Artikel ini mencakup troubleshooting step-by-step dengan urutan yang benar — dari yang paling sering terjadi ke yang paling jarang.
Topologi yang Diasumsikan
LAN Kantor Pusat (192.168.1.0/24)
│
[MikroTik Pusat] ─── VPN Tunnel ─── [MikroTik Cabang]
Public: 203.0.113.1 Public: 198.51.100.1
│ │
└── Switch ── PC └── Switch ── PC
(192.168.2.0/24)
Urutan Troubleshooting
Jangan loncat-loncat. Ikuti urutan ini — Layer 3 dulu, baru Layer 7.
1. Cek Status VPN
Masalah: kamu melihat "connected" di WinBox, tapi perlu verifikasi detail.
/ip ipsec remote-peers print
/ip ipsec active-peers print
/ip ipsec policy print
Perhatikan:
state=established— harus di kedua sisisa-count— minimal 1 (Security Association)src-addressdandst-address— pastikan subnet benar
Kalau state connecting atau created tapi tidak established, masalahnya di Phase 1 atau Phase 2 IKE. Loncat ke bagian bawah untuk troubleshooting koneksi VPN.
2. Bisa Ping Antar IP Public Router?
Ping dari router pusat ke public IP router cabang. Ini tes konektivitas dasar Layer 3.
/ping 198.51.100.1 src-address=203.0.113.1
Kalau tidak bisa ping, masalahnya bukan di VPN — tapi di koneksi internet atau firewall yang memblokir port VPN (UDP 500, UDP 4500, ESP protocol).
3. Routing: LAN Cabang Ada di Routing Table?
Masalah paling umum: VPN connected tapi tidak ada route ke subnet remote.
Cek di router pusat:
/ip route print where dst-address~"192.168.2"
Harusnya ada route seperti:
Dst: 192.168.2.0/24 Gateway: 198.51.100.1 (atau via interface VPN)
Kalau tidak ada, tambahkan:
/ip route add dst-address=192.168.2.0/24 gateway=198.51.100.1
Atau kalau pakai IPIP/GRE tunnel, gateway bisa pakai IP tunnel interface.
Lakukan hal yang sama di router cabang untuk subnet pusat (192.168.1.0/24).
4. Policy IPSec: Subnet di Policy Sudah Benar?
Masalah: policy IPSec mendefinisikan subnet mana yang dienkapsulasi VPN. Kalau subnet policy dan subnet di route berbeda, traffic tidak akan masuk tunnel.
/ip ipsec policy print
Pastikan:
src-address=192.168.1.0/24 dst-address=192.168.2.0/24
Di kedua router harus simetris (terbalik di router cabang).
Kalau policy benar tapi traffic tetap tidak jalan, cek apakah ada policy lain yang overlap. Policy IPSec dieksekusi berdasarkan urutan — policy pertama yang match akan dipakai.
5. NAT — Traffic ke VPN Tidak Kena Masquerade
Masalah klasik: traffic dari LAN pusat ke LAN cabang melewati rule masquerade, source IP diubah jadi IP public router. Akibatnya: traffic tidak masuk policy IPSec (karena source IP bukan dari subnet LAN).
Cek NAT rule:
/ip firewall nat print
Pastikan traffic ke subnet remote TIDAK kena masquerade.
Tambahkan accept rule SEBELUM masquerade rule:
/ip firewall nat add chain=srcnat src-address=192.168.1.0/24 dst-address=192.168.2.0/24 action=accept place-before=0
Ini memastikan traffic antar LAN tidak di-NAT. Cek lagi ping dari PC pusat ke PC cabang.
6. Firewall Filter: Traffic Antar LAN Diizinkan?
Masalah: rule forward chain memblokir traffic dari subnet pusat ke subnet cabang.
/ip firewall filter print chain=forward
Cari rule yang action=drop atau action=reject. Pastikan traffic antar subnet diizinkan SEBELUM rule drop.
Tambahkan di posisi atas:
/ip firewall filter add chain=forward src-address=192.168.1.0/24 dst-address=192.168.2.0/24 action=accept place-before=0
/ip firewall filter add chain=forward src-address=192.168.2.0/24 dst-address=192.168.1.0/24 action=accept place-before=1
7. Tes Traceroute — Diagnosa di Titik Mana Putus
Dari PC di kantor pusat (192.168.1.100):
tracert 192.168.2.100
Di Linux/Mac:
traceroute 192.168.2.100
Output akan menunjukkan di hop ke berapa koneksi berhenti:
- Hop 1: gateway LAN — OK
- Hop 2: IP internal router cabang — berarti traffic sudah lewat tunnel, masalah di LAN cabang (ARP, switch, atau PC tujuan mati)
- Hop 2: timeout — traffic tidak masuk tunnel (routing atau policy)
Troubleshooting Koneksi VPN yang Tidak Established
Kalau di langkah 1 kamu dapat state connecting:
Cek Log IPSec
/log print where topics~"ipsec"
Error umum:
- no proposal chosen: parameter enkripsi tidak cocok di kedua sisi (algorithm, hash, DH group). Samakan di kedua router.
- peer not responding: port UDP 500/4500 atau ESP protocol diblokir (firewall ISP, NAT di depan MikroTik)
- invalid ID: mode identification tidak cocok (main vs aggressive, FQDN vs address)
Cek Port Terbuka
Dari luar (laptop dengan koneksi internet berbeda):
nmap -sU -p 500,4500 203.0.113.1
Kalau port UDP 500 dan 4500 "filtered", ISP atau firewall depan MikroTik memblokirnya.
NAT-Traversal
Kalau salah satu MikroTik di belakang NAT (IP publik bukan di interface router, tapi di modem ISP), aktifkan NAT-T:
/ip ipsec peer set 0 nat-traversal=yes
Takeaway
Urutan troubleshooting VPN Site-to-Site yang benar:
- Status IPSec — established?
- Ping IP public — koneksi dasar jalan?
- Route table — ada route ke subnet remote?
- IPSec policy — subnet benar? Tidak ada policy overlap?
- NAT — traffic ke remote tidak kena masquerade?
- Firewall filter — traffic antar LAN diizinkan di forward chain?
- Traceroute — putus di titik mana?
Dalam 90% kasus, masalah ada di langkah 3, 5, atau 6. Sisanya masalah koneksi (NAT traversal, port block ISP, atau parameter IPSec tidak cocok).