View source for Mikrotik : Praktikum Uji Tunnel IPsec dan Diagnosa Kegagalan

Tunnel IPsec yang berstatus *established* belum tentu sehat. Materi ini melanjutkan artikel konsep pagi ini dengan sudut yang berbeda: bukan memasang tunnel, tetapi **mengujinya secara sengaja** — merusak satu bagian, membaca gejalanya, lalu memperbaiki.

== 🎯 Tujuan ==

Setelah menyelesaikan praktikum ini, kamu diharapkan bisa:

* Membaca status tunnel IPsec berlapis: fase 1, fase 2, jalur data, dan kesehatan jangka panjang.
* Melakukan **fault injection** terkontrol pada PSK, proposal, policy, NAT, FastTrack, firewall, dan MTU.
* Memetakan gejala ke bukti yang tepat, bukan menebak-nebak.
* Mengukur waktu deteksi DPD dan mengamati rekey SA tanpa trafik putus.
* Mengembalikan lab ke kondisi bersih dan mendokumentasikan hasil uji.

💡 '''Tips:''' satu uji, satu perubahan. Kalau kamu mengubah dua hal sekaligus, kamu tidak akan tahu mana yang menyebabkan gejala.

== 📍 Konteks nyata ==

Bayangkan kurir bersegel yang mengantar dokumen antar kantor. Ada empat pos pemeriksaan: kurirnya dikenal, segelnya utuh, alamat tujuannya benar, dan jalannya tidak banjir. Kalau paket hilang, kamu harus tahu pos mana yang gagal — bukan hanya bilang "kurirnya bermasalah".

IPsec juga begitu. Status `established` hanya berarti pos pertama dan kedua lulus. Data masih bisa mati di pos ketiga dan keempat.

🔥 '''Kasus nyata:''' sebuah SMK memakai IPsec untuk menghubungkan lab komputer di gedung B ke server CBT di gedung A. Pada hari ujian, siswa bisa login, tetapi tombol **kirim jawaban menggantung** dan sesi sering habis. Ping 5 paket kecil dari router mulus, tunnel `established`, dan tidak ada error di log — sehingga panitia menyimpulkan "jaringan normal". Setelah diperiksa: jalur uplink gedung B memakai modem 4G dengan MTU 1400, sementara tunnel memakai 1500; paket besar terfragmentasi lalu dibuang. Ditambah jam router meleset 11 menit setelah listrik padam, sehingga SA putus dan dibangun ulang berkala. Dua masalah berbeda, satu keluhan yang sama.

== 🧠 Konsep singkat ==

Uji tunnel IPsec sebaiknya berlapis, dari bawah ke atas. Jangan langsung ping.

| Lapis | Yang diperiksa | Perintah utama | Bukti sehat |
|---|---|---|---|
| 1 | Fase 1 (IKE SA) | `/ip ipsec active-peers print` | `state=established`, `uptime` bertambah |
| 2 | Fase 2 (IPsec SA) | `/ip ipsec policy print` | flag `A`, `ph2-state=established`, `ph2-count` minimal 2 |
| 3 | Jalur data | ping ber-`src-address`, counter NAT, raw/notrack | reply konsisten, counter bertambah |
| 4 | Kesehatan jangka panjang | `installed-sa`, `expires-in`, `/system clock print` | rekey mulus, waktu sinkron |

📊 '''Angka penting:''' default RouterOS — profile `dpd-interval=8s`, `dpd-maximum-failures=4` (deteksi sekitar 32 detik), proposal `lifetime=30m`, dan `pfs-group=modp1024`. Nilai default bukan salah, tetapi harus cocok di kedua sisi.

=== 🔹 Statistik adalah struk pembayaran ===

Menu `/ip ipsec statistics` mencatat error masuk dan keluar. Kalau kita reset dulu, lalu melakukan satu kesalahan saja, counter yang naik akan menunjuk lokasi masalah.

* `in-no-policies` — SA masuk benar, tetapi tidak ada policy yang cocok.
* `in-template-mismatches` — SA masuk benar, tetapi template policy tidak cocok.
* `in-state-mismatches` — opsi SA tidak cocok, misalnya tipe UDP encapsulation.
* `out-policy-blocked` — policy bertindak `discard` terhadap paket keluar.

