AxiShield Docs
Deploy, configure and operate AxiShield from the first installation through network segmentation, security policies, monitoring, maintenance and recovery.
This guide describes the standard AxiShield workflow and the modules available in the current platform family. Exact labels can vary slightly by release or licence edition. Changes affecting live traffic should be performed during a controlled maintenance window.
Prepare the host and network topology before starting the installer.
Use a dedicated x86-64 host or virtual machine with sufficient CPU, memory and storage for the expected traffic volume, logging retention and inspection workload.
Identify every physical or virtual interface before deployment. Record the intended WAN, LAN, management, CCTV or unassigned role for each port.
Keep local console access available during initial configuration. Incorrect role assignment, addressing or routing can interrupt remote access.
Install AxiShield through the authenticated deployment journey supplied by the Customer Portal.
Back up any required data, connect the intended network interfaces and confirm local console access.
Sign in, select the licence or trial, choose the target device and open the installation journey.
The portal creates a device-bound installation flow. Use only the command and token displayed for that device.
Execute the portal-provided command with administrative privileges on the supported Linux base. Do not reuse expired or previously committed pairing information.
The installer validates the host, retrieves signed components, installs services, registers the device and reports each stage.
After completion, reboot the system if the installer or release notes require it. Keep the console visible until the AxiShield workspace loads.
# Use the exact secure command generated in Customer Portal
sudo <portal-provided-installer-command>
# After a successful installation, reboot only when requested
sudo rebootInstaller links, pairing codes and device tokens may grant temporary provisioning access. Generate a new flow if a secret is exposed.
Complete the minimum safe configuration before connecting production users.
Interface roles define how AxiShield treats every connected network.
| Role | Purpose | Typical behaviour |
|---|---|---|
| WAN | Internet or upstream connectivity | Gateway monitoring, routing, failover or load balancing |
| LAN | Protected client network | DHCP, DNS, forwarding and assigned security policies |
| MGMT | Administrative access | Restricted management plane with no unnecessary client services |
| CCTV | Camera and recorder network | Internet access with predefined camera-focused protections and isolation |
| FREE | Available or intentionally unassigned port | No automatic production role until configured |
1. Rename interfaces according to their physical purpose. 2. Assign roles. 3. Configure static or dynamic addressing. 4. Apply DHCP/DNS settings where relevant. 5. Assign application policies. 6. Test from a single controlled client before wider rollout.
Maintain upstream availability without allowing invalid routes to remain active.
For two or more wired WAN interfaces, configure priority, health thresholds and failback behaviour. A failed or missing WAN is removed from active routing while its configuration and policy assignments remain preserved.
Distribute eligible sessions across healthy WANs using explicit weights. Weighting expresses preference; it does not guarantee identical bandwidth usage for every application.
Check the active default route, browse from a protected client, disconnect one WAN, confirm service continuity, then reconnect it and verify clean automatic reintegration.
Deliver predictable client addressing and controlled name resolution per eligible interface.
Create a scope only on interfaces that should serve clients. Keep the gateway inside the interface subnet and exclude infrastructure addresses from the dynamic pool.
Use the DNS module to control upstream resolvers, local behaviour and security filtering. Confirm that AxiShield itself can resolve names before diagnosing client-side DNS.
Create reusable policies first, then assign them to one or more interfaces.
AxiShield keeps application policies separate from interface configuration. A firewall policy can be created, renamed, duplicated and edited without being applied. Assignment is explicit and may target zero, one or several interfaces.
Define the policy objective, default action, services, ports, addresses, direction and logging requirements.
Select the LAN, CCTV or other eligible interfaces that should use the policy. Review conflicts before activation.
Test allowed business traffic and at least one expected denial. Review logs to confirm the correct rule is responsible.
Start with deny-by-default, then permit only the ports genuinely required by the protected environment. Duplicate the policy when another network needs a similar but not identical rule set.
Detect suspicious network behaviour and optionally prevent confirmed threats.
Begin in detect-only mode when introducing the engine to an existing production network. Review alerts, grouped analysis and repeated patterns before enabling blocking.
Enable IPS after validating signatures and expected traffic. Monitor Internet access and essential applications immediately after activation.
Inspect eligible files observed in network traffic without replacing endpoint protection.
Assign Network File Inspection to the required LAN-facing interfaces. Start in passive detection mode, generate a controlled test event and confirm that the file, source, destination and verdict appear in the interface.
File visibility depends on protocol, encryption and deployment design. Do not claim inspection coverage for content AxiShield cannot observe.
Scan authorised storage locations and isolate suspicious files with traceable evidence.
Use Quick Scan for routine checks and Full Scan for deeper review of authorised AxiDrive and USB locations. Progress, cancellation and results remain visible to the administrator.
Quarantined files are held in a restricted location with metadata, history and SHA-256 identification. Restore only after a documented review.
Disconnect the affected workflow if necessary, preserve the alert, verify the hash and source, review related network events, then delete or restore according to the organisation’s incident process.
Maintain trusted indicators and correlate them with local security events.
The Threat Intelligence module supports curated external sources and administrator-managed indicators. Current deployments can correlate recognised malicious infrastructure, certificate fingerprints or known exploited vulnerabilities with observed activity.
| Source type | Use | Operational note |
|---|---|---|
| CISA KEV | Known exploited vulnerabilities | Use to prioritise exposure and remediation; it is not a network blocklist by itself. |
| Feodo C2 | Known command-and-control infrastructure | Review destination matches and affected internal devices. |
| SSL certificate intelligence | Malicious certificate fingerprints | Correlate with encrypted infrastructure where visibility permits. |
| Custom IOC | Organisation-specific indicators | Document owner, source, expiry and confidence. |
Apply browsing controls without merging them into the firewall rule base.
Create independent filtering policies, define categories or explicit domain decisions, then assign those policies to the intended interfaces. Use narrow exceptions with an owner and review date rather than weakening the entire policy.
Route selected protected interfaces through named outbound VPN tunnels.
AxiVPN is managed as a client tunnel, not as a general remote-access VPN server. Create a named tunnel, configure its provider or server parameters, then assign zero, one or multiple interfaces. Traffic from clients on those interfaces exits through the selected tunnel.
vpnUKIsolate camera infrastructure while preserving controlled Internet access.
Assign the CCTV role to the interface serving cameras, recorders or related devices. AxiShield applies the CCTV network model and exposes the relevant protections across Firewall, DNS, Network Protector, Traffic Monitor and other supported applications.
Permit only the destinations and services required for camera operation, updates, time synchronisation and authorised remote management. Do not allow unrestricted access from CCTV devices to user networks.
Use shared evidence to understand health, performance and security activity.
When investigating an incident, correlate time, source interface, client address, destination, policy and action rather than relying on a single counter.
Surface actionable changes without flooding administrators during startup.
Use notification severity and source to distinguish information from action. Prioritise failed security services, persistent WAN loss, licence problems, update failures, quarantine events and configuration changes. Routine startup transitions should not be treated as incidents unless they remain unresolved.
Handle downloaded and removable files without exposing the wider operating system.
AxiDrive is a restricted file workspace. It provides access to the AxiShield downloads area and authorised USB media, but not to the rest of the system. Use it to review, copy, export or scan files under controlled policies.
Unknown or untrusted media should remain read-only until scanned and explicitly approved. Removing the USB device during a copy or scan can corrupt the operation.
Apply signed releases while preserving a stable and recoverable base.
Confirm scope, prerequisites, expected service interruption and reboot requirement.
Export or record critical settings before a production change.
Keep the progress view open and do not interrupt package verification, file commit or service reload.
Check WAN, DNS, client Internet access, firewall state and the modules modified by the release.
Rollback must return to the last validated complete package, not to an arbitrary mixture of files.
Manage entitlement, devices, secure installers and account recovery outside the firewall workspace.
Review edition, state, validity and eligible device capacity.
Authorise, identify and manage installations linked to the organisation.
Create secure device-specific installation journeys and review their status.
A simple routine prevents small warnings from becoming service incidents.
| Frequency | Review |
|---|---|
| Daily | WAN status, critical notifications, blocked threats, quarantine and failed services. |
| Weekly | Policy changes, top traffic, repeated detections, device inventory and backup status. |
| Monthly | Administrator accounts, exceptions, unused rules, licence state, update level and recovery readiness. |
| After every change | Management access, DNS, Internet access, affected applications and rollback evidence. |
Start with the lowest layer and isolate one variable at a time.
Complete this checklist before declaring a deployment ready.
Build the network in layers, validate every change and keep recovery available.