soal screenshot LAN/VLAN - DanDan - Personal Notes Parmi

bantu analisa dan je;askan ini

Gambar tersebut menunjukkan halaman konfigurasi port fisik (Port 7, dengan label name LAN Port 1) pada antarmuka Web Admin router/switch Peplink (Web Admin Interface).

Analisis Parameter Konfigurasi

Name (LAN Port 1): Port fisik nomor 7 pada sasis diberi label logis sebagai LAN Port 1.
Enable (Tercentang): Port dalam keadaan aktif (up).
PoE Enable (Tercentang): Fitur Power over Ethernet diaktifkan, artinya port ini menyuplai daya ke perangkat penerima (seperti Access Point atau IP Phone).
Speed (Auto): Negosiasi kecepatan port dan duplex dilakukan secara otomatis (Auto-negotiation).
Port Type (Trunk): Port diatur ke mode Trunk, yang memungkinkan port ini melewatkan lebih dari satu VLAN melalui satu jalur fisik (cocok dihubungkan ke Access Point multi-SSID atau switch lain).
VLAN Networks (Custom):
Diaktifkan (Centang): LAN (1), MAX_BR2 (220), dan SIL (280). Ketiga VLAN ini diizinkan lewat melalui port ini.
Ditolak (Kosong): PORT MNG (50). Traffic VLAN 50 diblokir/tidak dilewatkan ke port ini.
PVID (LAN (1)):
Port VLAN Identifier (Native VLAN): Diatur ke LAN (1).
Fungsi Ingress: Paket data tanpa tag 802.1Q (untagged frame) yang masuk ke Port 7 akan otomatis dimasukkan ke dalam VLAN 1.
Fungsi Egress: Paket data dari VLAN 1 yang keluar lewat Port 7 akan dilepas tag-nya (untagged), sesuai dengan kutipan pada pop-up Help: "All frames from the VLAN are untagged on egress."

Ringkasan Operasional Port

Port ini dikonfigurasi sebagai Trunk Port dengan detail enkapsulasi:

Untagged Traffic: VLAN 1 (LAN)
Tagged Traffic (802.1Q): VLAN 220 (MAX_BR2) dan VLAN 280 (SIL)
Blocked Traffic: VLAN 50 (PORT MNG)

masalah error ini ( test koneksi SF ) bisa di jelaskan penyebabnya ?
ini produk peplink aggregator

normalnya test harusnya bisa

Penyebab utama pesan Error: Stream 1: Cannot start connection pada SpeedFusion VPN Test ini terletak pada kondisi link WAN yang aktif serta pemblokiran port traffic oleh firewall/provider.

Analisis Penyebab Utama

Satu-Satunya WAN Aktif Hanya "Wi-Fi WAN on 2.4 GHz":
Di tabel status WAN, semua interface utama (SFP, WAN 1-5, Mobile Internet, Ethernet) berstatus WAN disabled atau WAN down.
Hanya Wi-Fi WAN 2.4 GHz yang berstatus Up (hijau). Wi-Fi WAN pada frekuensi 2.4 GHz sangat rentan terhadap packet loss, jitter, dan interferensi. Jika link ini mengalami keilangan paket di awal handshake atau throughput-nya drop, Peplink tidak bisa menginisiasi stream TCP untuk pengujian.
Firewall / Port Blocking di Sisi WAN atau Endpoint Remote:
Pengujian menggunakan protokol TCP. SpeedFusion Test membutuhkan komunikasi dua arah ke VPN Endpoint (Peplink remote atau FusionHub) melalui port data SpeedFusion (secara default TCP/UDP 2760 atau port enkapsulasi Data/Handshake 4500/500).
Jika jaringan Wi-Fi WAN yang terhubung berada di balik NAT ketat (Carrier-Grade NAT), hotspot publik, atau memiliki firewall yang memblokir outbound TCP port khusus tersebut, sesi stream tidak akan bisa terbentuk (handshake fail).
Terdapat Warning Sistem (WAN-to-WAN Connection Disabled):
Banner abu-abu di bawah tabel WAN mencatat: "The WAN-to-WAN connection disabled by the switch is temporary...". Ini mengindikasikan adanya mekanisme proteksi internal atau batasan routing pada switch/firmware yang sedang membatasi komunikasi antar-WAN sementara waktu.
Tunnel SpeedFusion Belum Terbentuk / Remote Unreachable:
Pengujian bawaan ini (SpeedFusion Test) mengharuskan VPN Tunnel aktif ke remote peer. Jika handshake VPN itu sendiri belum Established di jalur Wi-Fi WAN tersebut, maka tes stream internal otomatis akan gagal seketika.

Langkah Diagnosis & Solusi Quick-Fix

Ubah Mode Tes ke UDP:

* Pada SpeedFusion VPN Test Configuration, ubah pilihan Type dari TCP ke UDP. UDP lebih toleran terhadap latensi dan handshake loss awal pada koneksi Wi-Fi.

Cek Status SpeedFusion Profile:

* Pastikan tunnel SpeedFusion (VPN) ke FusionHub / Peer tujuan sudah berstatus Connected di menu Dashboard utama sebelum menjalankan tes.

Gunakan WAN Fisik / Seluler:

* Coba aktifkan salah satu jalur kabel (Ethernet/WAN 2) atau Mobile Internet. Jalur kabel/seluler jauh lebih stabil untuk membuka handshake stream dibanding Wi-Fi WAN 2.4 GHz.

Cek Outbound Port:

* Pastikan jaringan Wi-Fi sumber (Access Point tempat Wi-Fi WAN terhubung) tidak memblokir port outbound TCP/UDP 2760.

staus established 
test mode UDP masih sama

Masalah utama pada pengujian kali ini terletak pada nilai alokasi Bandwidth yang diisi terlalu tinggi (500.000 kbps / 500 Mbps) untuk ukuran satu link Wi-Fi WAN 2.4 GHz.