🧪 '''Uji cepat:''' selalu `/ip ipsec statistics reset` sebelum uji, lalu baca lagi setelah uji. Tanpa reset, angka lama akan menyesatkan.

=== 🔹 Kenapa ping ke IP WAN bukan bukti ===

Dokumentasi MikroTik menyebut paket yang berasal dari router dengan UDP sumber `500` **tidak** diproses oleh SPD, begitu juga paket tujuan lokal ke UDP `500`. Artinya, ping ke IP WAN peer bisa berhasil walau tunnel sama sekali tidak membawa data.

Selain itu, fase 1 hanya di-rekey saat `lifetime` habis **jika DPD aktif**. Kalau DPD dimatikan, hanya fase 2 yang diperbarui — detail kecil yang sering membuat tunnel "hidup tapi aneh".

== 🧩 Istilah penting ==

* **Fault injection** — sengaja merusak satu komponen untuk melihat gejalanya, dilakukan hanya di lab.
* **Baseline** — rekaman kondisi normal sebelum uji, dipakai sebagai pembanding.
* **ph2-total** — jumlah SA fase 2 yang aktif untuk satu peer. Nol berarti fase 2 belum jadi.
* **ph2-state** — status fase 2 pada policy: `established`, `no-phase2`, atau `expired`.
* **Mature** — status SA yang sudah siap dipakai; kebalikannya `dying` saat menuju kedaluwarsa.
* **Soft/hard lifetime** — soft memicu pembuatan SA baru, hard menghapus SA lama.
* **NAT-T** — pembungkusan ESP ke UDP `4500` agar bisa melewati NAT.
* **MSS clamp** — menurunkan ukuran segmen TCP agar tidak perlu fragmentasi.
* **Notrack** — melewati connection tracking; dipakai agar FastTrack tidak menyalip IPsec.
* **Rekey** — penggantian kunci SA tanpa memutus trafik.

== 🔧 Praktik: Uji Tunnel IPsec dan Diagnosa Kegagalan ==

Praktikum ini mengasumsikan tunnel dari artikel [[Mikrotik : VPN IPsec Dasar]] sudah berjalan. Alamat yang dipakai tetap sama:

| Perangkat | WAN | LAN |
|---|---|---|
| Kantor A | `192.0.2.10/24` | `10.1.203.0/24` |
| Kantor B | `198.51.100.10/24` | `10.1.102.0/24` |

⚠️ '''Hati-hati:''' semua uji di bawah dilakukan di lab sendiri. Jangan pernah melakukan fault injection pada tunnel produksi yang sedang dipakai ujian atau transaksi.

=== 🔹 Langkah 1: siapkan baseline bukti ===

Catat kondisi normal sebelum merusak apa pun. Di **Kantor A**:

<syntaxhighlight lang="text">
/ip ipsec statistics reset
/ip ipsec active-peers print detail
/ip ipsec policy print stats
/ip ipsec installed-sa print detail
/ip firewall nat print stats
/ping 10.1.102.1 src-address=10.1.203.1 count=5
</syntaxhighlight>

Simpan hasilnya sebagai baseline. Yang perlu dicatat: `ph2-total`, `ph2-state`, jumlah SA, dan apakah ping 0% loss.

💡 '''Tips:''' tulis baseline di kertas atau file. Saat panik karena tunnel mati, ingatanmu tidak bisa dipercaya.

=== 🔹 Langkah 2: Uji A — PSK salah (fase 1 gagal) ===

Di **Kantor B**, ubah secret menjadi berbeda:

<syntaxhighlight lang="text">
/ip ipsec identity set [find peer=peer-ke-a] secret="KunciSalahUntukUji"
</syntaxhighlight>

Di **Kantor A**, paksa negosiasi ulang:

<syntaxhighlight lang="text">
/ip ipsec active-peers kill-connections
/ping 10.1.102.1 src-address=10.1.203.1 count=3
</syntaxhighlight>

Gejala yang muncul: `active-peers` kosong, ping gagal, dan log menampilkan kegagalan fase 1. Perhatikan bahwa `policy` bisa tetap ada, tetapi tanpa flag `A`.

🧪 '''Uji cepat:''' `/log print where topics~"ipsec"` — cari kata `phase1` atau `authentication`. Kalau fase 1 tidak pernah berdiri, jangan buang waktu memeriksa policy.

Kembalikan secret yang benar sebelum lanjut.

