Skip to main content
Many Wirespeed integrations accept logs from firewalls, network devices, and other sources through a forwarder. After you add the integration, Wirespeed prepares that forwarder and shows the connection details you need.

​
Set up a forwarder

  1. Login to Wirespeed and navigate to Integrations > Add Integration
  2. Select the integration for your vendor or log source and click Integrate
  3. Set a Source Name so you can tell multiple instances of the same vendor apart in Integrations. Add a separate integration for each firewall; see When do I need multiple forwarders?
  4. Wirespeed prepares the forwarder after the integration is added
  5. Forwarder Details opens automatically when setup finishes while you remain on the integration page
  6. Copy the IP address or domain and the listener port(s) shown there
  7. Configure your vendor or source to send logs using those details
  8. Confirm logs appear in Events
Each integration page covers any vendor-specific steps, protocol choices, or formats. To check what your forwarder is receiving, troubleshoot missing logs and forwarder errors, or find out why the integration is Unstable or Unhealthy, use the integration’s Data usage tab. See Forwarder Data Usage.

​
Understanding the connection details

Forwarder Details shows an IP address or domain and one or more listener ports. Each listener also shows whether its connection is TLS encrypted (TLS: Enabled) or not (TLS: Disabled). Your devices send logs to that destination. The port identifies which Wirespeed integration the logs belong to, so they appear under the correct vendor in Events.

​
Syslog over TLS

Enable Enable TLS on TCP socket only when the vendor will send TCP syslog over TLS. Wirespeed presents a Let’s Encrypt certificate. Browsers already trust that chain. Many firewalls and appliances do not, and may need a CA imported as a trustpoint before secure syslog will connect.

​
Root CA

Import both Let’s Encrypt roots as trusted CAs (trustpoints) on the device: Let’s Encrypt chains can end at either root, and some appliances do not follow the cross-signed certificate in the chain. Trusting both roots covers certificate renewals without further changes. Use roots when you can. Intermediate CAs change more often; if you install one of those instead, you may have to update the device again later.

​
Inspect the certificate chain

Replace the placeholders with the domain and TLS port from Forwarder Details. This prints the subject and issuer of each certificate the forwarder serves:
Example output (the certificates and names change over time):
To read the output:
  • The issuer of the last certificate is the root that a device following the full chain needs. In this example, that is ISRG Root X1.
  • Any ISRG Root X* that appears as the issuer of an earlier certificate is the root needed by devices that stop before the cross-signed certificate. In this example, that is ISRG Root X2.
  • If you are unsure which one your device needs, import both.
The served chain can change when the certificate renews. Treat the output above as an example, not as a permanent description of the chain.

​
Verify before configuring the device

Confirm from a workstation that a root validates the forwarder certificate. Download the root PEM from the links above (for example isrgrootx1.pem) and run:
A successful check ends with Verify return code: 0 (ok). A failure prints a verify error line such as unable to get local issuer certificate. Repeat with -CAfile isrgrootx2.pem to check the other root; the chain validates against either one.

​
Intermediate chain

Use this only if the device will not accept a root trustpoint and requires the issuing CA. Replace the placeholders with the domain and TLS port from Forwarder Details:
chain.pem contains every certificate the forwarder serves after its own certificate: the intermediate CA or CAs and any cross-signed certificates. Import that file on the device. If the device accepts only one certificate per import, split the file and import the certificates one at a time.
Intermediates and cross-signed certificates change when the forwarder certificate renews. If you import them, you must import the new ones after a renewal. Roots change far less often, which is why importing the roots is preferred.

​
Certificate revocation (CRL) checks

If your firewall or appliance performs certificate revocation checks (CRL) on the Wirespeed forwarder certificate, you must allow outbound access to the domain *.c.lencr.org (for example r13.c.lencr.org) over HTTP (TCP port 80).
If the device cannot reach *.c.lencr.org over HTTP, the CRL check fails and the TLS connection to the forwarder may be rejected, so no logs arrive. Add *.c.lencr.org (HTTP) to your firewall allow list, or disable CRL checking for the trustpoint.

​
Troubleshooting

If TLS handshakes start failing right after a certificate renewal, the served chain has changed. Re-run the chain inspection command and import any ISRG Root X* that it shows as an issuer. Importing both roots avoids this in most cases.

​
When do I need multiple forwarders?

Different vendors or services need separate integrations — and therefore separate forwarders. For example, a SonicWall firewall and a Cisco Meraki deployment each get their own connection details. Multiple devices of the same vendor, such as several FortiGate firewalls, should be distributed across multiple integrations. Add one integration per firewall (or per high-availability pair) and give each a distinct Source Name, for example FortiGate - NYC HQ. A single forwarder can reach its resource limits when the event rate is high, so one integration per firewall keeps the load on each forwarder low.
If you have many firewalls and strongly prefer not to set up multiple forwarders, reach out to Wirespeed support.