Ketika pengujian UDP dijalankan, Peplink langsung mencoba memesan/mengalokasikan buffer stream sebesar 500 Mbps. Karena daya tampung (link capacity) Wi-Fi WAN 2.4 GHz riil jauh di bawah itu (biasanya hanya berkisar 10–30 Mbps), socket pengujian gagal diinisiasi (socket binding failed) dan seketika mengeluarkan error Cannot start connection.

Penyebab & Solusi Spesifik

Nilai Bandwidth Terlalu Besar (Over-allocation):
Penyebab: Parameter Bandwidth diisi 500000 kbps. Wi-Fi WAN 2.4 GHz tidak mampu memproses pemesanan throughput sebesar 500 Mbps.
Solusi: Turunkan angka ini ke batas realistis Wi-Fi 2.4 GHz, misalnya 10000 kbps (10 Mbps) atau 20000 kbps (20 Mbps) terlebih dahulu.
Fungsi SpeedFusion Test Mode UDP vs TCP:
Pada mode UDP, Peplink membutuhkan parameter isi Bandwidth (kbps) sebagai target pengiriman data (karena UDP tidak memiliki congestion control otomatis seperti TCP). Jika angkanya tidak masuk akal dibanding kapasitas interface aktif, engine tes akan gagal membuat stream.
Pada mode TCP, parameter diubah menjadi Streams (jumlah koneksi paralel), bukan Bandwidth.
Mekanisme WAN-to-WAN Rate Control / Block:
Dari screenshot sebelumnya, terdapat peringatan temporer pada switch WAN ("WAN-to-WAN connection disabled by the switch..."). Jika pengujian menembak IP remote via subnet WAN yang sedang di-throttle atau di-blok sementara oleh switch internal, stream tidak akan bisa terbuka.

Langkah Perbaikan Langsung

Ubah isi kolom Bandwidth dari 500000 menjadi 10000 (10 Mbps).
Klik tombol Start kembali.
Jika berhasil pada 10 Mbps, naikkan secara bertahap (misal 20000, 30000) untuk mencari batas throughput riil tunnel SpeedFusion tersebut.

125kbps sama saja

Jika settingan bandwidth minimal seperti 125 kbps masih menghasilkan Error: Stream 1: Cannot start connection, maka masalahnya bukan di alokasi bandwidth, melainkan port data pengujian terblokir atau daemon/listener iperf SpeedFusion di sisi remote peer tidak merespons.

Penyebab Utama & Penjelasan Technical

Port SpeedFusion Test (TCP/UDP 16181 atau 5201) Terblokir:
SpeedFusion VPN Test pada Peplink memanfaatkan service internal berbasis iperf yang berjalan di port khusus (secara default port UDP/TCP 16181, atau pada versi firmware tertentu menggunakan port 5201 / 2760).
Meskipun control plane PepVPN/SpeedFusion berstatus Established (port 2760/4500), traffic pengujian speedtest ini dikirim via stream/port terpisah. Jika ISP dari Wi-Fi WAN 2.4 GHz atau firewall di sisi remote memblokir port test tersebut, stream socket gagal terbentuk.
Service Test Server di Remote Peer Hang / Nonaktif:
Di sisi endpoint remote (FusionHub / Peplink Balance lawan), proses internal yang bertugas melayani permintaan tes koneksi (test daemon) bisa jadi mengalami stuck atau tidak diizinkan di konfigurasi profile.
Isolasi Subnet / IP Forwarding Rule:
Peringatan switch internal dari screenshot pertama (WAN-to-WAN connection disabled) menunjukkan ada pembatasan routing internal yang mengisolasi traffic antar-interface.

Langkah Troubleshooting lanjutan

Tes Arah Berlawanan (Download Test):

* Ubah Direction dari Upload menjadi Download. Jika Download berhasil tetapi Upload gagal, penyebanya positif pemblokiran port outbound oleh ISP Wi-Fi WAN tersebut.

Restart SpeedFusion Profile / Tunnel:

* Di menu Status > SpeedFusion, lakukan Disable lalu Enable kembali pada profil VPN yang terhubung untuk me-refresh socket session di kedua sisi.

Cek Konfigurasi Remote Peer (FusionHub/Balance lawan):

* Pastikan pada remote router, opsi SpeedFusion Test Server diizinkan dan tidak di-block oleh Inbound Firewall Rules.

Coba Jalankan WAN Analysis Tool:

* Masuk ke menu System > Tools > WAN Analysis (jika ada pada versi firmware ini) untuk menguji throughput antar WAN secara langsung tanpa lalu lintas tunnel SpeedFusion.

ini skrinsut menampilkan IP

Screenshot ini memberikan kejelasan signifikan terkait struktur topologi dan akar masalah pengujian SpeedFusion Test yang gagal.

Analisis IP & Status Subnet Tunnel

IP Remote Peer (Tujuan Tunnel): 117.102.97.178:4500
Ini adalah Public IP dan port UDP 4500 dari perangkat remote (BAZAR EX PICADILY).
IP Local WAN (Wi-Fi WAN): 180.252.246.7:27156
Perangkat lokal menggunakan IP Publik dari penyedia Wi-Fi dengan port lokal UDP 27156 untuk berkomunikasi dengan remote.
Mekanisme Handshake (VPN Control Plane):
Jalur VPN terkoneksi (Established) karena paket keep-alive UDP skala kecil (terlihat dari Latency 7 ms) berhasil menembus port 4500.

Akar Masalah Pengujian VPN Test yang Gagal

Meskipun tunnel VPN utama berjalan pada port UDP 4500, pengujian internal SpeedFusion VPN Test (iperf engine Peplink) memerlukan alokasi data socket tambahan di port terpisah (secara default TCP/UDP 16181).

Faktor Utama Error Cannot start connection:

Pemblokiran Port 16181 oleh ISP / NAT:
Router ISP di sisi 180.252.246.7 (Wi-Fi WAN) atau firewall di sisi IP Publik Remote 117.102.97.178 mengizinkan port VPN utama (4500), namun memblokir traffic outbound/inbound port 16181 (port khusus untuk fitur test iperf Peplink).
Efek Warning Switch internal (WAN-to-WAN temporary block):
Peringatan "The WAN-to-WAN connection disabled by the switch is temporary..." di bagian bawah mengonfirmasi bahwa switch/firmware lokal menahan forwarding paket data antar-WAN internal selama 15 menit. Hal ini secara langsung mencegah traffic generator internal Peplink melempar paket stream ke interface Wi-Fi WAN.

Langkah Penyelesaian

Opsi 1 (Bypass Port Blocking): Masuk ke menu Status > SpeedFusion, klik profil MAX-OTG-192D-4092-874F-9A91, lalu ubah opsi Data Port atau tes enkapsulasi ke mode port lain jika firmware mendukung custom test port.
Opsi 2 (Tunggu Masa Cooldown Switch): Biarkan perangkat tanpa pengujian berulang selama 15 menit agar proteksi otomatis switch internal merilis blokir WAN-to-WAN tersebut.
Opsi 3 (Gunakan WAN Fisik Lain): Sambungkan salah satu Ethernet WAN (WAN 1/2) untuk mendapatkan IP lokal yang tidak terkena pembatasan NAT/Firewall ketat dari Wi-Fi WAN.

apakah ada sesuatu yang ganjil pada network setting ini ?

Pengaturan jaringan ini memiliki beberapa poin yang sangat tidak biasa dan berpotensi menimbulkan masalah routing serius.

Hal Ganjil & Potensi Masalah

Penggunaan Public IP Address untuk VLAN Lokal (MAX_BR2 & SIL):
VLAN 220 (MAX_BR2): Menggunakan 7.19.0.1/16 (Public IP milik DoD Network Information Center / militer AS).
VLAN 280 (SIL): Menggunakan 7.44.0.1/24 (Public IP milik DoD Network Information Center).
Masalah: Alokasi subnet privat seharusnya menggunakan standar RFC 1918 (10.0.0.0/8, 172.16.0.0/12, atau 192.168.0.0/16). Jika klien di VLAN ini mencoba mengakses IP publik berawalan 7.x.x.x di internet, traffic tidak akan pernah keluar karena dianggap sebagai IP lokal oleh router.
Penggunaan Static Route untuk Default Gateway (0.0.0.0/0):
Di tabel Static Route Settings, terdapat entry 0.0.0.0 /0 yang diarahkan ke Gateway 10.238.239.41.
Masalah: Pada arsitektur Peplink/Balance/MAX, default route menuju internet secara normal ditangani otomatis oleh Outbound Policy dan WAN Link Controller. Memaksa Default Route (0.0.0.0/0) via Static Route ke IP LAN/PTP (10.238.239.41) dapat mengacaukan alur pemrosesan SpeedFusion, Multi-WAN load balancing, serta pengalihan health check WAN.
Format Notasi IP pada Untagged LAN (10.238.239.42/30):
Subnet privat /30 hanya memiliki 2 IP host usable (.41 dan .42).
Di konfigurasi ini, Router dipasang IP .42 dan Static Route menembak .41. Jika ini adalah point-to-point (PtP) link ke router lain, alokasi ini valid secara subnetting, namun membuat LAN utama (VLAN 1) tidak memiliki sisa IP untuk client/device lain.
Format Penulisan Subnet Mask pada LAN List:
Interface PORT MNG, MAX_BR2, dan SIL menampilkan format IP gateway tanpa subnet mask di belakangnya (misal 7.19.0.1/16 ditulis sebagai IP tunggal), berbeda dengan LAN [1] yang ditulis lengkap dalam format CIDR (10.238.239.42/30).

Rekomendasi Perbaikan

Ubah IP VLAN 220 & 280 ke RFC 1918: Ganti blok IP 7.19.x.x dan 7.44.x.x ke rentang privat seperti 10.19.0.1/16 atau 172.19.0.1/16.
Hapus Static Route 0.0.0.0/0: Biarkan Peplink mengelola default gateway melalui konfigurasi WAN dan Outbound Policy bawaan.
Pastikan Peran VLAN 1: Jika VLAN 1 digunakan untuk koneksi Point-to-Point ke core router/firewall lain, batasan /30 sudah benar. Namun jika ditujukan untuk host lokal, perluas subnet-nya (misal ke /24).

Saya ingin membahas secara mendalam PoC yang sedang dilakukan, Untuk test akan dilakukan antara unit SDX dengan 1 remote dulu, berupa B20x

bisa kita mulai ?

Bisa, mari kita bahas. Berdasarkan temuan konfigurasi dari pengujian sebelumnya, integrasi PoC antara Balance SDX (Core/Hub) dan Balance 20X (Remote Edge) perlu diselaraskan dari sisi arsitektur dan routing.

Topologi & Parameter Dasar PoC

Core / Hub Unit: Peplink Balance SDX
Remote / Edge Unit: Peplink Balance 20X
VPN Protocol: SpeedFusion / PepVPN (Layer 3 Tunnel)
Kebutuhan Utama: Bonding / Unbreakable VPN, Outbound Policy, dan verifikasi throughput internal.

Poin Kunci Persiapan PoC

Pembersihan Routing & IP Space (SDX & B20X):

* Pastikan Static Route 0.0.0.0/0 manual di tabel LAN ditiadakan agar lalu lintas dialirkan melalui PepVPN/SpeedFusion Engine dan Outbound Policy secara presisi. * Pastikan subnet LAN di B20X dan SDX tidak bentrok dan menggunakan IP privat RFC 1918 (bukan IP publik seperti blok 7.x.x.x).

Handshake & Port Enkapsulasi:

* Control Plane (PepVPN Handshake): UDP 2760 / UDP 4500 (Data Encryption). * SpeedFusion Test Service (iPerf Engine): Pastikan port TCP/UDP 16181 (atau 5201) diizinkan secara inbound di sisi SDX jika pengujian dilakukan dari B20X.

Inbound & Outbound Policy:

