OVPN Mikhmon Disconnect & IP Pool Overlap di ROS 7

Semua client RT/RW net tiba-tiba tidak stabil — internet putus-nyambung tanpa alasan jelas, padahal PPPoE semua terlihat connected di WinBox. Ini adalah skenario yang membingungkan banyak admin jaringan pemula maupun berpengalaman. Artikel ini mendokumentasikan kasus nyata dari sebuah jaringan RT/RW net dengan 26 client, RouterOS 7.16.1 pada RB450Gx4, yang berhasil di-resolve setelah analisa mendalam dari ARP table, IP pool, hingga OVPN log.

Disclaimer: CekIPSaya tidak diendorse, disponsori, atau berafiliasi dengan ISP, provider, atau brand pihak ketiga manapun yang disebutkan dalam artikel ini. Pembahasan disusun secara independen berdasarkan data publik dan pengalaman pengguna — tujuan kami murni edukasi. Semua merek dagang adalah milik pemegang hak masing-masing.

📋 Spesifikasi jaringan kasus ini: MikroTik RB450Gx4, RouterOS 7.16.1, 26 client PPPoE + voucher hotspot, Mikhmon sebagai manajemen hotspot via OVPN tunnel, upstream IndiHome 200Mbps.

Gejala: Internet Tidak Stabil di Semua Client Termasuk Voucher

Gejala yang dilaporkan: semua client — baik PPPoE maupun voucher hotspot — mengalami koneksi intermittent. Kadang bisa browsing, kadang tidak. Yang membingungkan, saat dicek di WinBox semua PPPoE session statusnya Connected. Tidak ada yang disconnect. Tapi client tetap ngeluh.

Gejala	Yang Dicurigai Awal	Root Cause Sebenarnya
Semua client intermittent	Upstream ISP bermasalah	❌ Bukan — lihat temuan di bawah
PPPoE connected tapi internet tidak stabil	Session PPPoE stuck	❌ Bukan — PPPoE clean
Voucher juga terdampak	Server Mikhmon down	✅ Sebagian benar — OVPN tunnel bermasalah
Sebagian client tidak bisa konek	IP conflict	✅ Benar — IP pool overlap

💡 Prinsip diagnosa: Kalau gejala menyerang semua client termasuk voucher secara bersamaan, selalu curigai komponen yang shared — bisa tunnel VPN ke server manajemen, DHCP pool, atau upstream ISP. Bukan masalah per-client.

Diagnosa Layer by Layer — Dari ARP Table hingga OVPN Log

Troubleshoot yang efektif dimulai dari data, bukan asumsi. Berikut urutan diagnosa yang dilakukan pada kasus ini, dari yang paling mudah ke yang paling dalam:

STEP 1

Cek ARP Table — /ip arp print — Dari output ARP table ditemukan interface 1_IN_ISP memiliki banyak entry berstatus failed. Ini sinyal awal ada masalah di upstream atau IP assignment. Lebih kritis lagi, ditemukan MAC address yang sama muncul di dua IP berbeda — tanda IP conflict dari pool yang overlap.

STEP 2

Cek IP Pool — /ip pool print — Ditemukan dua pool aktif dengan range yang hampir identik: pool HOTSPOT (10.10.0.1–10.10.15.254) dan pool hs-pool-7 (10.10.0.1–10.10.15.254). Overlap masif — IP yang sama bisa di-assign ke dua client berbeda dari pool yang berbeda.

STEP 3

Cek DHCP Server — /ip dhcp-server print — DHCP server aktif hanya satu (dhcp1) dan menggunakan pool hs-pool-7. Pool HOTSPOT tidak dipakai oleh siapapun — artinya bisa langsung dihapus tanpa risiko.

STEP 4

Cek OVPN Log — /log print where topics~"ovpn" — Di sinilah root cause kedua ditemukan. Log menunjukkan ovpn-mikhmon loop disconnect terus-menerus dengan error: "could not add address: already have such address (6)". Tunnel connect beberapa menit, lalu error, disconnect, retry — berulang tiap 15–20 menit.

Root Cause #1 — IP Pool Overlap: Dua Pool, Satu Range

Pool HOTSPOT dan hs-pool-7 terbentuk karena proses bridge yang dilakukan 3 hari sebelumnya. Saat interface di-bridge, MikroTik kadang membuat pool baru secara otomatis atau pool lama ikut ter-assign ke bridge interface baru. Hasilnya dua pool aktif dengan range yang hampir identik.

