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 and SonicWall 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 management 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 management 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 management 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 management console

Return to the management 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. 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 management 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 management console

Return to the management 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 management 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 management console

Return to the management 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.

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.