=== 🔹 Langkah 3: Uji B — proposal fase 2 tidak cocok ===

Sekarang rusak fase 2 saja. Di **Kantor B**:

<syntaxhighlight lang="text">
/ip ipsec proposal set [find name=prop-aes256] pfs-group=modp1536
</syntaxhighlight>

Lalu di **Kantor A**:

<syntaxhighlight lang="text">
/ip ipsec active-peers kill-connections
/ping 10.1.102.1 src-address=10.1.203.1 count=3
</syntaxhighlight>

Gejala khasnya berbeda dari Uji A: peer **muncul** dengan `state=established`, tetapi `ph2-total=0` dan policy berstatus `no-phase2`. Log menyebut negosiasi fase 2 gagal.

📊 '''Angka penting:''' inilah pembeda paling berguna saat troubleshooting — peer kosong berarti fase 1, peer hidup dengan `ph2-total=0` berarti fase 2. Jangan tertukar.

Kembalikan `pfs-group=modp2048` di kedua sisi.

=== 🔹 Langkah 4: Uji C — hanya satu arah policy ===

Hapus sementara policy arah balik di kedua router (di A hapus `B ke A`, di B hapus `A ke B`). Ingat: hapus hanya yang arah balik.

<syntaxhighlight lang="text">
/ip ipsec policy print
/ip ipsec policy disable [find comment="B ke A"]
</syntaxhighlight>

Sesuaikan nama comment dengan konfigurasimu. Lalu ping dari A:

<syntaxhighlight lang="text">
/ping 10.1.102.1 src-address=10.1.203.1 count=5
</syntaxhighlight>

Hasilnya: 100% loss, tetapi di **Kantor B** terlihat request masuk. Di A, `installed-sa` menunjukkan `tx-bytes` naik sementara `rx-bytes` hampir tidak bergerak. Ini ciri klasik policy satu arah — request keluar, balasan dibuang karena tidak ada selector yang cocok.

Aktifkan kembali policy tersebut dan pastikan ping kembali normal.

=== 🔹 Langkah 5: Uji D — NAT dan FastTrack menyalip IPsec ===

Pindahkan rule bypass NAT ke bawah `masquerade`:

<syntaxhighlight lang="text">
/ip firewall nat print
/ip firewall nat move 0 1
/ip firewall nat print stats
</syntaxhighlight>

Ping lagi. Tunnel tetap `established`, tetapi trafik gagal karena alamat sumber sudah diubah sebelum dienkripsi. Counter `masquerade` naik, counter rule bypass tetap nol.

Kembalikan ke posisi teratas:

<syntaxhighlight lang="text">
/ip firewall nat move 1 0
</syntaxhighlight>

Sekarang uji FastTrack. Tambahkan rule di atas chain `forward`:

<syntaxhighlight lang="text">
/ip firewall filter add chain=forward action=fasttrack-connection \
    connection-state=established,related place-before=0
</syntaxhighlight>

Dokumentasi MikroTik menegaskan FastTrack membuat paket **melewati policy IPsec**. Solusinya bukan menghapus FastTrack, tetapi mengecualikan trafik tunnel lebih awal:

<syntaxhighlight lang="text">
/ip firewall raw add action=notrack chain=prerouting \
    src-address=10.1.203.0/24 dst-address=10.1.102.0/24
/ip firewall raw add action=notrack chain=prerouting \
    src-address=10.1.102.0/24 dst-address=10.1.203.0/24
</syntaxhighlight>

📊 '''Angka penting:''' dokumentasi menyebut bypass lewat raw `notrack` mengurangi beban CPU sekitar 30% dibanding menambah rule `accept` di filter untuk setiap tunnel.

=== 🔹 Langkah 6: Uji E — IKE dibuka, ESP diblok ===

Ini simulasi firewall yang "hampir benar": UDP `500` diizinkan, tetapi protokol ESP tidak.

<syntaxhighlight lang="text">
/ip firewall filter print
/ip firewall filter disable [find comment~"ESP"]
/ip ipsec active-peers kill-connections
/ping 10.1.102.1 src-address=10.1.203.1 count=3
</syntaxhighlight>

Gejala: fase 1 bisa berdiri karena UDP `500` lolos, tetapi data tidak pernah sampai. Yang membuat bingung, sering **tidak ada error jelas di log** — karena paket ESP dibuang firewall sebelum sempat dilaporkan sebagai masalah IPsec.