MIKROTIK CLI — Kondisi pool sebelum fix

/ip pool print
# NAME      RANGES
# HOTSPOT   10.10.0.1-10.10.11.21, 10.10.11.23-10.10.15.254
# EXPIRED   198.51.100.2-198.51.100.254
# PPPOE     203.0.113.2-203.0.113.254
# hs-pool-7 10.10.0.1-10.10.10.0, 10.10.10.2-10.10.15.254

HOTSPOT dan hs-pool-7 overlap hampir total di range 10.10.x.x. IP EXPIRED dan PPPOE menggunakan RFC 5737 documentation range untuk ilustrasi.

Dampaknya: client yang seharusnya mendapat IP dari hs-pool-7 kadang mendapat IP dari HOTSPOT pool, atau bahkan mendapat dua IP berbeda dari dua pool berbeda. Router bingung mau routing ke mana. Hasilnya intermittent — kadang konek, kadang tidak.

Fix IP Pool Overlap

FIX 1

Konfirmasi pool mana yang dipakai DHCP server — /ip dhcp-server print — lihat kolom address-pool. Pastikan tahu pool mana yang aktif dipakai sebelum menghapus apapun.

FIX 2

Hapus pool yang tidak dipakai — Karena DHCP server hanya pakai hs-pool-7, pool HOTSPOT bisa dihapus aman: /ip pool remove [find name=HOTSPOT]

FIX 3

Flush semua DHCP lease lama — Setelah pool dihapus, flush semua lease lama agar client reconnect dan mendapat IP bersih dari pool yang benar: /ip dhcp-server lease remove [find]

MIKROTIK CLI — Fix pool overlap

# Konfirmasi pool yang dipakai
/ip dhcp-server print

# Hapus pool HOTSPOT yang tidak dipakai
/ip pool remove [find name=HOTSPOT]

# Flush semua lease lama
/ip dhcp-server lease remove [find]

Tunggu 2-3 menit setelah flush — client akan reconnect otomatis dan mendapat IP bersih.

Root Cause #2 — OVPN Mikhmon Loop Disconnect di RouterOS 7.x

Mikhmon adalah sistem manajemen hotspot berbasis web yang terhubung ke MikroTik via OVPN tunnel. Kalau tunnel-nya putus, semua autentikasi voucher dan hotspot ikut terganggu — yang menjelaskan kenapa client voucher juga kena masalah, bukan hanya PPPoE.

MIKROTIK LOG — Pattern disconnect loop ovpn-mikhmon

21:28:07 ovpn,info  ovpn-mikhmon: initializing...
21:28:19 ovpn,info  ovpn-mikhmon: using encoding - BF-128-CBC/SHA1
21:29:12 ovpn,info  ovpn-mikhmon: connected
21:29:17 ovpn,error could not add address: already have such address (6)
21:29:17 ovpn,info  ovpn-mikhmon: disconnected
21:29:28 ovpn,info  ovpn-mikhmon: initializing...
21:29:48 ovpn,info  ovpn-mikhmon: disconnected <could not connect>
21:29:58 ovpn,info  ovpn-mikhmon: connected
21:35:06 ovpn,info  ovpn-mikhmon: disconnected <nothing received for a while>
21:35:46 ovpn,info  ovpn-mikhmon: disconnected <TLS error: handshake timed out>

Pattern ini terjadi berulang tiap 15-20 menit — tunnel connect lalu gagal karena IP lama belum di-release.

Kenapa "could not add address: already have such address"?

Error ini terjadi karena saat OVPN tunnel reconnect, IP address lama yang di-assign ke interface ovpn-mikhmon belum di-release dari routing table. Jadi ketika server mencoba assign IP yang sama lagi, MikroTik menolak karena IP itu sudah "ada" — konflik dengan dirinya sendiri. Ini bukan masalah cipher atau server — ini masalah IP tidak clean saat reconnect.

Error Message	Artinya	Solusi
could not add address: already have such address	IP lama belum di-release saat reconnect	✅ Hapus IP di interface OVPN → disable → enable
nothing received for a while	Server tidak merespons dalam timeout	✅ Cek koneksi ke server Mikhmon
TLS error: handshake timed out	Gagal bangun koneksi TLS ke server	✅ Cek cipher compatibility + koneksi upstream
could not connect	Gagal konek ke endpoint server	✅ Cek IP/domain server Mikhmon masih valid

Fix OVPN Mikhmon Disconnect Loop