* Di sisi B20X, arahkan traffic spesifik subnet melalui PepVPN Profile menuju SDX. * Di sisi SDX, atur Inbound Rules dan Internal Subnet Forwarding agar VLAN di B20X dapat saling menjangkau LAN SDX secara seamless.

Silakan informasikan skenario pengujian pertama yang ingin dieksekusi (misal: failover test, SpeedFusion bonding throughput test, atau latency/jitter mitigation), atau jika ada parameter WAN spesifik yang terpasang di B20X saat ini.

Nah,
masalahnya saya harus mensimulasikan kondisi keadaan real yang diminta user/customer

Maka,
akan infokan setting yang real terlebih dahulu, nanti bilamana terjadi penyimpangan atau setting yang aneh-aneh atau melanggar routing ideal, bisa kita diskusikan

Intinya begini:
- mereka memakai SpeedFusion, jika toko 100 maka SF profile pun akan 100 dan seterusnya
- mereka dengan sengaja ( alasan klasik ) mengeset IP di tiap remote sama IP nya
- lalu mereka mengontrol via NAT

Saya berikan satu-satu contoh konfigurasi, ditunggu

Ini skenario klasik di enterprise/retail skala besar: Overlapping Subnet/IP pada Remote Site (Multi-Site Same IP Architecture) yang ditangani menggunakan SpeedFusion + NAT (Virtual IP / One-to-One NAT / Many-to-One NAT) di sisi Hub/HQ.

Secara teori arsitektur ini memang valid untuk menghindari re-IP di ratusan cabang, meskipun dari sudut pandang clean networking menambah lapisan kompleksitas (NAT overhead & troubleshooting).

Silakan bagikan konfigurasi atau gambar setting-an pertamanya (apakah dari sisi B20X Remote, SDX Hub, atau SpeedFusion Profile & NAT Mapping-nya). Nanti kita bedah alur trafik, potensi bottleneck, serta letakPenyimpangan routing-nya bersama. Ditunggu!

ya, alasan mereka, saat membuka toko kadang sekaligus banyak dan itu tak resource jika mengirim orang IT satu-satu, tempat akan tersebar di seluruh propinsi di masa yang akan datang, tak mau pusing dengan SDM dan ingin cepat/gampang

Strategi tersebut sangat lumrah digunakan oleh perusahaan retail, franchise, atau F&B yang sedang mengejar ekspansi cepat (aggressive rollout). Ketika targetnya adalah membuka puluhan hingga ratusan cabang baru secara bersamaan di berbagai daerah, model pengiriman teknisi IT internal (field engineer) secara on-site memang menjadi bottleneck terbesar.

Berikut adalah analisis mengapa alasan mereka sangat masuk akal secara bisnis, serta solusi arsitektur IT yang paling ideal untuk mengakomodasi kebutuhan tersebut:

Realita Operasional: Mengapa IT Konvensional Gagal di Skala Ini

Tantangan Utama	Dampak Jika Mengirim IT Manual
Beban SDM & Overhead	Gaji, tiket pesawat, akomodasi, dan travel allowance untuk teknisi melambung tinggi.
Time-to-Market Lambat	Pembukaan toko tertunda hanya karena menunggu jadwal penerbangan atau kedatangan teknisi.
Keterbatasan Skill Lokal	Merekrut staf IT lokal di setiap kota butuh waktu lama dan kualitasnya tidak merata.
Maintenance Complex	Jika ada perangkat bermasalah di daerah terpencil, toko bisa tidak beroperasi hari itu juga.

Solusi Arsitektur: Zero-Touch Deployment & Cloud Management

Untuk menjawab kebutuhan "tanpa pusing SDM, cepat, dan gampang", sistem IT yang diterapkan wajib berbasis Zero-Touch Provisioning (ZTP) dan Centralized Cloud Management.

1. Zero-Touch Provisioning (ZTP)

Cara Kerja: Perangkat (Router/Firewall/Access Point) dikirim langsung dari distributor/vendor ke alamat cabang baru tanpa perlu dibuka atau dikonfigurasi terlebih dahulu oleh tim IT.
Eksekusi di Lapangan: Staf toko (atau teknisi lokal pihak ketiga) hanya perlu melakukan plug and play: tancapkan kabel listrik dan kabel WAN/internet.
Proses Otomatis: Begitu router terhubung ke internet, perangkat akan otomatis menarik konfigurasi (SSID Wi-Fi, IP subnet, rule firewall, VPN) dari server cloud pusat secara remote.

2. Standardisasi Hardware "Plug-and-Play"

Kit Perangkat Standar: Buat 1 box standar untuk setiap toko (misal: 1 Router Cloud + 1 AP + 1 Switch + IP Camera + POS Terminal).
Koneksi Seluler Dual-SIM / Bonding: Menggunakan router dengan modem LTE/5G bawaan. Ini menghilangkan keterlambatan akibat menunggu pemasangan kabel internet fixed line (Indihome/Biznet/dll) dari ISP lokal. Toko bisa langsung jualan di hari H menggunakan koneksi seluler.

3. Outsource Deployment (Vendor Pihak Ketiga)

Untuk pekerjaan fisik (tarik kabel UTP, pasang bracket AP, pasang kamera CCTV), cukup gunakan vendor lokal cabling atau pihak ketiga (Managed Service Provider / MSP).
Vendor lokal hanya perlu mengerjakan fisik dan memverifikasi lampu indikator menyala, tanpa perlu tahu password atau konfigurasi jaringan internal.

Keuntungan Utama untuk Perusahaan

Kecepatan Scaling: Ratusan cabang bisa go-live serentak dalam hitungan hari, bukan bulan.
Rendahnya OPEX: Tidak perlu memelihara pasukan teknisi IT internal yang besar.
Visibilitas Terpusat: Tim IT HQ yang minim (cukup 2–3 orang) bisa memantau kesehatan seluruh jaringan toko se-Indonesia dari satu dashboard cloud tunggal.
Standardisasi Keamanan: Risiko kesalahan konfigurasi manusia (human error) di lapangan dapat ditekan hingga nol karena semua pola konfigurasi terkunci secara terpusat.

