Skip to content

External Firewalls

When XplicitTrust Network Access is deployed behind a corporate firewall, several common firewall features can interfere with the agent's data path. This page describes the mechanisms that most often cause problems and how to adjust the firewall so that XplicitTrust clients can establish and maintain stable tunnels.

The first part of this page is vendor-independent and covers the data-path model and the verification tools shipped with the agent. The vendor-specific configuration steps for FortiGate, Sophos Firewall, SonicWall, Check Point Quantum Spark and pfSense are in the tabs further down.

Background

XplicitTrust uses WireGuard over UDP as its preferred data-path protocol. Clients reach their peers either directly or through a UDP relay; if UDP becomes unavailable or unstable, the agent automatically fails over to a TCP relay (TLS over TCP/443). The TCP fallback preserves connectivity but introduces additional latency and overhead. Traffic remains end-to-end encrypted at every level – the relay infrastructure forwards encrypted packets but never has access to their contents.

Four firewall features can interfere with this dual-path model, independently of each other:

  • Application Control identifies WireGuard via deep packet inspection on the handshake. Most vendors classify the WireGuard signature as high-risk and block it by default. Detection is protocol-based, so changing the UDP port does not bypass it.
  • DoS / UDP flood protection drops sustained UDP traffic once a packets-per-second threshold is exceeded. Default thresholds are conservative and are routinely tripped by legitimate VPN traffic during file transfers, VoIP or screen sharing.
  • SSL / TLS deep inspection (HTTPS decryption) affects the TCP relay path. The relay carries WireGuard payload inside a TLS connection on TCP/443. When deep inspection is active, the firewall terminates the TLS session and substitutes its own certificate; the XplicitTrust agent rejects the substituted certificate and the TCP relay fails. If the UDP relay is simultaneously blocked, the agent cannot connect at all.
  • Source-NAT port translation randomises the UDP source port of outgoing packets when configured to do so. XplicitTrust direct peer-to-peer connections rely on UDP hole punching, which in turn requires the firewall to preserve the agent's source port across NAT. Configurations that do not preserve it cause the agent to fall back to the UDP relay even when a direct path would otherwise be possible.

The first three mechanisms can fully block the data path; the fourth does not interrupt connectivity, but forces all traffic through the UDP relay.

Verifying from the client

Two commands provided by the agent are useful regardless of the firewall vendor. They are the fastest way to confirm what the firewall on the path is doing to XplicitTrust traffic:

xtna-util --connectivity

Reports whether SSL termination is present on the XplicitTrust endpoints. If termination is detected, SSL/TLS deep inspection on the firewall is the cause.

xtna-util --status

Reports the active data path and the locally observed NAT type. A NAT type of Non-Collaborative NAT indicates that the firewall is rewriting the agent's UDP source port and is preventing direct peer-to-peer connections.

See the xtna-util reference for the full list of flags.

Vendor configuration

Steps below assume FortiOS 7.2 or later. Earlier versions use slightly different menu paths but expose the same settings.

1. Application Control blocks WireGuard

The FortiGuard application signature WireGuard (ID 46495, category Proxy) is classified as high-risk and is blocked by default in many FortiGate profiles.

Symptoms

  • XplicitTrust agent operates via the TCP relay instead of the preferred UDP relay path.
  • UDP relay sessions are blocked or torn down shortly after establishment.
  • Application Control log contains entries with appname "WireGuard" and action "block".
  • Changing the UDP port on the agent does not resolve the issue.

Verify (CLI)

execute log filter category 10
execute log display

Filter the output for "WireGuard". If matching block entries are present, Application Control is the cause.

Resolution via GUI

  1. Open Security Profiles → Application Control and edit the application profile attached to the firewall policy used for client traffic.
  2. In the Application and Filter Overrides section, click Create New.
  3. Type: Application. In the search field enter WireGuard and select the signature.
  4. Set the action to Allow (or Monitor if logging is required) and save.
  5. Confirm that no broader category filter (for example Proxy or VPN.Tunnel) still blocks the traffic. If it does, set those filters to Monitor or move the WireGuard override above them in the evaluation order.

Resolution via CLI

config application list
    edit "default"          # or the name of the profile in use
        config entries
            edit 0
                set application 46495
                set action pass
            next
        end
    next
end

2. DoS policy drops UDP traffic

The udp_flood, udp_src_session and udp_dst_session anomalies in a DoS policy drop sustained UDP traffic once a packets-per-second threshold is exceeded.

Symptoms

  • UDP relay traffic is interrupted under load (file transfer, VoIP, screen sharing, backup); the agent fails over to the TCP relay.
  • Anomaly log contains entries with attack udp_flood and action clear_session for the UDP relay session.
  • The issue correlates with throughput, not idle time, and recurs each time the agent attempts to switch back to the UDP relay.

Verify (CLI)

execute log filter category 7
execute log display

Category 7 is the anomaly log. Look for udp_flood, udp_src_session or udp_dst_session entries on the interface that carries XplicitTrust traffic.

Recommended resolution

Disable the udp_flood anomaly on the DoS policy that covers the XplicitTrust traffic. The same behaviour is documented for FortiGate's own SSL-VPN DTLS tunnels. Disabling udp_flood does not weaken the rest of the DoS policy; SYN flood, ICMP flood, port scan and other anomalies remain active.

Recommendation

Disable udp_flood (and, if present, udp_src_session / udp_dst_session) on the DoS policy that applies to the interface or zone used by XplicitTrust clients. Leave the remaining anomalies (SYN flood, ICMP flood, scan detection, etc.) enabled.

GUI path

  1. Open Policy & Objects → DoS Policy and edit the relevant IPv4 (or IPv6) DoS policy.
  2. Under L4 Anomaly, locate udp_flood and set the status to Disable.
  3. Apply the same change to udp_src_session and udp_dst_session if they are enabled.
  4. Save the policy.

CLI

config firewall DoS-policy
    edit <policy-id>
        config anomaly
            edit "udp_flood"
                set status disable
            next
            edit "udp_src_session"
                set status disable
            next
            edit "udp_dst_session"
                set status disable
            next
        end
    next
end

Alternative: keep UDP flood protection, exempt XplicitTrust

