OrcaMonitorOrcaMonitor
Get Started
Complete tutorial

Network connectivity guide

WireGuard, IPsec, cloud firewall, routing — end to end

Connect your on-prem networks to your OrcaMonitor cloud instance. Follow WireGuard when you can install an agent on Linux, or IPsec when you terminate VPN on FortiGate, Cisco, Palo Alto, or similar firewalls. Then lock down public access with Cloud Firewall and advertise LAN routes.

Open Network Peers Open IPsec

1. Choose WireGuard or IPsec

OrcaMonitor gives you two ways to reach on-prem networks from your cloud instance. Pick one primary path (you can use both later if needed).

  1. 1

    WireGuard — no firewall required

    Best when you can install a small agent on a Linux server inside your LAN (Ubuntu, Debian, Rocky, AlmaLinux, RHEL, Fedora). The server dials out; you usually do not open inbound ports on your edge firewall.

    Tip: Use this for labs, branch offices without a managed firewall, or any Linux host that can run WireGuard.

  2. 2

    IPsec — terminate on your firewall

    Best when you already have FortiGate, Cisco, Palo Alto, or another IKEv2 firewall. You create a site-to-site tunnel; OrcaMonitor applies the matching side on your cloud VPS.

    Tip: Use this for corporate edge firewalls and compliance environments that standardize on IPsec.

  3. 3

    Where to start in the product

    Sign in → Dashboard → Network. Provision the mesh and add devices from Peers, or open the IPsec tab for firewall tunnels. Cloud Firewall is a separate Dashboard tab (Vultr allow-list for your instance).

2. Prerequisites

Have these ready before you start either path.

  1. 1

    Active cloud instance

    Your OrcaMonitor cloud deployment should be live (or at least provisioning complete). Networking features attach to that VPS.

  2. 2

    Know your LAN CIDR

    Example: 10.10.0.0/24 or 192.168.1.0/24. For IPsec you will enter this as the remote subnet. Avoid overlapping the cloud overlay (CGNAT 100.64.0.0/10).

  3. 3

    Admin access

    WireGuard path: sudo on a Linux host. IPsec path: rights to create a site-to-site VPN on your firewall. Dashboard: tenant owner/admin role.

  4. 4

    Public IP (IPsec)

    For a static remote gateway, know your firewall WAN IP. If the remote side is dial-up / dynamic, enable Dynamic remote gateway in the wizard.

3. WireGuard mesh — step by step

This builds a private WireGuard overlay (OrcaNet) between your cloud VPS and on-prem peers. Overlay addresses are allocated from 100.64.0.0/10 (typically a /24 per tenant). Default listen port is UDP 51820.

  1. 1

    Open Peers

    Dashboard → Network → Peers. Provision the mesh there, then add devices from the same tab, or use the IPsec tab if your tunnel terminates on a firewall.

  2. 2

    Provision the mesh

    Click Provision Network (or equivalent). This creates your private WireGuard overlay and coordinator state. Wait until the UI shows the network is ready.

    Tip: You only do this once per tenant.

  3. 3

    Add a laptop / workstation peer (optional)

    Go to Peers → Add Peer → choose Manual config file. Name the peer, download the .conf, import it into the official WireGuard app (Windows, macOS, iOS, Android, or Linux), and activate the tunnel.

    Tip: Official clients: https://www.wireguard.com/install/

  4. 4

    Connect an on-prem Linux gateway (recommended)

    On Peers → Add Peer → Auto-install script, create an install token and copy the curl command. On the Linux server run: curl -sSL '<install URL>' | sudo bash

    Tip: The token is single-use and typically valid for 24 hours. The script installs wireguard-tools, generates keys on the server, registers the peer, and can enable MASQUERADE so cloud → LAN traffic works.

  5. 5

    Confirm the peer is online

    Peers tab should show the new peer with an overlay IP. Open the peer detail to download config again, view routes, or toggle gateway/masquerade if needed.

  6. 6

    Advertise your LAN with a route

    Go to Routes → Add route. Set an identifier (e.g. hq-lan), the LAN CIDR (e.g. 10.10.0.0/24), and select the Linux peer as the routing peer. Traffic for that CIDR is forwarded through that peer.

    Tip: Without a route, mesh peers can talk to each other on the overlay, but the cloud cannot reach your private LAN subnets.

  7. 7

    Optional: Networks & access policies

    Add routes from the peer that forwards them: open a peer (Peers → click its name), go to Network Routes, and add a route for the remote LAN's CIDR. The mesh IP for each peer is assigned automatically — you only add routes for networks behind it.