💡 '''Tips:''' kalau `active-peers` hidup, policy aktif, tetapi counter SA tidak bergerak, curigai firewall atau MTU sebelum menuduh PSK.

Aktifkan kembali rule ESP.

=== 🔹 Langkah 7: Uji F — cari MTU dan pasang MSS clamp ===

Uji paket besar dengan larangan fragmentasi:

<syntaxhighlight lang="text">
/ping 10.1.102.1 src-address=10.1.203.1 size=1400 do-not-fragment=yes count=3
/ping 10.1.102.1 src-address=10.1.203.1 size=1300 do-not-fragment=yes count=3
</syntaxhighlight>

Kalau ukuran 1400 gagal dan 1300 berhasil, jalur tunnel tidak sanggup membawa paket penuh. Overhead ESP mode tunnel sekitar 50–73 byte, jadi MTU 1500 di kabel belum tentu jadi 1500 di dalam tunnel.

Pasang MSS clamp agar TCP tidak memaksa paket besar:

<syntaxhighlight lang="text">
/ip firewall mangle add chain=forward action=change-mss new-mss=1360 \
    protocol=tcp tcp-flags=syn tcp-mss=1361-65535 passthrough=yes \
    comment="MSS clamp untuk tunnel IPsec"
</syntaxhighlight>

🔥 '''Kasus nyata:''' di kasus SMK tadi, login CBT berhasil karena halaman login kecil. Yang menggantung justru unggahan jawaban berisi gambar. Setelah MSS diturunkan ke 1360, unggahan selesai normal tanpa mengubah bandwidth.

=== 🔹 Langkah 8: Uji G — DPD, rekey, dan jam ===

Uji deteksi peer mati. Disable policy di **Kantor B**, lalu dari A jalankan ping terus-menerus sambil mengamati peer:

<syntaxhighlight lang="text">
/ping 10.1.102.1 src-address=10.1.203.1 count=60
/ip ipsec active-peers print detail
</syntaxhighlight>

Dengan `dpd-interval=8s` dan `dpd-maximum-failures=4`, peer biasanya dianggap mati setelah sekitar 30–40 detik, bukan seketika. Kolom `last-seen` terus bertambah sebelum peer hilang.

Uji rekey tanpa memutus trafik. Ubah lifetime proposal menjadi 5 menit di kedua sisi, lalu amati:

<syntaxhighlight lang="text">
/ip ipsec installed-sa print detail
</syntaxhighlight>

Perhatikan `expires-in` menghitung mundur dan `spi` berganti. Ping bersamaan seharusnya tetap 0% loss — kalau putus, ada masalah pada `pfs-group` atau waktu.

Terakhir, periksa jam:

<syntaxhighlight lang="text">
/system clock print
/system ntp client print
</syntaxhighlight>

Selisih waktu antar ujung adalah penyebab putus berkala yang paling sering terlewat.

=== 🔹 Langkah 9: Uji H — policy duplikat dan flag invalid ===

Tambahkan policy dengan selector yang sama persis seperti policy yang sudah ada:

<syntaxhighlight lang="text">
/ip ipsec policy add peer=peer-ke-b src-address=10.1.203.0/24 \
    dst-address=10.1.102.0/24 proposal=prop-aes256 tunnel=yes \
    action=encrypt level=require comment="duplikat uji"
/ip ipsec policy print
</syntaxhighlight>

Policy baru akan tampil dengan flag `I` (invalid). Dokumentasi menyebut penyebabnya memang duplikat `src-address`/`dst-address`. Policy invalid tidak dipakai, dan membuat bingung karena konfigurasi "terlihat lengkap".

Hapus kembali:

<syntaxhighlight lang="text">
/ip ipsec policy remove [find comment="duplikat uji"]
</syntaxhighlight>

=== 🔹 Langkah 10: bersih-bersih dan lembar hasil ===

<syntaxhighlight lang="text">
/ip firewall mangle remove [find comment~"MSS clamp"]
/ip firewall raw remove [find action=notrack]
/ip firewall filter remove [find action=fasttrack-connection]
/ip ipsec active-peers kill-connections
/ip ipsec policy print
/ip ipsec active-peers print
/ping 10.1.102.1 src-address=10.1.203.1 count=5
/export file=lab-ipsec-setelah-uji
</syntaxhighlight>

