Syslog forwarding from Log Viewer fails when “Use the original sender’s address as the source address” or custom source IP is enabled

• What works

  • Syslog events are correctly received and displayed in Log Viewer.
  • Forwarding to an external syslog/SEM collector succeeds when the forwarding action is set to:
    • Source network address: use the SolarWinds server’s address as the source.
    • Syslog HOSTNAME field: use the original sender’s address.
    • Syslog ORIGINAL ADDRESS field: add the original sender’s address.
  • In this configuration, the external collector receives the events and still sees the original device identity in HOSTNAME/ORIGINAL ADDRESS, even though the packet source IP is the SolarWinds server.

• What fails

  • When the forwarding action is changed to:
    • Use the original sender’s address as the source address, or
    • Use a custom source address set to the device IP,
  • syslog events still appear in Log Viewer, but:
    • forwarded packets either do not leave the SolarWinds server or are dropped by the network path, and
    • the external syslog/SEM does not show the corresponding events.

• Why it happens

  • Using the original sender/custom IP as the packet source is effectively IP source spoofing: packets appear on the network as if they originate from the device IP, even though they are sent by the SolarWinds server.
  • Many networks enforce uRPF, anti-spoofing, and strict ingress ACLs, which can block or drop spoofed-looking packets.
  • Forwarding in this mode is therefore dependent on firewall rules and network/security policies, not just the forwarding rule itself.
  • The Syslog service executable also needs an explicit outbound firewall rule to reach the external collector.

This issue is not caused by syslog ingestion or rule-matching in Log Viewer. In all observed cases, the affected syslog messages are successfully received and displayed in Log Viewer, and the same rules forward correctly when the SolarWinds server IP is used as the source.

The failure occurs only when the forwarding action is configured to:

• Use the original sender’s address as the source address, or
• Use a custom source address set to the device IP.

In these modes, the SolarWinds Syslog service constructs forwarded packets that appear to originate from the device IP, even though they are actually sent from the SolarWinds server’s NIC. On the network, this is effectively IP source spoofing.

Many customer networks enforce security controls such as:

• Unicast Reverse Path Forwarding (uRPF)
• Anti-spoofing policies
• Strict ingress ACLs and firewall rules

These controls commonly drop or reject packets whose source IP does not match the expected interface/network, which includes spoofed-looking traffic originating from the SolarWinds server but claiming to be from a device IP. If outbound firewall rules are not explicitly allowing the Syslog service executable, traffic may also be blocked at the host or perimeter firewall.

As a result:

• Syslogs still appear in Log Viewer (ingestion works),
• But forwarded packets using the original/custom source IP are blocked or discarded by network/security devices, so the external syslog/SEM never receives them.

1. Use a non-spoofed, supported forwarding configuration (recommended)
   Configure the syslog forwarding action in Log Viewer / Log Analyzer as follows:

   • Source network address:
     
     • Set to Use the SolarWinds Platform server’s address as the source address.
   • Syslog HOSTNAME field:
     
     • Set to Use the original sender’s address for HOSTNAME field.
   • Syslog ORIGINAL ADDRESS field:
     
     • Set to Add the original sender’s address for ORIGINAL ADDRESS field.

   This keeps the SolarWinds server IP as the packet source IP (no spoofing) while preserving the original device identity in the syslog payload. In affected environments, this configuration has been confirmed to forward successfully to external syslog/SEM collectors.

2. If you need to use the device IP as the packet source (original sender/custom source)

   This mode is environment- and security-dependent:

   • Firewall rule for the Syslog service

     • Ensure the host or perimeter firewall allows outbound traffic from:
       C:\Program Files\SolarWinds\Orion\SolarWinds.Orion.LogMgmt.SyslogService.exe
       to the external syslog/SEM server on the configured port (for example, UDP/514).

   • Review spoofing-related controls with the network team
     Ask your network/security team to review and, if appropriate, adjust:

     • uRPF (Unicast Reverse Path Forwarding)
     • Anti-spoofing policies
     • Ingress ACLs on routers/firewalls

     They must explicitly allow packets that originate from the SolarWinds server’s interface but use the device IP as the source IP. If these controls cannot be relaxed for this traffic, original-sender/custom-source forwarding will likely continue to fail by design.

   • Re-test with packet capture and SEM search
     After any network changes:

     • Trigger a test syslog from the device.
     • Use Wireshark on the SolarWinds server to confirm packets are sent to the external syslog/SEM with the device IP as source.
     • Confirm the external collector now receives and parses the events.