FIX 1

Hapus IP sisa di interface OVPN — Ini langkah paling krusial. Jalankan: /ip address remove [find interface=ovpn-mikhmon] — ini membersihkan IP lama yang masih "nyangkut" di routing table.

FIX 2

Disable interface OVPN — /interface ovpn-client disable [find name=ovpn-mikhmon] — pastikan tunnel benar-benar mati sebelum di-enable ulang.

FIX 3

Enable ulang interface OVPN — /interface ovpn-client enable [find name=ovpn-mikhmon] — tunnel akan reconnect dari kondisi bersih tanpa IP lama. Tunggu 30 detik dan monitor log.

VERIFY

Verifikasi tunnel running — /interface ovpn-client print — pastikan flag menunjukkan R (running) tanpa error merah di log. Tunnel yang berhasil akan tetap connected tanpa loop.

MIKROTIK CLI — Fix OVPN disconnect loop (urutan wajib)

# Step 1: Hapus IP sisa di interface OVPN
/ip address remove [find interface=ovpn-mikhmon]

# Step 2: Disable tunnel
/interface ovpn-client disable [find name=ovpn-mikhmon]

# Step 3: Enable ulang — reconnect dari kondisi bersih
/interface ovpn-client enable [find name=ovpn-mikhmon]

# Verifikasi — harus ada flag R (running)
/interface ovpn-client print

Urutan ini wajib diikuti. Kalau langsung enable tanpa hapus IP dulu, error yang sama akan muncul lagi.

⚠️ Jangan ubah cipher OVPN sendirian tanpa koordinasi dengan admin server Mikhmon. Kalau cipher di MikroTik diubah tapi server masih pakai cipher lama, tunnel tidak akan bisa connect sama sekali. Koordinasi dulu sebelum mengubah cipher.

Studi Kasus: Kasus Nyata: RT/RW Net 26 Client di Kota Besar Sumatera
Sebuah jaringan RT/RW net dengan 26 client (PPPoE + voucher hotspot) mengalami intermittent connection setelah admin melakukan konfigurasi bridge baru 3 hari sebelumnya. Setelah analisa ARP table, ditemukan MAC address yang dapat IP ganda dari dua pool yang overlap. Bersamaan dengan itu, log OVPN menunjukkan ovpn-mikhmon loop disconnect tiap 15-20 menit dengan error "could not add address". Setelah fix dilakukan — hapus pool HOTSPOT yang tidak dipakai, flush DHCP lease, dan clean reconnect OVPN — semua client kembali stabil dan konfirmasi masalah resolved dalam waktu kurang dari 1 jam.

Alur Troubleshoot — Step by Step dari Gejala ke Solusi

STEP 1

Identifikasi scope masalah — Apakah masalah hanya di sebagian client atau semua? Kalau semua client terdampak termasuk voucher — curigai komponen shared: OVPN tunnel atau DHCP pool. Kalau hanya sebagian — curigai IP conflict atau PPPoE session stuck.

STEP 2

Cek ARP table — /ip arp print — Cari entry dengan status failed di interface ISP, dan MAC address yang muncul di dua IP berbeda. Keduanya adalah tanda pool overlap atau routing issue.

STEP 3

Cek IP pool — /ip pool print + /ip dhcp-server print — Bandingkan range semua pool yang ada. Kalau ada range yang overlap — identifikasi mana yang dipakai DHCP server aktif, lalu hapus yang tidak dipakai. Flush semua lease setelahnya.

STEP 4

Cek OVPN log — /log print where topics~"ovpn" — Cari error could not add address atau TLS handshake timed out. Kalau ada — lakukan clean reconnect: hapus IP di interface OVPN → disable → enable. Verifikasi flag R (running) setelahnya.

VERIFY

Konfirmasi dari sisi client — Jangan hanya cek WinBox — tes langsung dari device client: ping ke 8.8.8.8, buka browser, cek apakah koneksi stabil selama minimal 5 menit. Ini konfirmasi akhir bahwa fix benar-benar bekerja.

Checklist Preventif — Hindari Masalah Serupa

Masalah ini bisa dicegah dengan beberapa langkah preventif yang sebaiknya dilakukan setiap kali ada perubahan konfigurasi besar di jaringan RT/RW net:

Setelah membuat bridge baru — selalu cek /ip pool print untuk memastikan tidak ada pool baru yang terbuat otomatis dengan range yang overlap.
Setelah ganti dynamic ke static PPPoE — jalankan /ppp active remove [find] untuk drop semua session lama dan paksa reconnect dengan binding baru.
Monitor OVPN log secara berkala — error could not add address yang muncul di log sebelum jadi masalah bisa di-fix lebih awal dengan prosedur clean reconnect.
Dokumentasikan perubahan config — catat tanggal dan jenis perubahan yang dilakukan. Saat ada masalah, timeline ini sangat membantu isolasi root cause.
Test dari sisi client setelah setiap perubahan — jangan hanya cek status di WinBox. Tes langsung browsing dan ping dari device client untuk konfirmasi.

🔧 Tools diagnosa gratis: Gunakan Ping Test, Traceroute, dan DNS Lookup di cekipsaya.com untuk diagnosa koneksi dari sisi client secara real-time — tanpa install apapun.

FAQ — Pertanyaan yang Sering Ditanyakan

Kenapa OVPN Mikhmon bisa disconnect loop di RouterOS 7?

Root cause paling umum adalah IP address lama yang belum di-release dari routing table saat tunnel reconnect. Saat server mencoba assign IP yang sama lagi, MikroTik menolak karena IP itu sudah ada — konflik dengan dirinya sendiri. Fix-nya: hapus IP di interface OVPN dulu (<code>/ip address remove [find interface=ovpn-mikhmon]</code>), baru disable dan enable ulang tunnel-nya.

Apa bedanya IP pool overlap dengan IP conflict biasa?

IP pool overlap terjadi ketika dua pool berbeda memiliki range yang sama atau bertumpukan. Satu client bisa mendapat IP dari dua pool berbeda, atau dua client berbeda mendapat IP yang sama dari pool yang berbeda. Berbeda dengan IP conflict biasa yang terjadi saat dua device dikonfigurasi dengan IP statis yang sama.

Apakah aman menghapus IP pool di MikroTik yang sedang aktif?

Tidak langsung aman kalau pool masih dipakai oleh DHCP server atau layanan lain. Selalu cek dulu dengan <code>/ip dhcp-server print</code> untuk memastikan pool yang mau dihapus tidak sedang aktif dipakai. Setelah yakin tidak dipakai, hapus pool lalu flush DHCP lease agar client reconnect dengan bersih.

Kenapa semua client kena masalah kalau hanya OVPN Mikhmon yang bermasalah?

Karena Mikhmon adalah sistem manajemen hotspot yang menangani autentikasi voucher dan session hotspot. Saat tunnel OVPN ke server Mikhmon putus, semua proses autentikasi baru ikut terganggu. Client yang sudah login mungkin masih bisa browsing sementara, tapi client baru yang mencoba login atau yang sessionnya expired tidak bisa terautentikasi.

Apakah cipher BF-128-CBC masih aman dipakai di RouterOS 7?

BF-128-CBC (Blowfish) adalah cipher yang sudah tua dan tidak direkomendasikan untuk keamanan tinggi. Namun untuk jaringan RT/RW net internal, ini masih acceptable selama server juga support cipher ini. Yang lebih penting, jangan ubah cipher di sisi MikroTik tanpa koordinasi dengan admin server Mikhmon — perubahan satu sisi akan menyebabkan tunnel tidak bisa connect sama sekali.

Berapa lama proses fix ini dan apakah client perlu restart?

Seluruh proses fix biasanya selesai dalam 5-10 menit. Client tidak perlu restart device — setelah DHCP lease di-flush, client akan otomatis mendapat IP baru dalam hitungan detik hingga 1-2 menit tergantung DHCP lease time yang dikonfigurasi. Untuk OVPN, tunnel biasanya reconnect dalam 30-60 detik setelah di-enable ulang.

Kesimpulan

Dua masalah yang terlihat seperti satu gejala — internet tidak stabil di semua client — ternyata punya root cause yang berbeda: IP pool overlap yang menyebabkan client mendapat IP ganda, dan OVPN Mikhmon yang loop disconnect karena sisa IP lama belum di-release saat reconnect. Keduanya harus diselesaikan bersamaan. Gunakan Ping Test dan Traceroute di cekipsaya.com untuk diagnosa awal koneksi, dan selalu mulai troubleshoot dari data — ARP table, pool print, dan log — sebelum mengambil kesimpulan. Kalau masalah jaringan RT/RW net kamu mirip dengan kasus ini, ikuti langkah-langkah di atas dan pastikan fix dilakukan secara berurutan.