Isi lembar hasil berikut setelah praktik. Ini yang membedakan laporan praktikum dari sekadar daftar command.

| Uji | Gejala utama | Bukti kunci | Pelajaran |
|---|---|---|---|
| A | peer kosong, ping gagal | `active-peers` kosong, log fase 1 | PSK/proposal fase 1 |
| B | peer hidup, data mati | `ph2-total=0`, `no-phase2` | bedakan fase 1 vs 2 |
| C | request masuk, balasan hilang | `tx-bytes` naik, `rx-bytes` diam | policy satu arah |
| D | SA aktif, trafik gagal | counter masquerade naik | NAT sebelum enkripsi |
| D | trafik lolos tanpa enkripsi | FastTrack di atas policy | raw `notrack` |
| E | IKE hidup, data mati | tidak ada error log | ESP diblok firewall |
| F | login jalan, unggah macet | ping 1400 gagal, 1300 lolos | MTU dan MSS |
| G | putus berkala | `last-seen`, jam meleset | DPD dan NTP |
| H | policy tampak lengkap | flag `I` | duplikat selector |

== 🏭 Dipakai di dunia kerja ==

* **Sekolah:** lab CBT di gedung terpisah terhubung ke server ujian; uji MTU wajib sebelum hari ujian, karena unggahan jawaban lebih besar dari halaman login.
* **Kantor cabang:** aplikasi ERP dan penggajian lewat tunnel; tim IT memantau `ph2-total` agar tahu kapan cabang benar-benar terputus, bukan hanya "koneksi internet hidup".
* **Koperasi dan bank:** jalur host-to-host antar kantor pusat dan cabang; perubahan policy satu arah bisa menghentikan setoran tanpa pesan error yang jelas.
* **Industri:** data PLC dan sensor dikirim ke server monitoring pusat; MSS clamp dan MTU yang benar mencegah data produksi terpotong.
* **ISP dan NOC:** tunnel pelanggan korporat dipantau lewat `last-seen` dan counter SA; deteksi dini mencegah komplain sebelum pelanggan menelepon.
* **Klinik dan rumah sakit:** rekam medis antar cabang; jam yang sinkron penting agar sesi tidak putus saat sedang mengisi data pasien.

== ✅ Verifikasi ==

Jalankan berurutan setelah semua uji selesai:

<syntaxhighlight lang="text">
/ip ipsec active-peers print detail
/ip ipsec policy print stats
/ip ipsec installed-sa print detail
/ip ipsec statistics print
/ip firewall nat print stats
/ping 10.1.102.1 src-address=10.1.203.1 count=10
</syntaxhighlight>

| Pemeriksaan | Hasil yang diharapkan |
|---|---|
| Fase 1 | `state=established`, `uptime` bertambah, `last-seen` kecil |
| Fase 2 | `ph2-count` minimal 2, `ph2-state=established`, flag `A` |
| SA | ada entri ESP `state=mature`, `expires-in` wajar |
| Statistik | tidak ada kenaikan `in-no-policies` atau `in-template-mismatches` |
| NAT | counter rule bypass bertambah, bukan counter masquerade |
| Trafik | ping 10 paket, 0% loss, waktu stabil |

🧪 '''Uji cepat:''' reset statistik, ping 10 paket, lalu baca statistik lagi. Kalau bersih, tunnel benar-benar sehat — bukan hanya "kelihatan hidup".

== ⚠️ Kesalahan umum & troubleshooting ==

| Gejala | Perintah pemeriksa | Penyebab dan perbaikan |
|---|---|---|
| `active-peers` kosong | `/ip ipsec active-peers print` | PSK beda, DH group beda, atau UDP `500` diblok |
| Peer hidup, `ph2-total=0` | `/ip ipsec policy print stats` | Proposal/PFS beda, `tunnel=no`, selector tidak cocok |
| Ping satu arah timeout | `/ip ipsec installed-sa print detail` | Policy balik belum ada atau dinonaktifkan |
| SA aktif, trafik nol | `/ip firewall nat print stats` | `masquerade` mendahului bypass, atau FastTrack menyalip |
| IKE hidup, ESP hilang | `/ip firewall filter print stats` | Protokol ESP tidak diizinkan |
| Login jalan, unggah macet | `/ping ... size=1400 do-not-fragment=yes` | MTU terlalu besar, MSS belum di-clamp |
| Putus tiap beberapa jam | `/system clock print`, `/system ntp client print` | Jam tidak sinkron, SA harus dibangun ulang |
| `in-no-policies` naik | `/ip ipsec statistics print` | SA masuk tanpa policy yang cocok |
| `in-template-mismatches` naik | `/ip ipsec policy print` | Template policy tidak cocok, biasanya mode-config |
| Policy berflag `I` | `/ip ipsec policy print` | Ada dua policy dengan selector sama |
| Rekey memutus trafik | `/ip ipsec installed-sa print detail` | `pfs-group` beda atau waktu tidak sinkron |