4. IPsec site-to-site — step by step

OrcaMonitor creates the cloud side of an IKEv2 tunnel and gives you values (and vendor snippets) to paste into FortiGate, Cisco, Palo Alto, or Linux/strongSwan.

  1. 1

    Open IPsec

    Dashboard → Network → IPsec → Create IPsec Tunnel.

  2. 2

    Step 1 — Name & remote gateway

    Enter a tunnel name (e.g. HQ-Forti). Uncheck Dynamic if your firewall has a fixed WAN IP and enter that IP. Leave Dynamic enabled for dial-up / changing WAN addresses.

  3. 3

    Step 2 — Authentication

    IKE version is IKEv2 with Pre-shared Key. The PSK is generated when you create the tunnel — you will copy the same PSK onto the firewall.

  4. 4

    Step 3 — Subnets (interesting traffic)

    Remote address = your LAN CIDR (e.g. 10.10.0.0/24). Local address = OrcaMonitor side (leave empty to auto-assign a /30 from the 100.65.x.x range).

    Tip: On the firewall, Local = your LAN, Remote = the OrcaMonitor local CIDR shown after create.

  5. 5

    Step 4 — Crypto (Compatible preset)

    Phase 1: AES-256-CBC / SHA256 / DH14 / IKEv2. Phase 2: AES-256-CBC / SHA256 / PFS14. NAT-T: On (UDP 4500).

    Tip: Match these proposals exactly on FortiGate / Cisco / Palo Alto “Compatible” style profiles.

  6. 6

    Step 5 — Create & Apply to VPS

    Review settings, then Create & Apply to VPS. OrcaMonitor pushes the tunnel to your cloud instance.

  7. 7

    Configure your firewall

    In the tunnel detail panel: copy Remote Gateway (OrcaMonitor VPS), paste the Pre-shared Key, set Local = your LAN CIDR and Remote = cloud local CIDR, then apply Compatible Phase 1/2. Download FortiGate / Cisco / Palo Alto / Linux snippets if you prefer CLI.

  8. 8

    Firewall policy & routing

    Allow the VPN interface to forward between your LAN and the OrcaMonitor remote subnet. Add a static route (or rely on the VPN route) so return traffic to the cloud subnet goes into the tunnel. Allow UDP 500 and UDP 4500 (NAT-T) on the WAN if your policy set is restrictive.

  9. 9

    Wait for Up

    Status should move to Up with traffic counters. Use Resync if you changed firewall settings and need the cloud side reapplied.

5. Cloud firewall (instance allow-list)

Dashboard → Firewall manages the cloud VPS firewall (inbound allow rules). This is separate from WireGuard/IPsec. Use it to whitelist on-prem or operator IPs for HTTPS/API access to your instance.

  1. 1

    Open Cloud Firewall

    Dashboard → Firewall. Review existing rules (protocol, port, source CIDR).

  2. 2

    Add a rule

    Choose TCP or UDP, set a port (or use presets such as HTTPS 443, HTTP 80, API 8080), and enter a source CIDR (e.g. 203.0.113.0/32 for a single IP). Save.

    Tip: Port 22 is reserved for system break-glass access and cannot be managed from this UI.

  3. 3

    Tighten sources

    Prefer specific office / jump-host CIDRs over 0.0.0.0/0 when possible. Remove rules you no longer need.

  4. 4

    How this relates to tunnels

    WireGuard and IPsec carry private traffic over the VPN. Cloud Firewall controls who can hit public ports on the VPS itself (web UI, APIs). You usually need both: VPN for LAN reachability, firewall rules for admin access patterns.