If policy requires that UDP flood protection remain enabled, two alternatives preserve the protection while allowing XplicitTrust to operate:

  • Exempt the XplicitTrust traffic: create a dedicated DoS policy above the generic one, scoped to the XplicitTrust relay address(es) as destination and the internal client subnets as source, with the UDP anomalies set to Disable. The generic policy continues to protect all other traffic.
  • Raise the threshold: first set the udp_flood action to Pass with logging for one to two business days to establish a peak-traffic baseline, then set the threshold to roughly twice the observed peak (in packets per second). Defaults are typically 2000 pps, which is easily exceeded by a single sustained file transfer through the tunnel.

3. SSL Deep Inspection breaks the TCP relay

Symptoms

  • The TCP relay path fails to establish or is repeatedly torn down.
  • The agent log shows TLS handshake or certificate validation errors against the XplicitTrust relay endpoints.

Verify

From a client machine behind the FortiGate:

xtna-util --connectivity

If SSL termination is reported, SSL Deep Inspection on the FortiGate is the cause.

Recommended resolution

Exempt the XplicitTrust endpoints from SSL Deep Inspection. This keeps full inspection active for all other traffic and only excludes the XplicitTrust control plane and relays from TLS termination.

Recommendation

Add the XplicitTrust endpoint FQDNs (or wildcard *.xplicittrust.com for standard SaaS deployments; adjust to your tenant) to the SSL Exempt list of the SSL/SSH Inspection profile attached to the policy that carries XplicitTrust client traffic.

GUI path

  1. Open Security Profiles → SSL/SSH Inspection and edit the profile attached to the relevant firewall policy.
  2. In the Exempt from SSL Inspection section, click Create New.
  3. Type: Wildcard FQDN. Enter the XplicitTrust relay FQDNs or a wildcard such as *.xplicittrust.com.
  4. Save the profile and confirm it is applied to the policy that carries client traffic.

CLI

config firewall ssl-ssh-profile
    edit <profile-name>
        config ssl-exempt
            edit 0
                set type wildcard-fqdn
                set wildcard-fqdn "*.xplicittrust.com"
            next
        end
    next
end

Alternative: certificate-inspection mode

If exempting specific endpoints is not desired, switch the SSL/SSH Inspection profile applied to the relevant policy from deep-inspection to certificate-inspection mode. Certificate inspection examines TLS metadata only and does not terminate the session, so the TCP relay continues to work. Note that this lowers visibility into encrypted traffic for the policy as a whole.

4. Source port preservation for direct connections

XplicitTrust agents establish direct peer-to-peer UDP connections whenever possible, falling back to a relay only if a direct path cannot be negotiated. The direct path is set up by UDP hole punching coordinated by the XplicitTrust broker: for each pair of agents the broker assigns a fixed UDP peering port on each side and instructs both agents to send their hole-punching packets from that local port to the other agent's <public IP>:<peering port> tuple. The receiving peer is told in advance which source port to expect. For this to work the FortiGate's source-NAT must preserve the agent's UDP source port.

FortiOS Static SNAT – the default mode when NAT is enabled on a firewall policy and Use Outgoing Interface Address is selected – preserves the original source port whenever possible. The Source Port Translation option defaults to When Port Conflicts, which leaves the source port untouched unless another active session is already using the same external IP and port. This is the configuration XplicitTrust direct connections need. The two configurations that override this default and force source-port randomisation are dynamic IP pools (in either policy-based NAT or Central NAT) and Source Port Translation: Always.

Symptoms

  • XplicitTrust agents behind the FortiGate consistently end up on a UDP or TCP relay, even when direct connectivity should be possible based on the network topology.
  • xtna-util --status on an affected client reports the local NAT type as Non-Collaborative NAT.
  • The same agents successfully establish direct connections from other networks (mobile hotspot, residential connection, a different site).

Verify

Run xtna-util --status on a client behind the FortiGate. To confirm, take a brief packet capture on the FortiGate WAN interface filtered on the agent's UDP traffic: the source port observed on the outside should equal the agent's peering port shown in the Admin Console under Assets → [select asset] → Edit → Advanced → Port. If it differs, the FortiGate is rewriting it.

Recommendation

On the firewall policy that handles outbound XplicitTrust traffic, enable NAT with Use Outgoing Interface Address (Static SNAT) and leave Source Port Translation at its default When Port Conflicts setting. The original source port is then preserved whenever possible, enabling direct peer-to-peer connections without per-asset port forwarding.

GUI path

  1. Open Policy & Objects → Firewall Policy and edit the policy that handles outbound XplicitTrust traffic (typically client subnets → WAN).
  2. Enable NAT and select Use Outgoing Interface Address.
  3. Confirm Source Port Translation is set to When Port Conflicts (the default). Do not select Always unless the deployment specifically requires it.
  4. Save the policy.

Note on Central NAT

If Central NAT is enabled, source port behaviour is controlled by the IP pool type and the central-snat-map entry. To preserve the source port in Central NAT mode, either use an Overload-type IP pool with port preservation enabled (FortiOS 7.4.4 introduced an explicit set port-preserve enable option in the central-snat-map), or exclude the XplicitTrust traffic from Central NAT and let it use the standard per-policy Static SNAT. The standard per-policy approach is significantly simpler and is the recommended path.

5. Direct connections via UDP port forwarding

If source-port preservation is not achievable, an asset that should accept direct inbound connections from peers can be made reachable by forwarding its tenant-specific UDP listening port on the FortiGate.

Step 1: Look up the agent UDP port

  1. Sign in to the XplicitTrust Admin Console.
  2. Open Assets, select the relevant asset and click Edit.
  3. Switch to the Advanced tab. The UDP listening port is shown in the Port field.

Step 2: Create a Virtual IP

  1. Open Policy & Objects → Virtual IPs and click Create New → Virtual IP.
  2. Name: xtna-<hostname> (or any descriptive name).
  3. External interface: WAN. External IP: the public WAN address of the FortiGate.
  4. Map to IPv4 address: the internal IP of the XplicitTrust asset.
  5. Enable Port Forwarding. Protocol: UDP. External and Mapped port: the port value from the Admin Console. Save.

