Server communication matrix

Each server that runs a Wanguard or Wansight Sensor, or a Wanguard Filter, must keep an always-on connection with its associated Console. The communication between servers is done via MySQL (optionally over SSL) and NFS, so when you use multiple servers make sure that TCP port 3306 (MySQL) is allowed through the firewall. If you store graph data in InfluxDB, or flow data and graphs in ClickHouse, on a separate server, their HTTP(S) interfaces (for example TCP port 8123 for ClickHouse) must be reachable as well.

Best practices when deploying software components on remote servers:

• An "event log" record is generated each time a remote system becomes unavailable. Enable Event Reporting in Configuration » Schedulers » Event Reporting to get automatic notifications about critical event log entries such as these, by email, syslog or SNMP.
• The WANsupervisor service stops and logs a syslog error when the Console’s MySQL server becomes unreachable. Make sure the service is restarted after a network error with a tool such as monit or daemontools — distributions that use systemd restart it automatically.
• If possible, connect the servers over out-of-band links (e.g. management ports in a management VLAN with private IP addresses).
• Use BGP blackholing, or configure the Filter to block attacks that might congest the network connection to the Console server.

For performance reasons, Flow Sensor saves flow data on its own server, and Packet Sensor also saves packet dumps locally. To list flows, generate flow tops, or inspect packet dumps from the user interface, each remote server must export a path to the Console server using NFS — see the KB article NFS configuration for remote servers. Collecting flows and packet dumps is optional.