Network & connectivity

Two different problems wear the same name. The first is reaching your infrastructure: OrcaMonitor runs in the cloud and your devices are on a private address, so something has to bridge them. The second is diagnosing an existing tunnel when it stops passing traffic. This page covers both.

Reaching private infrastructure

Devices on RFC1918 addressing are not reachable from a cloud-hosted OrcaMonitor until a route exists. There are three ways to get one, and they are not mutually exclusive.

WireGuard peers and LAN routes

1. 1
   Add a peer

   OrcaMonitor generates the keypair and shows the install script. Run it on a Linux host inside the private network.

2. 2
   Declare the LAN routes

   Tell OrcaMonitor which private subnets sit behind that peer. Only declared routes are reachable — this is the allow-list, and it is deliberate.

3. 3
   Verify from the peer

   Bring the interface up and confirm a handshake. If the handshake succeeds but a device is unreachable, the route declaration is the thing to check.

IPsec from your edge device

Where your edge is a firewall you already run, terminate IPsec there and configure the matching parameters in OrcaMonitor. Proposals, DH group, PFS and lifetimes must agree on both ends — a mismatch is the single most common cause of a tunnel that comes up and then immediately drops.

Cloud firewall

The instance has its own public allow-list, which is separate from the VPN. Opening a tunnel does not open the firewall, and a healthy tunnel with a closed allow-list behaves exactly like a broken one.

Diagnosing tunnels

Once a tunnel exists, OrcaMonitor can diagnose it across the common enterprise firewalls instead of you remembering each vendor's IKE command. The agent picks the right command set from the platform string, so a Cisco IOS device gets IOS commands and an ASA gets ASA commands without being told.

vpn_tunnel_status    {"device": "bom-fw-01", "tunnel": "dc-to-dc"}
vpn_tunnel_diagnose  {"device": "bom-fw-01", "tunnel": "dc-to-dc"}
vpn_peer_reachability{"device": "bom-fw-01", "peer": "203.0.113.9"}
vpn_config_compare   {"device": "bom-fw-01", "peer_device": "dc-fw-02"}

A sane order to work in

Tunnel problems are usually one of six things. Working in this order avoids changing a working setting while chasing the actual fault.

1. 1
   Reachability

   Can each peer reach the other on UDP 500 and 4500? If not, nothing else matters — this is a routing or firewall problem, not an IKE problem.

2. 2
   Proposals

   Encryption, integrity, DH group and lifetime must match exactly on both ends. Compare the two configurations rather than reading them side by side by eye.

3. 3
   Pre-shared key or certificate

   A PSK mismatch and an expired certificate both present as phase 1 failing, so check the validity window before concluding the key is wrong.

4. 4
   Interesting traffic

   The tunnel only carries what the ACL or crypto map selects. Traffic that is uninteresting is not a tunnel failure.

5. 5
   NAT-T

   If either peer is behind NAT, encapsulation must be permitted. This presents as phase 1 succeeding and phase 2 never completing.

6. 6
   MTU

   A tunnel that establishes but drops large packets is an MTU or MSS problem. Small pings succeed, real traffic does not.

When a ticket mentioning tunnel keywords is opened, the agent's context is augmented with the vendor command set and the checklist, so the first diagnostic command it runs is the right one for that platform rather than a generic ping.