Step 3: Create an inbound firewall policy

  1. Open Policy & Objects → Firewall Policy and click Create New.
  2. Incoming interface: WAN. Outgoing interface: the internal interface or zone where the asset resides.
  3. Source: all (or a geographic restriction if desired). Destination: the Virtual IP from Step 2. Service: ALL or a UDP service object matching the port.
  4. NAT: Disabled (the Virtual IP already performs the destination NAT).
  5. Attach the Application Control profile from section 1 so that the WireGuard signature is allowed on this inbound path as well, and save.

CLI

config firewall vip
    edit "xtna-<hostname>"
        set extip <wan-ip>
        set extintf "wan1"
        set portforward enable
        set protocol udp
        set extport <port>
        set mappedport <port>
        set mappedip "<internal-ip>"
    next
end

config firewall policy
    edit 0
        set name "xtna-direct-<hostname>"
        set srcintf "wan1"
        set dstintf "<internal-intf>"
        set srcaddr "all"
        set dstaddr "xtna-<hostname>"
        set action accept
        set schedule "always"
        set service "ALL"
        set application-list "<profile-with-wireguard-allow>"
    next
end

Step 4: Fixate the port in the Admin Console

Return to the Admin Console: Assets → [select asset] → Edit → Advanced → Port and enable Fixate Port. This locks the agent to the configured UDP port, so it does not renegotiate to a different port that the FortiGate is not forwarding.

Order matters

Enable Fixate Port only after Steps 2 and 3 are complete. Enabling it before the FortiGate is forwarding the port will lock the agent to a port that is not yet permitted, breaking direct connectivity until the FortiGate side is configured.

One Virtual IP plus one firewall policy is required per asset that should be directly reachable. If the FortiGate WAN IP is dynamic, configure DDNS so the public hostname remains stable.

Managed service providers

If the FortiGate is operated by a managed service provider, the relevant change requests are:

  1. Application Control override allowing application ID 46495 (WireGuard).
  2. Disabling the udp_flood anomaly on the DoS policy covering the client interface.
  3. Exempting the XplicitTrust relay endpoints from SSL Deep Inspection.
  4. Using Static SNAT with default Source Port Translation: When Port Conflicts on the firewall policy that handles outbound XplicitTrust traffic.

In HA or cluster setups, apply the changes on the primary unit only. They are synchronised to the secondary automatically.

Steps below assume Sophos Firewall (SFOS) v20 or later. Earlier versions use slightly different menu paths but expose the same settings.

1. Application Control blocks WireGuard

SophosLabs classifies WireGuard as a controlled application. Depending on the Application Filter policy in use, WireGuard traffic is blocked either directly or as part of a broader category rule (typically VPN or Very High Risk).

Symptoms

  • XplicitTrust agent operates via the TCP relay instead of the preferred UDP relay path.
  • UDP relay sessions are blocked or torn down shortly after establishment.
  • The Application Filter log contains entries for the application "WireGuard" with action "Deny" or "Drop".
  • Changing the UDP port on the agent does not resolve the issue.

Verify

Open Monitor & analyze → Log viewer and select the Application Filter module. Filter for WireGuard. Matching block or deny entries indicate that Application Control is the cause.

Resolution

  1. Open Protect → Applications → Application filter and edit the Application Filter policy attached to the firewall rule used for client traffic.
  2. Click Add to create a new rule above the existing block rules.
  3. In the filter criteria, search for WireGuard and select the application from the list.
  4. Set the action to Allow and save the rule.
  5. Confirm that the allow rule is positioned above any rule that blocks the broader categories (VPN, Proxy and Tunnel, Very High Risk). Application Filter policies are evaluated top-down.
  6. Save the policy and confirm it is selected in the firewall rule that handles client traffic (Rules and policies → Firewall rules, under Security features → Application Control).

2. DoS & spoof protection drops UDP traffic

The UDP flood Apply flag in DoS & spoof protection drops sustained UDP traffic once a per-source or per-destination packet rate is exceeded. Sophos's own documentation notes that the default UDP flood values commonly disrupt VoIP and VPN traffic; the same applies to XplicitTrust UDP relay sessions under load.

Symptoms

  • UDP relay traffic is interrupted under load; the agent fails over to the TCP relay.
  • The IPS / DoS attack log contains entries for UDP flood attacks against the agent's source or the relay's destination address.
  • The issue correlates with throughput, not idle time.

Verify

Open Monitor & analyze → Log viewer and select the IPS module. Look for UDP flood entries during periods of degraded XplicitTrust performance.

Recommendation

Under DoS & spoof protection, clear the Apply flag checkbox in both the Source and Destination columns of the UDP flood row. Leave SYN flood, TCP flood, ICMP flood and spoof prevention settings enabled.

Steps (GUI)

  1. Open Protect → Intrusion prevention → DoS & spoof protection.
  2. In the DoS settings section, locate the row for UDP flood.
  3. Clear the Apply flag checkboxes in both the Source and Destination columns.
  4. Click Apply.

Alternative: keep UDP flood protection, raise the threshold

If policy requires UDP flood protection to remain enabled, raise the packet rate to a value well above the peak XplicitTrust traffic observed for the deployment. Sophos support typically suggests 1500 packets per second per source as a baseline; XplicitTrust traffic under sustained load can require considerably higher values. Monitor the IPS log after the change to confirm that XplicitTrust traffic is no longer flagged.

3. SSL/TLS inspection breaks the TCP relay

Symptoms

  • The TCP relay path fails to establish or is repeatedly torn down.
  • The agent log shows TLS handshake or certificate validation errors against the XplicitTrust relay endpoints.

Verify

From a client machine behind the Sophos Firewall:

xtna-util --connectivity

If SSL termination is reported, SSL/TLS inspection on the Sophos Firewall is the cause.

Recommendation

Create an SSL/TLS inspection rule with action set to Don't decrypt, scoped to the XplicitTrust endpoint FQDNs (or wildcard *.xplicittrust.com for standard SaaS deployments; adjust to your tenant). Position the rule above any rule that performs decryption.

Steps (GUI)

  1. Open Rules and policies → SSL/TLS inspection rules.
  2. Click Add to create a new rule. Give it a descriptive name (e.g. XplicitTrust-Exclude).
  3. Set Action to Don't decrypt.
  4. Under Destination networks, add an FQDN host object for the XplicitTrust relay endpoints, or use a URL group containing the relay FQDNs (e.g. *.xplicittrust.com). Source and services can be left at the broadest setting suitable for the deployment.
  5. Position the rule above any Decrypt rules in the table; SSL/TLS inspection rules are evaluated top-down.
  6. Save the rule.