6. Networks, routes & policies

After the tunnel or mesh is up, use Network sub-tabs to control what is reachable.

  1. 1

    Peers

    Inventory of WireGuard devices: status, overlay IP, gateway flag, config download, install scripts.

  2. 2

    Networks

    Map an environment (LAN, VPC, office) onto the mesh. Add resources (single IP, CIDR, domain, wildcard) and attach access policies (protocol + ports) to groups.

  3. 3

    Routes

    Advertise CIDRs via a routing peer (identifier + range + peer + metric). Required for cloud → on-prem subnet reachability over WireGuard.

  4. 4

    IPsec vs routes

    IPsec interesting traffic is defined by the tunnel local/remote LAN CIDRs. WireGuard uses Routes (+ optional Networks policies). Do not invent conflicting overlapping advertisements without a clear design.

7. Verify connectivity

Confirm the path end to end after setup.

  1. 1

    UI status

    WireGuard: peer shows online. IPsec: tunnel Status = Up with non-zero traffic after a test. Firewall: new rule appears in the list.

  2. 2

    From cloud toward LAN

    From a host that can reach the overlay (or from tools inside OrcaMonitor that target on-prem IPs), ping or TCP-check a known LAN address that should be routed.

  3. 3

    From LAN toward cloud

    From an on-prem host, reach the OrcaMonitor local/tunnel address or overlay IP as documented in the peer/tunnel detail. Ensure firewall policies allow return traffic.

  4. 4

    Application check

    Point monitoring / SNMP / agent targets at on-prem device IPs. Alerts or discovery succeeding is the real acceptance test.

8. Troubleshooting

Common failures and what to check first.

  1. 1

    WireGuard peer never comes online

    Confirm the install command used a fresh token, the host has outbound internet, wireguard kernel module / tools installed, and time is synced (NTP). Re-download config if you regenerated keys.

  2. 2

    Mesh up but cannot reach LAN

    Add a Route for the LAN CIDR via the gateway peer. On the Linux peer, confirm IP forwarding (net.ipv4.ip_forward=1) and MASQUERADE/NAT for cloud→LAN if required by your design.

  3. 3

    IPsec stays Down

    Match Phase 1/2 exactly (AES-256-CBC, SHA256, DH14/PFS14, IKEv2). Confirm PSK identical both sides. Open UDP 500/4500. Check local/remote CIDRs are swapped correctly on the firewall vs OrcaMonitor. Use Resync after edits.

  4. 4

    Overlapping subnets

    If your LAN overlaps 100.64.0.0/10 or the auto local /30, renumber or pick a non-overlapping remote LAN. Overlaps break routing silently.

  5. 5

    Cloud UI unreachable

    That is usually Cloud Firewall (Dashboard → Firewall), not the VPN. Whitelist your current public IP for TCP 443.

9. Ports & reference

Quick reference for firewall and tunnel designers.

  1. 1

    WireGuard

    UDP 51820 (default listen). Overlay: CGNAT 100.64.0.0/10. Peer install: GET /api/orcanet/install/<token>/install.sh (single-use token).

  2. 2

    IPsec / IKEv2

    UDP 500 (IKE), UDP 4500 (NAT-T). Crypto Compatible: Phase 1 AES-256-CBC / SHA256 / DH14 / IKEv2; Phase 2 AES-256-CBC / SHA256 / PFS14. Auth: pre-shared key.

  3. 3

    Cloud firewall UI

    Customer-managed allow rules for TCP/UDP ports to the VPS. Port 22 reserved. Prefer tight source CIDRs.

  4. 4

    Dashboard deep links

    Peers: /dashboard?tab=network · IPsec: /dashboard?tab=network&net=ipsec · Firewall: /dashboard?tab=firewall. Routes are added from a peer's Network Routes tab.

Ready to connect?

Open your dashboard Network tab and use Peers for WireGuard or IPsec for firewall tunnels. Need help? Enterprise support can review your tunnel design.

Go to dashboard Support
Explore the full platform

See every module, pricing tier, and deployment option on the OrcaMonitor overview.

Back to Overview