seebnarnya mereka nanti menggunakan 2 WAN , mungkin ke dua duanya IP publik.

untuk saat ini karena PoC tetapi simulasi real:

Connection Type
Static IPIP Address
117.102.97.178Subnet Mask
255.255.255.240Additional IP Address
Default Gateway
117.102.97.177DNS Servers
203.142.82.222
203.142.84.222
Uptime
0 minutesMTU
1440
terlampir untuk LAN, abaikan yang PORT MNG, fokus 3 lainnya

Konfigurasi WAN dengan IP Publik dedicated (117.102.97.178/28) ini secara teknis sudah sangat solid untuk bertindak sebagai Hub/HQ Node (SDX). IP publik statis dengan latensi rendah dari ISP lokal ini ideal untuk menerima inbound SpeedFusion handshake dari cabang (B20X).

Namun, ada beberapa aspek kritis pada kombinasi parameter WAN dan LAN yang berpotensi menjadi masalah besar saat pengujian PoC.

Analisis Parameter WAN & LAN

MTU Size WAN (1440 Byte):
Nilai MTU diatur ke 1440. Jika WAN membawa encapsulation SpeedFusion (PepVPN overhead ± 19–40 byte tergantung enkripsi), effective path MTU untuk data kotor di dalam tunnel akan turun ke rentang 1400–1420.
Dampak: Jika client di cabang mengirim paket standar 1500 byte tanpa DF-bit (Don't Fragment), akan terjadi fragmentasi paket di level WAN Peplink yang dapat menurunkan throughput atau memicu masalah pada aplikasi sensitif (seperti transaksi POS/EDC).
Alokasi IP LAN yang Berbahaya (7.19.0.1/16 & 7.44.0.1/24):
Menggunakan rentang 7.x.x.x untuk VLAN internal (MAX_BR2 & SIL) di cabang/hub sangat tidak direkomendasikan. Blok IP ini terdaftar secara global sebagai milik US Department of Defense (DoD).
Dampak Ke Internet: Jika toko/cabang perlu mengakses layanan cloud, web publik, atau API payment gateway yang kebetulan berada di blok IP publik 7.0.0.0/8, Peplink akan menganggap traffic tersebut sebagai lokal LAN dan tidak pernah menyalurkannya ke WAN/Internet.
Dampak ke Overlapping Subnet NAT: Karena mereka berencana menyamakan IP di 100 toko dan mengontrolnya via NAT di Hub (SDX), pemakaian IP publik di LAN akan membuat tabel 1-to-1 NAT atau Many-to-1 NAT Peplink sangat rentan konflik (routing loop).
Untagged LAN /30 (10.238.239.42/30):
Subnet /30 ini sangat spesifik untuk Point-to-Point (PtP) link ke device lain (misal Core Switch atau Firewall eksisting).
Di dalam arsitektur Multi-site NAT Peplink, pastikan IP .41 (gateway lawan) terhubung langsung ke interface fisik tanpa terhalang switch unmanaged.

Rekomendasi Penyesuaian PoC

Atur MSS Clamping / Path MTU Discovery: Pastikan di setting PepVPN/SpeedFusion Profile, fitur Mss Clamping diaktifkan (misal di set ke 1360 atau auto) untuk menyesuaikan MTU WAN 1440.
Koreksi IP Space di PoC (Rekomendasi Utama): Edukasi customer untuk mengganti subnet 7.x.x.x ke privat RFC 1918 (misal 10.19.0.1/16 dan 10.44.0.1/24). Jika customer bersikeras tidak mau ganti karena alasan legacy, pastikan seluruh komunikasi dari/ke VLAN ini di-NAT sempurna sebelum menyentuh WAN.

Silakan dibagikan parameter berikutnya (misalnya SpeedFusion Profile atau NAT Mapping Rules di SDX) agar kita bisa melihat bagaimana mereka memetakan IP 7.19.x.x / 7.44.x.x yang identik ini dari sisi Hub.

saya akan lampirkan satu-satu agar jelas, mohon ditunggu.

lampiran satu
LAN profile

Konfigurasi ini menunjukkan bahwa untagged LAN utama difungsikan secara murni sebagai link Point-to-Point (PtP).

Analisis Detail Profile LAN

IP Address 10.238.239.42/30:
Subnet /30 (255.255.255.252) hanya menyediakan 2 IP usable (.41 dan .42).
Peplink memegang .42, sementara IP .41 (yang sebelumnya muncul di Static Route) dialokasikan untuk router/firewall/switch L3 internal di sisi pelanggan.
Inter-VLAN Routing (Tercentang):
Fitur ini mengizinkan Peplink melempar paket antar-VLAN lokal secara internal (LAN, PORT MNG, MAX_BR2, dan SIL).
DHCP Server (Tidak Aktif):
Sesuai untuk segmen PtP karena pengalamatannya bersifat statis dan tidak ditujukan langsung ke end-user client.

Catatan Catatan Arsitektur (Potential Issue)

Karena Inter-VLAN routing diaktifkan pada link PtP ini, traffic dari VLAN lain (7.19.0.0/16 dan 7.44.0.0/24) secara default dapat menyeberang ke subnet 10.238.239.40/30 tanpa halangan, kecuali dibatasi oleh Internal Network Firewall Rules.
Jika IP 10.238.239.42/30 ini juga akan disamakan/di-duplikasi di 100 toko remote, maka subnet PtP ini wajib ikut masuk ke dalam skema Virtual IP / NAT Mapping agar tidak memicu IP conflict di VPN hub.

Silakan dilanjutkan ke lampiran berikutnya.

MAX_BR2

silahkan sambil dikomentari atau apapun untuk pemahaman logika

Konfigurasi ini valid secara teknis untuk Web Admin Peplink/Pepwave, namun ada beberapa kejanggalan logika subnetting dan alokasi IP yang berpotensi memicu troubleshooting headache di lapangan.

Berikut bedah logika dan catatan kritis untuk skenario ini:

1. Kejanggalan Subnet Mask & DHCP Pool Range

IP Gateway: 7.19.0.1/16 (255.255.0.0)
DHCP Range: 7.19.3.1 s/d 7.19.3.254 dengan Subnet Mask 255.255.0.0 (/16)
Logika / Masalah:
Meskipun subnet mask di-set /16 (ruang IP 7.19.0.1 – 7.19.255.254 / 65.534 host), alokasi dinamik DHCP disempitkan secara manual hanya di subnet segmen 7.19.3.x (hanya 254 IP).
Jika tujuannya memang membatasi jumlah client DHCP maksimum 254 host, pendekatan ini bekerja. Namun, jika butuh jaringan seluas /16, membatasi pool hanya di .3.x membuat alokasi IP terasa tidak rapi (mengapa mulai dari 7.19.3.1 alih-alih 7.19.1.1 atau menggunakan subnet mask yang presisi seperti /24).

2. Konflik Logika DHCP Reservation vs DHCP Range

Tabel DHCP Reservation:
7.19.0.7
7.19.0.11
7.19.0.64
7.19.0.244
Logika / Masalah:
Semua IP yang di-reserve (7.19.0.x) berada di luar rentang DHCP Server (7.19.3.1 - 7.19.3.254).
Pada Peplink Web Admin, meletakkan DHCP Reservation di luar rentang DHCP Pool secara teknis diizinkan selama masih dalam satu Subnet Interface (7.19.0.0/16). Namun, secara best practice, IP static/reservation di luar pool lebih baik dikelola via Static IP Configuration di sisi client atau dimasukkan ke DHCP Exclusion Range jika berada di dalam pool, agar topologi tetap bersih dan mudah dibaca oleh admin lain.

3. Penggunaan Classful Public IP pada Private LAN (IP 7.x.x.x)

IP Interface: 7.19.0.1
Logika / Masalah:
Alamat 7.0.0.0/8 adalah Public IP Block milik US Department of Defense (DoD), bukan alokasi Private IP RFC 1918 (10.0.0.0/8, 172.16.0.0/12, atau 192.168.0.0/16).
Dampak: Client di VLAN 220 ini tidak akan bisa mengakses server/layanan publik asli di internet yang menggunakan blok IP 7.x.x.x karena router akan menganggap trafik tersebut sebagai lokal (terjebak di LAN).

4. Routing & DNS Specifics

Inter-VLAN Routing: Centang aktif (✓). VLAN 220 ini dapat berkomunikasi langsung layer 3 ke VLAN lain di Peplink tanpa terhalang firewall lokal (kecuali ada Internal Network Firewall Rules yang memblokirnya).
Static DNS Override: IP 33.33.3.251 dan 10.232.5.251 di-push manual ke client DHCP. Pastikan kedua IP resolver ini reachable via WAN / SpeedFusion tunnel internal.

Rekomendasi Penyesuaian (Best Practice):

IP Private RFC 1918: Ubah IP LAN/VLAN ke blok privat standar, contoh: 10.19.0.1/16 atau 172.19.0.1/16 untuk menghindari IP Conflict di internet.
Meresmikan Subnet Mask: Jika hanya membutuhkan ~250 IP untuk client DHCP, gunakan mask /24 (255.255.255.0) dengan gateway 7.19.3.1 (atau 10.19.3.1) agar konsisten dengan DHCP Range.

SIL

Konfigurasi VLAN 280 (SIL) ini secara umum jauh lebih rapi dan rapi secara struktur DHCP dibanding VLAN 220 sebelumnya, meski masih membawa isu IP Publik pada LAN.

Analisis Detail & Logika Konfigurasi

Struktur Subnetting & DHCP Rapi (/24):
Gateway: 7.44.0.1/24
Range DHCP: 7.44.0.2 – 7.44.0.254 (/24)
Analisis: Sangat presisi. Penggunaan subnet mask /24 pada IP interface konsisten dengan alokasi DHCP Pool-nya. Tidak ada pemborosan alamat IP atau mis-match mask seperti pada MAX_BR2.
DHCP Reservation Berada di Dalam Pool:
Alokasi IP Statis (7.44.0.4, 7.44.0.10, 7.44.0.11) berada di dalam rentang DHCP (7.44.0.2 – 7.44.0.254).
Analisis: Ini penanganan reservation yang standar pada Peplink. Router otomatis menandai IP ini agar tidak diberikan ke device dinamis lain.
DNS Resolver Kustom:
DNS Server: 33.33.3.253 dan 10.232.5.251
Analisis: Sama seperti VLAN 220, DNS ini kemungkinan mengarah ke server DNS internal/private perusahaan via VPN tunnel. (Perhatikan bahwa 33.33.3.253 juga merupakan alokasi IP Publik milik DoD, sehingga pastikan routing ke IP ini dipaksa lewat SpeedFusion VPN).

Isu Kritis yang Tetap Melekat

Penggunaan IP Publik DoD (7.44.0.0/24):
Seperti pada VLAN MAX_BR2, penggunaan IP Publik untuk LAN lokal di 100 cabang akan memicu IP overlap jika ada akses ke server internet publik di blok 7.x.x.x.
Arsitektur 100 Remote "Same IP":
Jika VLAN SIL (7.44.0.0/24) ini akan di-copy paste persis sama nilainya ke 100 toko, maka ketika semua B20X terhubung via SpeedFusion ke Hub SDX, SDX tidak akan bisa membedakan mana toko A dan toko B tanpa Virtual IP / One-to-One NAT pada SpeedFusion Profile masing-masing remote.

Silakan dilanjutkan ke lampiran berikutnya (misalnya SpeedFusion Profile, Static Route, atau NAT Mapping).

saya ambil 1 profil SF tunnel aktif / established, lupakan dulu profil yang lain

Konfigurasi pada PepVPN / SpeedFusion Profile ini mengungkap jawaban paling krusial mengenai bagaimana mereka menangani masalah "100 Remote Subnet Sama" di level VPN.

Analisis Parameter Profil SpeedFusion

Data Port (UDP 4500):
Port enkapsulasi utama menggunakan UDP 4500 (IPsec NAT-Traversal standard port). Ini pilihan yang sangat baik untuk menembus NAT dari berbagai provider internet/cellular di remote site.
Remote IP Addresses / Host Name (117.102.97.178):
B20X menembak ke IP Publik SDX Hub di 117.102.97.178.

Kunci Jawaban Arsitektur: Section "Virtual Network Mapping"

Di bagian paling bawah screenshot, mekanisme Virtual Network Mapping diaktifkan secara spesifik untuk memecahkan overlapping IP:

Physical Network (IP Riil Cabang): 7.44.0.0 /24 (VLAN SIL di B20X)
Virtual Network (IP Terjemahan untuk Hub): 10.236.192.0 /24

Cara Kerja Logika NAT di Tunnel Ini

Translasi Otomatis oleh Peplink:

* Di lokal B20X (toko), perangkatan/client tetap menggunakan IP 7.44.0.x/24. * Begitu paket data melintasi tunnel SpeedFusion menuju SDX Hub, Peplink B20X secara otomatis mengubah (NAT) blok IP 7.44.0.x menjadi 10.236.192.x.

Solusi untuk 100 Toko:

* Toko 1: Physical 7.44.0.0/24 $\rightarrow$ Virtual 10.236.192.0/24 * Toko 2: Physical 7.44.0.0/24 $\rightarrow$ Virtual 10.236.193.0/24 * Toko 3: Physical 7.44.0.0/24 $\rightarrow$ Virtual 10.236.194.0/24, dan seterusnya.

Mengapa HQ/SDX Aman dari Clash:

* SDX Hub di HQ tidak pernah melihat IP 7.44.0.0/24 dari cabang. SDX hanya melihat IP unik 10.236.192.0/24 untuk toko ini. * Ini menjelaskan mengapa tim IT mereka bisa dengan santai men-duplikasi IP 7.44.0.0/24 ke 100 toko tanpa membuat VPN tumbang (IP Conflict).

Catatan Kritis & Potensi Masalah pada PoC

VLAN MAX_BR2 (7.19.0.0/16) Belum Di-map:
Di profil ini, Virtual Network Mapping baru dibuat untuk 7.44.0.0/24 (SIL).
Jika traffic dari VLAN MAX_BR2 (7.19.0.0/16) dilewatkan ke tunnel ini tanpa Virtual Network Mapping tersendiri, SDX Hub akan menerima IP mentah 7.19.x.x. Begitu Toko #2 terhubung dengan IP 7.19.x.x yang sama, routing di SDX akan langsung flapping / bentrok.
Akses dari HQ ke Toko (Inbound Initiated Traffic):
Jika server di HQ ingin melakukan ping atau RDP ke komputer kasir di toko ini, HQ wajib menembak IP Virtual-nya (10.236.192.x), bukan IP asli 7.44.0.x.

Silakan lanjut ke screenshot atau konfigurasi berikutnya (misalnya Outbound Policy atau Inbound Mapping dari sisi SDX Hub)!

saya lampirkan lagi ini ( network )

Tampilan halaman Network > LAN Settings ini makin memperjelas peta routing dan isolasi trafik pada perangkat remote (B20X).

Analisis Parameter & Temuan Kunci

Virtual Network Mapping (Kosong pada Tabel LAN Global):
Tabel One-to-One NAT dan Many-to-One NAT di tingkat lokal LAN ini berstatus kosong.
Artinya: Mekanisme translasi IP Virtual (10.236.192.0/24) tidak dieksekusi secara lokal pada interface LAN, melainkan ditangani secara spesifik di dalam enkapsulasi profil SpeedFusion VPN Tunnel itu sendiri.
Static Route Default Gateway (0.0.0.0/0 via 10.238.239.41):
Terdapat Static Route manual yang memaksa seluruh trafik default (0.0.0.0/0) terlempar ke IP Gateway .41 pada segmen PtP (10.238.239.42/30).
Potensi Bentrok dengan SpeedFusion: Jika seluruh trafik default dilempar ke router/switch internal via .41, paket data dari VLAN lokal (MAX_BR2 & SIL) bisa jadi bypass dari engine SpeedFusion/Outbound Policy kecuali diatur secara ketat menggunakan Outbound Policy Managed by SpeedFusion.
Status DNS Proxy (Enabled):
DNS Proxy diaktifkan tanpa DNS Caching dan tanpa Google Public DNS. Artinya, Peplink murni bertindak sebagai forwarder query DNS dari client ke DNS Server kustom (33.33.3.253 / 10.232.5.251) yang di-push via DHCP.

Ringkasan Alur Trafik (Flow Logic)

Client di toko tersambung ke VLAN 280 (SIL) dan menerima IP di rentang 7.44.0.x/24.
Saat client berkomunikasi ke HQ via SpeedFusion, Peplink tidak melakukan NAT di level LAN lokal, melainkan melempar paket ke profil SpeedFusion VPN.
Di dalam SpeedFusion Profile, fitur Virtual Network Mapping mengubah IP 7.44.0.x/24 menjadi 10.236.192.x/24 sebelum keluar menuju SDX Hub (117.102.97.178).
SDX Hub menerima trafik seolah-olah berasal dari subnet unik 10.236.192.0/24, sehingga aman dari IP collision dengan 99 toko lainnya.

Silakan dilanjutkan ke lampiran konfigurasi berikutnya (misalnya Outbound Policy, Inbound Firewall Rules, atau Tampilan Setting dari Sisi SDX Hub).

saya sudah melewati beberapa hari dan berbagai macam test dan cek lapangan, apakah bisa dilanjutkan . Saya bisa berikan tangkapan layar terbaru dan hasil pada mode produksi. Kebetulan saya masih punya beberapa akses

Bisa, mari kita lanjutkan. Informasi langsung dari mode produksi (live environment) dan pengujian lapangan selama beberapa hari terakhir ini sangat berharga untuk memvalidasi arsitektur jaringan secara riil.

Silakan bagikan tangkapan layar terbaru beserta temuan atau kendala yang ditemui di lapangan (baik dari sisi SDX Hub, B20X Remote, maupun perilaku trafik di mode produksi). Nanti kita bedah bersama untuk memastikan sistem siap di-scale ke 100 toko tanpa kendala routing. Ditunggu!

saya akan mulai secara bertahap untuk kondisi real saat ini, tahap demi tahap

1. WAN
- saat ini hanya menggunakan 1 WAN ( sengaja oleh pelanggan, alasannya mereka menggunakan internal DNS, nanti kita lihat kasus nyata ) 
- untuk catatan mereka punya 2 WAN dengan IP publik

Sangat menarik. Dari tangkapan layar WAN Connection Status, terlihat jelas:

WAN 1: No Cable Detected (Down/Disambung).
WAN 2: Connected (Active) dengan IP Publik 117.102.97.178.

Analisis Alasan Pelanggan (Internal DNS & Single WAN):

Maksud Pelanggan: Pelanggan sengaja mematikan/tidak mencolokkan WAN 1 karena khawatir query Internal DNS (33.33.3.253 / 10.232.5.251) akan bocor atau ter-route secara acak (asymmetric routing) jika 2 WAN aktif bersamaan tanpa konfigurasi policy yang tepat.
Potensi Masalah/Mispersepsi Pelanggan:
Di ekosistem Peplink, menonaktifkan WAN 2 justru menghilangkan keunggulan utama SpeedFusion (seperti Hot Failover, Bandwidth Bonding, dan WAN Smoothing).
Masalah resolusi Internal DNS di Multi-WAN sebenarnya tidak perlu diselesaikan dengan cara mematikan WAN 1, melainkan cukup ditangani via Outbound Policy (Enforced Rule) atau DNS Forwarding yang memaksakan query IP DNS Server tersebut masuk ke tunnel SpeedFusion VPN.

Silakan dilanjutkan ke Tahap 2 (misalnya tampilan Outbound Policy, PepVPN/SpeedFusion Status terbaru, atau LAN/Routing di kondisi produksi saat ini). Ditunggu!

info saja,
unit lama mereka BPL-2500 dikatakan fix bisa hingga 4000 peers.
saat ini sementara di aktifkan pada tipe SDX ( maksimum 500 peers dengan add on license ).

Mesin SDX ini cukup tahan, tetapi baru sekitaran 200 peers established, dashboard unit masih terlihat aman, CPU tidak merah.

contoh isi Profile SDX ( aggregator ):

setelah ini saya infokan profile untuk remote pasangan ini.

Silahkan di bahas atau jelaskan dari tangkapan layar saya untuk 1 profil ini, preshared key memang sengaja mereka buat, setahu saya selama mode enkripsi, tak wajib isi PSK, tapi mereka ber alasan agar tak bisa di tembus unit yang mencoba - coba tapi tak diperbolehkan

Penjelasan teknis terkait tangkapan layar SpeedFusion VPN Profile di sisi SDX (Aggregator/Hub) serta tanggapan mengenai kapasitas unit dan Pre-Shared Key (PSK).

Analisis Kapasitas Perangkat (BPL-2500 vs SDX)

BPL-2500 vs SDX: Balance 2500 memang dirancang untuk skala enterprise core besar (mendukung hingga 4.000 PepVPN peers). Namun, Peplink SDX merupakan arsitektur modular hardware modern yang jauh lebih efisien dari sisi pemrosesan enkripsi.
Performa 200 Peers di SDX: Hasil pengamatan Anda bahwa CPU SDX tetap stabil di 200 peers sangat wajar. Peplink SDX memisahkan modul enkripsi hardware dengan lancar, sehingga 200–500 peers aktif tidak akan membebankan CPU secara signifikan selama throughput per tunnel terkontrol.

Analisis Konfigurasi Profil SpeedFusion di SDX Hub

Penggunaan Pre-Shared Key (PSK):
Fakta Teknis: Enkripsi 256-bit AES menangani proteksi kerahasiaan data di jalan, tetapi Authentication (Remote ID + PSK atau X.509 Certificate) menangani identitas. Tanpa PSK atau Sertifikat, siapapun yang mengetahui Serial Number / Remote ID SDX bisa mencoba melakukan handshake PepVPN.
Alasan Pelanggan: Tindakan pelanggan mengisi Pre-Shared Key sudah sangat tepat. Ini memberikan lapisan otentikasi ganda (Mutual Authentication). Unit remote yang mencoba connect wajib memiliki Remote ID yang cocok dan PSK yang sesuai, mencegah unauthorized device membentuk tunnel ke SDX HQ.
NAT Mode di-Centang ke VLAN MAX_BR2 (220):
Pengaturan ini memaksa semua trafik yang keluar dari tunnel VPN ini menuju jaringan internal HQ untuk di-NAT menggunakan IP dari interface VLAN MAX_BR2 (220).
Dampak: Perangkat di HQ akan melihat trafik cabang seolah-olah berasal dari IP lokal VLAN 220 milik SDX. Ini menyembunyikan IP cabang asli dan menyederhanakan routing di internal HQ.
Traffic Distribution Mode (Dynamic Weighted Bonding):
SDX siap menerima multiple WAN dari remote untuk di-bond secara aktif.
Packet Jitter Buffer (150 ms): Disiapkan untuk menstabilkan variasi latency (jitter) dari koneksi remote site, sangat berguna jika remote menggunakan koneksi seluler/Kabel dengan latensi tidak stabil agar urutan paket data tidak berantakan (out-of-order packets).

Silakan dilanjutkan untuk membagikan tangkapan layar profil dari sisi remote pasangannya agar bisa kita bandingkan parameternya!