Alternative: web exception (DPI mode only)

If HTTPS decryption is performed by the DPI engine through firewall rules rather than a dedicated SSL/TLS inspection rule, the equivalent exclusion is a web exception: Web → Exceptions → Add exception. Under URL pattern matches, add a regular expression matching the XplicitTrust endpoints (for example ^.*\.xplicittrust\.com$), and clear the HTTPS decryption checkbox.

4. Source port preservation for direct connections

XplicitTrust direct peer-to-peer connections require that the firewall's source-NAT preserves the agent's UDP source port (see the FortiGate section for the underlying broker mechanics – the same requirement applies on every vendor). Sophos Firewall implements outbound NAT as a Masquerade (MASQ) rule and does not expose an explicit Preserve source port or Consistent NAT toggle in the GUI. The default Masquerade behaviour is endpoint-dependent: the public (IP, port) the agent appears on can change per destination, which the XplicitTrust NAT classifier reports as Non-Collaborative NAT.

Symptoms

  • XplicitTrust agents behind the Sophos Firewall consistently end up on a UDP or TCP relay, even when direct connectivity should be possible based on the network topology.
  • xtna-util --status on an affected client reports the local NAT type as Non-Collaborative NAT.
  • The same agents successfully establish direct connections from other networks (mobile hotspot, residential connection, a different site).

Verify

Run xtna-util --status on a client behind the Sophos Firewall. To confirm, take a brief packet capture on the WAN interface filtered on the agent's UDP traffic: the source port observed on the outside should equal the agent's peering port shown in the Admin Console under Assets → [select asset] → Edit → Advanced → Port. If it differs, the Sophos Firewall is rewriting it.

Recommendation

Sophos Firewall does not expose a setting that makes Masquerade behave as endpoint-independent (cone) NAT. If xtna-util --status reports Non-Collaborative NAT and direct connections are required, configure the per-asset UDP port forwarding described in the next section. A 1:1 SNAT (Translated source set to a dedicated IP Host rather than MASQ) on the outbound rule that carries the agent's traffic is an alternative when a spare public IP per asset is available; this is rarely practical at scale.

5. Direct connections via UDP port forwarding

If an asset behind the Sophos Firewall should accept direct inbound connections from peers but is not reachable because of NAT type or restrictive firewall behaviour, configure a service object, a DNAT rule and the matching firewall rule so that direct connections to the asset become possible.

Step 1: Look up the agent UDP port

  1. Sign in to the XplicitTrust Admin Console.
  2. Open Assets, select the relevant asset and click Edit.
  3. Switch to the Advanced tab. The UDP listening port is shown in the Port field.

Step 2: Create a UDP service object

  1. Open System → Hosts and services → Services and click Add.
  2. Name: xtna-<hostname> or any descriptive name.
  3. Type: TCP/UDP. Protocol: UDP.
  4. Source port: 1:65535. Destination port: the UDP port from Step 1. Save.

Step 3: Configure DNAT and firewall rule

On Sophos Firewall, port forwarding requires two objects: a DNAT rule that performs the address and port translation, and a firewall rule that permits the inbound traffic. The Server access assistant can create both in one workflow; the manual procedure is given below it for reference.

Option A – Server access assistant (recommended)

  1. Open Rules and policies → NAT rules and click Add NAT rule → Server access assistant (DNAT).
  2. Internal server IP address: the internal IP host of the XplicitTrust asset.
  3. Public IP address: the WAN interface or the public IP host.
  4. Services: the UDP service object from Step 2.
  5. External source networks and devices: Any (or restrict as required by policy).
  6. Click Save and finish. The assistant creates the DNAT rule, the firewall rule and, where applicable, loopback and reflexive rules.

Option B – Manual (DNAT rule + firewall rule)

DNAT rule:

  • Rules and policies → NAT rules → Add NAT rule → New NAT rule.
  • Original source: Any. Original destination: the WAN IP host or interface.
  • Original service: the UDP service from Step 2.
  • Translated source (SNAT): Original. Translated destination (DNAT): the asset's internal IP host.
  • Translated service (PAT): Original (port stays the same). Inbound and outbound interface: Any. Save.

Firewall rule:

  • Rules and policies → Firewall rules → Add firewall rule → New firewall rule.
  • Source zones: WAN. Source networks and devices: Any (or restricted).
  • Destination zones: LAN or DMZ (whichever holds the asset). Destination networks: the asset's internal IP host.
  • Services: the UDP service object from Step 2. Action: Accept.
  • Under Security features, attach the Application Filter policy that allows WireGuard (see section 1). Save.

Step 4: Fixate the port in the Admin Console

Return to the Admin Console: Assets → [select asset] → Edit → Advanced → Port and enable Fixate Port. This locks the agent to the configured UDP port, so it does not renegotiate to a different port that the firewall is not forwarding.

Order matters

Enable Fixate Port only after Steps 2 and 3 are complete. Enabling it before the firewall is forwarding the port will lock the agent to a port that is not yet permitted, breaking direct connectivity until the Sophos Firewall side is configured.

One service object, one DNAT rule and one firewall rule are required per asset that should be directly reachable. If the WAN IP is dynamic, configure DDNS so the public hostname remains stable.

Managed service providers