⚠️ '''Hati-hati:''' jangan menambah policy baru di atas policy yang bermasalah. Perbaiki penyebabnya dulu, karena policy dibaca berurutan dari atas ke bawah.

== 🔐 Catatan keamanan & etika ==

* **Fault injection hanya untuk lab.** Merusak tunnel produksi bisa menghentikan ujian, absensi, atau transaksi.
* **PSK tetap lemah.** Dokumentasi MikroTik menyatakan serangan *offline* terhadap PSK mungkin terjadi bahkan pada mode `main` dan `ikev2`. Untuk produksi, gunakan sertifikat.
* **Batasi sumber IKE.** Jangan buka UDP `500/4500` untuk seluruh internet; batasi ke IP peer.
* **Hati-hati saat logging.** Log IPsec bisa memuat alamat, identitas, dan informasi negosiasi. Aktifkan debug hanya selama uji, lalu matikan.
* **Uji tidak menghapus enkripsi.** Menurunkan MSS atau menambah `notrack` tidak melemahkan IPsec; keduanya hanya mengatur jalur paket.
* **Etika praktik.** Semua pengujian dilakukan pada perangkat sendiri atau yang kamu punya izin tertulis.

== 📌 Kesimpulan ==

Tunnel IPsec yang sehat punya empat lapis bukti: peer berdiri, SA fase 2 terbentuk, jalur data bersih, dan waktu sinkron. Kalau satu lapis gagal, gejala dan perintah pemeriksanya berbeda.

Tiga kebiasaan yang paling menolong:

* **Baseline dulu, reset statistik, satu perubahan per uji.**
* **Bedakan peer kosong (fase 1) dari `ph2-total=0` (fase 2).**
* **Curigai NAT, FastTrack, firewall, dan MTU sebelum menuduh kunci.**

Langkah berikutnya: ulangi Uji A sampai Uji H tanpa melihat panduan, lalu tulis sendiri gejalanya. Kemampuan mendiagnosis inilah yang dipakai di dunia kerja, bukan hafalan command.

== 🔗 Materi terkait ==

* [[Mikrotik : VPN IPsec Dasar]] — konsep dan lab pemasangan tunnel yang menjadi dasar praktikum ini.
* [[Mikrotik : Praktikum Uji WireGuard Site-to-Site]] — pola fault injection serupa untuk VPN modern.
* [[Mikrotik : Firewall Filter Dasar]] — dasar mengizinkan UDP `500/4500` dan protokol ESP.
* [[Mikrotik : Praktikum Cek Firewall Filter dengan Counter dan Log]] — membaca counter dan log saat paket jatuh.
* [[Mikrotik : NAT Masquerade agar Client Bisa Internet]] — memahami urutan NAT sebelum enkripsi.
* [[Mikrotik : Firewall Mangle Dasar]] — tempat menaruh MSS clamp dan mark paket.
* [[Mikrotik : Tabel Routing dan Manajemen Rute di RouterOS v7]] — memastikan rute antar-LAN benar sebelum menyalahkan tunnel.

== 📚 Referensi ==

* MikroTik RouterOS Documentation — IPsec: https://help.mikrotik.com/docs/spaces/ROS/pages/11993097/IPsec
* MikroTik RouterOS Manual — IPsec: https://manual.mikrotik.com/docs/virtual-private-networks/ipsec/
* IETF RFC 4301 — Security Architecture for the Internet Protocol
* IETF RFC 4303 — Encapsulating Security Payload (ESP)
* IETF RFC 7296 — Internet Key Exchange Protocol Version 2 (IKEv2)
* IETF RFC 5737 — IPv4 Address Blocks Reserved for Documentation

[[Category:TKJ]]
[[Category:Jaringan]]
[[Category:Mikrotik]]