If the Sophos Firewall is operated by a managed service provider, the relevant change requests are:

  1. Application Filter allow rule for the WireGuard application.
  2. Clearing the Apply flag for UDP flood under DoS & spoof protection.
  3. Adding the XplicitTrust relay endpoints to an SSL/TLS inspection exclusion (action Don't decrypt).

In HA setups, apply the changes on the primary unit only. They are synchronised to the auxiliary unit automatically.

Tested against SonicOS 7. Earlier versions expose the same settings but use slightly different menu paths.

1. Source-NAT port translation prevents direct connections

By default, SonicWall remaps the source port on every new SNAT flow, taking a (usually random) port from the NAT pool. The external mapping additionally changes per destination, because Consistent NAT is disabled by default. From the broker's perspective this is textbook symmetric NAT: the XplicitTrust NAT classifier reports Non-Collaborative NAT, UDP hole-punching to peers behind another NAT fails, and the agent falls back to the relay.

Symptoms

  • xtna-util --status on a client behind the SonicWall reports the local NAT type as Non-Collaborative NAT.
  • XplicitTrust agents consistently end up on the UDP or TCP relay, even when direct connectivity should be possible.
  • The same agents establish direct connections from other networks (mobile hotspot, residential connection, a different site).

Recommended resolution – Enable Consistent NAT (lower-touch)

Consistent NAT uses an MD5 hash of the internal (IP, port) so the same internal endpoint always maps to the same external (IP, port) regardless of destination. This is endpoint-independent (cone) mapping and is on its own sufficient to flip the classifier from Non-Collaborative NAT to Collaborative NAT.

  1. Open Network → Firewall (in SonicOS 7, Network → Firewall / VoIP Settings depending on the build).
  2. Enable Consistent NAT and apply.

SonicWall notes a "slight decrease in overall security" with Consistent NAT enabled because the external (IP, port) pairs become more predictable. The trade-off is normally acceptable in environments where direct peer-to-peer connectivity is desired.

Alternative – Disable Source Port Remap (more targeted)

If Consistent NAT must not be enabled box-wide, the source port can be preserved per NAT policy instead:

  1. Open Network → NAT Policies and edit the LAN → WAN NAT policy that covers traffic from the agent.
  2. On the Advanced tab, enable Disable Source Port Remap.
  3. Apply.

SonicWall's documentation recommends also disabling Consistent NAT when Disable Source Port Remap is in use, since the two interact.

Option 1 (Consistent NAT) is the lower-touch fix; option 2 is more surgical and is appropriate when only the XplicitTrust outbound flow should be exempted.

2. App Control Advanced may match a VPN signature

SonicWall App Control Advanced can match VPN signatures by category (e.g. VPN → OpenVPN, named VPN clients). There is no dedicated WireGuard signature surfaced in the SonicWall knowledge base today, but signatures are configurable per-signature and similar engines on other vendors detect the WireGuard handshake.

Verify

Check the App Control logs for VPN-category drops on the broker or peer port range around the failure window.

Resolution

If a VPN-category drop is observed, either allow the matching signature for the egress policy that carries XplicitTrust traffic, or use a Bypass DPI rule in App Rules for that traffic. The change is only required if matches are actually observed; SonicWall does not block WireGuard by default.

3. DPI-SSL and aggressive UDP-blocking rules

SonicWall DPI-SSL is TCP-only and therefore does not directly affect the XplicitTrust UDP relay. However, some deployments deploy aggressive hardening rules that block UDP on common encrypted-traffic ports in order to force traffic onto TCP where DPI-SSL can decrypt it. When such a rule is active, the WireGuard handshake or data UDP can be silently dropped; the XplicitTrust NAT classifier then reports Full Block and the agent falls back to the TCP relay on TCP/443.

Verify

xtna-util --connectivity and xtna-util --status together indicate whether UDP is being blocked outright on the path. If UDP cannot reach the broker or relays but TCP/443 can, an outbound rule on the SonicWall is the likely cause.

Resolution

Confirm that outbound UDP from the client subnets to the XplicitTrust broker and relay endpoints is permitted. WireGuard needs outbound UDP to the broker, the UDP relay and to peer port ranges (starting at the tenant's BasePort 51821 and spanning roughly 5000 ports). Add an explicit allow rule for these destinations, ordered above the hardening rule that otherwise blocks UDP.

4. Direct connections via UDP port forwarding

If source-port preservation is not achievable on the SonicWall, an asset that should accept direct inbound connections from peers can still be made reachable by forwarding its tenant-specific UDP listening port.

Step 1: Look up the agent UDP port

  1. Sign in to the XplicitTrust Admin Console.
  2. Open Assets, select the relevant asset and click Edit.
  3. Switch to the Advanced tab. The UDP listening port is shown in the Port field.

Step 2: Configure port forwarding on the SonicWall

On SonicWall, port forwarding is typically built from three objects:

  1. Network → Address Objects — create a host object for the internal IP of the XplicitTrust asset.
  2. Object → Services — create a custom service of type UDP with the port from Step 1.
  3. Network → NAT Policies — create an inbound NAT policy: Original Source = Any, Original Destination = the WAN public IP (or WAN Interface IP), Original Service = the service from step 2, Translated Destination = the host object from step 1, Translated Service = Original.
  4. Policy → Rules and Policies → Access Rules — add a WAN → LAN (or WAN → DMZ) rule permitting the same UDP service to the internal host object.

SonicWall's Public Server Wizard (Quick Configuration) can create the address object, service object, NAT policy and access rule in a single flow and is the simplest path for this configuration.

Step 3: Fixate the port in the Admin Console

Return to the Admin Console: Assets → [select asset] → Edit → Advanced → Port and enable Fixate Port. This locks the agent to the configured UDP port, so it does not renegotiate to a different port that the SonicWall is not forwarding.

Order matters

Enable Fixate Port only after the NAT and access rule entries are in place. Enabling it before the SonicWall is forwarding the port will lock the agent to a port that is not yet permitted, breaking direct connectivity until the SonicWall side is configured.

Asks for a SonicWall customer

When working with a customer or managed service provider running a SonicWall, the three change requests that resolve the vast majority of cases are:

  1. Enable Consistent NAT (or disable Source Port Remap on the relevant LAN → WAN NAT policy) and re-run xtna-util --status to confirm the NAT class flips from non-collaborative to collaborative.
  2. Confirm App Control Advanced is not matching a VPN signature on the egress policy — check logs around the failure window.
  3. Confirm outbound UDP to the broker, relay and peer port ranges is not blocked by a hardening rule.

Tested against locally managed Quantum Spark 1500/1600/1800/1900/2000 series running R81.10.X (Gaia Embedded). Centrally managed Spark appliances expose the same blades through SmartConsole; the underlying mechanisms are identical.

Check Point Quantum Spark differs from the other vendors covered on this page in one important way: Hide NAT on Spark does not offer a source-port preservation option. Direct peer-to-peer connections behind a Spark therefore depend on the per-asset UDP port forwarding described in section 4 rather than on a NAT tuning toggle. The other three areas (Application Control, IPS UDP flood and HTTPS Inspection) follow the same pattern as the other vendors.

1. Application Control may match a WireGuard signature

Check Point AppWiki classifies WireGuard as a controlled application. Depending on the Access Policy in use, the WireGuard handshake is blocked either directly or as part of a broader category rule (typically VPN Tunnel or Anonymizer).

Symptoms

  • XplicitTrust agent operates via the TCP relay instead of the preferred UDP relay path.
  • UDP relay sessions are blocked or torn down shortly after establishment.
  • The Application & URL Filtering log contains entries for application "WireGuard" (or a VPN-tunnel category) with action Block or Drop.
  • Changing the UDP port on the agent does not resolve the issue.

Verify

Open Logs & Monitoring → Security Logs, filter for Blade = Application Control and search for WireGuard or VPN Tunnel around the failure window. Matching block entries indicate that Application Control is the cause.

Resolution

  1. Open Access Policy → Firewall Blade Control and confirm Application Control is enabled on the relevant policy layer.
  2. Open Access Policy → Policy (or the equivalent SmartConsole layer when centrally managed) and locate the outbound rule that carries client traffic.
  3. Add an override that explicitly allows the WireGuard application (and, if applicable, the broader VPN Tunnel category) on this rule. Place it above any rule that blocks the broader category.
  4. Install policy and re-test. Confirm that no further WireGuard block entries appear in the Application Control log.

2. IPS Non-TCP flood protection drops UDP traffic

Check Point IPS includes a Non-TCP Flood Footprint protection that drops sustained non-TCP traffic (UDP and ICMP) once a per-source or per-gateway packet rate is exceeded. The default IPS profile on Quantum Spark sets this protection to Prevent, and the threshold is not exposed in the WebUI on locally managed appliances. Legitimate XplicitTrust UDP relay traffic under sustained load (file transfer, VoIP, screen sharing, backup) routinely exceeds this threshold.

Symptoms

  • UDP relay traffic is interrupted under load; the agent fails over to the TCP relay.
  • The Threat Prevention log contains entries with attack name Non-TCP Flood Footprint (or, in older firmware, Non-TCP-Flood-Attack) and action Prevent / Drop against the agent's source IP or the XplicitTrust relay destination.
  • The issue correlates with throughput, not idle time, and recurs each time the agent attempts to switch back to the UDP relay.

Verify

Open Logs & Monitoring → Security Logs, filter for Blade = IPS and look for Non-TCP Flood Footprint entries on the interface that carries XplicitTrust traffic.

Recommendation

Set the Non-TCP Flood Footprint IPS protection to Detect (or Inactive) for the relevant profile, or add an IPS exception scoped to the XplicitTrust relay addresses as destination. Leave the remaining IPS protections enabled.

Steps (WebUI)

  1. Open Threat Prevention → IPS Protections (or Access Policy → Threat Prevention depending on firmware).
  2. Search for Non-TCP Flood Footprint.
  3. Change the action to Detect or Inactive for the IPS profile attached to the WAN-facing policy. Apply.
  4. If the threshold needs to remain enforced, add an IPS exception with Source: Any, Destination: XplicitTrust relay endpoints, Protection: Non-TCP Flood Footprint, Action: Detect.

On locally managed appliances where the IPS protection cannot be individually overridden in the WebUI, set the profile mode to Detect only for the duration of the test to confirm the diagnosis, then contact Check Point support to add a per-protection exception via cpsh or SmartConsole.

3. HTTPS Inspection breaks the TCP relay

Symptoms

  • The TCP relay path fails to establish or is repeatedly torn down.
  • The agent log shows TLS handshake or certificate validation errors against the XplicitTrust relay endpoints.

Verify

From a client machine behind the Quantum Spark:

xtna-util --connectivity

If SSL termination is reported, HTTPS Inspection on the Quantum Spark is the cause.

Recommendation

Add the XplicitTrust endpoint FQDNs (or wildcard *.xplicittrust.com for standard SaaS deployments; adjust to your tenant) to the SSL Inspection Exceptions list so the TCP relay traffic is bypassed by HTTPS Inspection. The rest of the HTTPS traffic continues to be inspected.

Steps (WebUI)

  1. Open Access Policy → SSL Inspection → Exceptions (path may be Threat Prevention → HTTPS Inspection → Exceptions depending on firmware).
  2. Click Add Exception.
  3. Type: FQDN (or Updatable Object if an XplicitTrust group is provided by Check Point). Enter the relay FQDNs, or the wildcard *.xplicittrust.com.
  4. Action: Bypass / Don't inspect. Save and install policy.
  5. Re-run xtna-util --connectivity from the client and confirm SSL termination is no longer reported.

Refer to Check Point sk180929 for the current best-practice on SSL inspection on locally managed Quantum Spark appliances and sk163595 for the HTTPS Inspection bypass-list object.

4. Direct connections via UDP port forwarding

Hide NAT on Quantum Spark does not preserve the agent's UDP source port (there is no equivalent to FortiGate's Source Port Translation: When Port Conflicts or SonicWall's Consistent NAT). Behind a Spark, the XplicitTrust NAT classifier therefore reports Non-Collaborative NAT and the agent falls back to the relay. The supported way to enable direct peer-to-peer connections for an asset behind a Spark is to forward its tenant-specific UDP listening port using a Server object.

Step 1: Look up the agent UDP port

  1. Sign in to the XplicitTrust Admin Console.
  2. Open Assets, select the relevant asset and click Edit.
  3. Switch to the Advanced tab. The UDP listening port is shown in the Port field.

Step 2: Define the internal host and the server object

  1. Open Users & Objects → Network Resources → Network Objects and add a Host object for the internal IP of the XplicitTrust asset.
  2. Open Access Policy → NAT → Servers and click New.
  3. Name: xtna-<hostname> or any descriptive name. Server type: Other. Host: the network object from Step 1.
  4. Under Access, select Server is accessible from the Internet.
  5. Under Server Ports add an entry: Protocol UDP, External port and Internal port both set to the UDP port from Step 1.
  6. Public IP: use the gateway's external interface address (or a dedicated public IP if assigned). Save.

The Servers workflow creates both the static destination-NAT entry and the matching firewall rule that permits the inbound UDP traffic.

Step 3: Verify the inbound rule

Open Access Policy → Policy → Incoming, Internal and VPN traffic and confirm that an Accept rule for UDP/<agent-port> to the server object exists. The Spark generates this rule automatically when the server is published; verify it is enabled and not overridden by a higher Drop rule. If the appliance is in default-block mode and the rule is missing, add it manually:

  • Source: Any. Destination: the server object from Step 2.
  • Service: a custom UDP service matching the agent port.
  • Action: Accept. Track: Log.

Ensure the Application Control override from section 1 is active on this rule as well, so the WireGuard handshake is not blocked on the inbound path.

Step 4: Fixate the port in the Admin Console

Return to the Admin Console: Assets → [select asset] → Edit → Advanced → Port and enable Fixate Port. This locks the agent to the configured UDP port, so it does not renegotiate to a different port that the Spark is not forwarding.

Order matters

Enable Fixate Port only after Steps 2 and 3 are complete. Enabling it before the Spark is forwarding the port will lock the agent to a port that is not yet permitted, breaking direct connectivity until the Spark side is configured.

One server object is required per asset that should be directly reachable. If the Spark's WAN IP is dynamic, configure DDNS so the public hostname remains stable.

Note on upstream routers

Quantum Spark is often deployed behind a SOHO router (FRITZ!Box, cable/DSL modem in router mode). In that topology the upstream device must additionally publish the Spark's WAN address to the public Internet — typically via Exposed Host on FRITZ!Box, or by placing the modem in bridge mode so the Spark holds the public IPv4 directly. If the public IPv4 is CGNAT (common with German cable and mobile uplinks), inbound port forwarding is not possible regardless of how the Spark and upstream router are configured, and the agent will operate on the relay.

Managed service providers

If the Quantum Spark is operated by a managed service provider, the relevant change requests are:

  1. Application Control override allowing the WireGuard application (and any matching VPN Tunnel category) on the outbound policy rule that carries client traffic.
  2. Setting the Non-TCP Flood Footprint IPS protection to Detect for the relevant profile, or adding an IPS exception scoped to the XplicitTrust relay endpoints.
  3. Adding the XplicitTrust relay endpoints to the SSL Inspection Exceptions list (bypass HTTPS Inspection).
  4. Publishing each asset that requires direct peer-to-peer connectivity through Access Policy → NAT → Servers, with the UDP port shown under Assets → [asset] → Edit → Advanced → Port in the Admin Console.

In cluster or HA setups, apply the changes on the primary unit only. They are synchronised to the secondary automatically.

Tested against pfSense Plus 23.X and pfSense CE 2.7.X. Both expose the same data-path mechanisms; menu paths are identical unless noted.

pfSense differs from the commercial vendors covered above in one important respect: it ships without an integrated Application Control or HTTPS Inspection feature. By default outbound LAN → WAN traffic is accepted and not subject to deep packet inspection, so the only mechanism that consistently affects XplicitTrust in a default install is source-port randomisation on Outbound NAT, covered first. The remaining sections apply only when the corresponding optional package (Snort, Suricata or Squid with SSL bump) is installed.

1. Source port preservation for direct connections

pfSense uses pf as its NAT engine. In the default Outbound NAT mode (Automatic) pfSense rewrites the source port on every outbound connection to a random value, with one hard-coded exception for UDP/500 (IKE). For every other UDP source port — including XplicitTrust agent traffic — the public (IP, port) the agent appears on changes per destination, which the XplicitTrust NAT classifier reports as Non-Collaborative NAT. UDP hole punching to peers behind another NAT then fails, and the agent falls back to the relay.

pfSense exposes an explicit toggle to preserve the source port on selected outbound flows, called Static Port. Enabling it on the outbound NAT rule that covers the agent's traffic is the direct equivalent of FortiGate's Source Port Translation: When Port Conflicts or SonicWall's Disable Source Port Remap.

Symptoms

  • XplicitTrust agents behind the pfSense consistently end up on a UDP or TCP relay, even when direct connectivity should be possible based on the network topology.
  • xtna-util --status on an affected client reports the local NAT type as Non-Collaborative NAT.
  • The same agents successfully establish direct connections from other networks (mobile hotspot, residential connection, a different site).

Verify

Run xtna-util --status on a client behind the pfSense. To confirm, take a brief packet capture on the WAN interface (Diagnostics → Packet Capture) filtered on the agent's UDP traffic: the source port observed on the outside should equal the agent's peering port shown in the Admin Console under Assets → [select asset] → Edit → Advanced → Port. If it differs, pfSense is rewriting it.

Recommendation

Switch Outbound NAT to Hybrid Outbound NAT and add a rule above the automatic rules that covers the agent's traffic with Static Port enabled. Hybrid mode keeps the existing automatic rules for everything else; only the matched XplicitTrust flow is affected.

Steps (WebUI)

  1. Open Firewall → NAT → Outbound and switch the mode from Automatic outbound NAT rule generation to Hybrid outbound NAT rule generation. Save.
  2. Under Mappings, click Add (the Add at top button) to insert a new manual rule above the automatic block.
  3. Interface: WAN. Address Family: IPv4 (add a second rule for IPv6 if applicable). Protocol: UDP.
  4. Source: the network of XplicitTrust clients (or a specific client host). Destination: Any. Destination Port: Any.
  5. Translation → Address: Interface Address (or a specific WAN IP host if using non-default NAT). Port: leave blank.
  6. Tick Static Port: Use static port (do not randomize source port). Save and Apply.
  7. From a client behind the pfSense, re-run xtna-util --status and confirm the local NAT type is no longer Non-Collaborative NAT.

Scope the Static Port rule

Static Port rules should be scoped as tightly as the deployment allows. When two internal hosts use the same source port to the same destination through the same external IP, pf cannot resolve the conflict and one flow will fail. Limiting Source to the XplicitTrust client subnet and Protocol to UDP keeps the rule narrow.

2. IDS/IPS (Snort or Suricata) may match a WireGuard signature

pfSense does not have a built-in Application Control engine, but the optional Snort and Suricata packages can match WireGuard handshakes through signatures shipped in the Emerging Threats Open ruleset (typically in the ET POLICY category). These rules are disabled by default in a fresh install; they are commonly enabled when an IPS-Balanced or IPS-Security policy template is selected or when the policy category is enabled wholesale.

Symptoms

  • XplicitTrust agent operates via the TCP relay instead of the preferred UDP relay path.
  • UDP relay sessions are blocked or torn down shortly after establishment.
  • The Snort or Suricata alert log on the WAN interface contains entries referencing WireGuard, ET POLICY or VPN tunnel around the failure window.
  • Changing the UDP port on the agent does not resolve the issue.

Verify

Open Services → Snort → Alerts (or Services → Suricata → Alerts), select the WAN interface and filter for WireGuard. If matching block or drop entries appear, the IDS/IPS is the cause.

Resolution

  1. Open the IDS package (Services → Snort or Services → Suricata) and edit the relevant interface.
  2. Switch to the Rules tab and locate the category that contains the matching SID (typically emerging-policy under ET Open, or the appropriate Snort VRT category).
  3. Use SID Management to disable the specific SID, or set its action to Alert only instead of Drop. Per-SID overrides survive ruleset updates; disabling categories does not.
  4. Restart the package on that interface and confirm no further WireGuard alerts appear.

If Snort/Suricata is not installed, skip this section.

3. HTTPS interception (Squid + SSL bump) breaks the TCP relay

Stock pfSense does not intercept HTTPS. The optional Squid package with SSL bump ("HTTPS / SSL interception" in the Squid GUI) is the only configuration in which pfSense terminates TLS on outbound HTTPS, which would in turn break the XplicitTrust TCP relay. SSL bump requires a custom CA on every client, so it is uncommon in SMB deployments.

Symptoms

  • The TCP relay path fails to establish or is repeatedly torn down.
  • The agent log shows TLS handshake or certificate validation errors against the XplicitTrust relay endpoints.

Verify

From a client machine behind the pfSense:

xtna-util --connectivity

If SSL termination is reported, Squid SSL bump (or another HTTPS proxy in the path) is the cause.

Recommendation

Add the XplicitTrust relay FQDNs (or the wildcard *.xplicittrust.com for standard SaaS deployments; adjust to your tenant) to the Squid SSL/MITM Whitelist (also labelled SSL Bump Direct Sites depending on Squid version) so that the TCP relay traffic is excluded from interception. Leave SSL bump active for the remaining HTTPS traffic.

Steps (WebUI)

  1. Open Services → Squid Proxy Server → ACLs.
  2. Add the XplicitTrust endpoint FQDNs to the SSL/MITM Whitelist (or Whitelist when SSL bump is not configured). Wildcard entries (.xplicittrust.com) are accepted.
  3. Apply, then re-run xtna-util --connectivity from the client to confirm SSL termination is no longer reported.

If Squid is not installed (or SSL bump is not enabled), skip this section.

4. Direct connections via UDP port forwarding

If source-port preservation cannot be enabled (for example because another NAT policy on the same outbound interface conflicts with Static Port), an asset that should accept direct inbound connections from peers can be made reachable by forwarding its tenant-specific UDP listening port. pfSense's port-forward workflow creates both the NAT entry and the matching firewall rule in one step.

Step 1: Look up the agent UDP port

  1. Sign in to the XplicitTrust Admin Console.
  2. Open Assets, select the relevant asset and click Edit.
  3. Switch to the Advanced tab. The UDP listening port is shown in the Port field.

Step 2: Create the port-forward

  1. Open Firewall → NAT → Port Forward and click Add.
  2. Interface: WAN. Address Family: IPv4 (add a separate rule for IPv6 if applicable). Protocol: UDP.
  3. Destination: WAN address (or a specific WAN IP host when multiple are assigned). Destination port range: From and To set to the UDP port from Step 1.
  4. Redirect target IP: the internal IP of the XplicitTrust asset. Redirect target port: the same UDP port from Step 1.
  5. Filter rule association: leave the default Add associated filter rule so pfSense creates the inbound WAN rule automatically.
  6. Save and Apply. Verify under Firewall → Rules → WAN that the associated allow rule is present and enabled.

Step 3: Fixate the port in the Admin Console

Return to the Admin Console: Assets → [select asset] → Edit → Advanced → Port and enable Fixate Port. This locks the agent to the configured UDP port, so it does not renegotiate to a different port that pfSense is not forwarding.

Order matters

Enable Fixate Port only after Step 2 is complete. Enabling it before pfSense is forwarding the port will lock the agent to a port that is not yet permitted, breaking direct connectivity until the pfSense side is configured.

One port-forward entry plus its associated firewall rule is required per asset that should be directly reachable. If the WAN IP is dynamic, configure DDNS (Services → Dynamic DNS) so the public hostname remains stable.

Managed service providers

If the pfSense is operated by a managed service provider, the relevant change requests are:

  1. Switching Outbound NAT to Hybrid mode and adding a Static Port rule for the XplicitTrust client subnet (UDP, source = client subnet, destination = any).
  2. If Snort or Suricata is active on the WAN interface, ensuring the WireGuard / ET POLICY signature is set to alert-only (or disabled) for the rule set in use.
  3. If Squid SSL bump is active, adding the XplicitTrust relay endpoints to the SSL/MITM whitelist.

In CARP / HA setups, apply the changes on the primary node and let them synchronise via XMLRPC sync to the secondary; confirm the secondary picked up the Outbound NAT mode change before failover testing.

Verification

After applying the vendor-specific changes:

  1. Reconnect the XplicitTrust agent.
  2. Run xtna-util --status and confirm that the active data path is a direct connection (or the UDP relay where direct is not possible) and that the reported local NAT type is not Non-Collaborative NAT.
  3. Run xtna-util --connectivity and confirm that no SSL termination is reported on the XplicitTrust endpoints.
  4. Generate sustained traffic through the tunnel (a large file transfer or an iperf3 UDP test is a good baseline).
  5. Re-check the firewall logs. Neither the Application Control / Filter log nor the DoS / IPS log should contain block or flood entries for XplicitTrust traffic, and the agent should remain on the preferred path throughout.
  6. If issues persist, capture a brief packet trace on the firewall's WAN interface filtered on the agent source address and the XplicitTrust relay address, and forward it together with the firewall software version to XplicitTrust support.

Support

For questions or further assistance, contact XplicitTrust at support@xplicittrust.com.