nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Community
- Command Central
- MVP Program
- Monthly Mission
- Blogs
- Groups
- Events
- Media Vault
Products
- Observability
- Network Management
- Application Management
- IT Security
- IT Service Management
- System Management
- Database Management
Content Exchange
- SolarWinds Platform
- Server & Application Monitor
- Database Performance Analyzer
- Server Configuration Monitor
- Network Performance Monitor
- Network Configuration Manager
- SQL Sentry
- Web Help Desk
Free Tools & Trials
Store

help needed - UDP Spoofing on VM not working

digeratimaximus

We are trying to use UDP spoofing to forward unaltered syslog events to a SIEM collector. We tried using the RFC 3164 headers first, but there still seems to be some extraneous information added to the messages.

The Kiwi Syslog server is running as a VM on a VMWare ESX server. When using the Kiwi syslog server dialog box, the default adapter is some VPN dialup adapter, the secondary choice is actually the VMWare adapter. The Kiwi server has been running successfully with the current configuration for a while, collecting events from Windows servers via SNARE and Cisco ASA FW and FWSMs.

When we try to check the box for UDP spoofing and select the VMWare adapter, we receive an error message stating that the default GW MAC could not be resolved. The test also fails, of course.

This seems confusing since we were successfully sending UDP on port 514 earlier in the day with no problems.

What is different with the UDP spoffing packets that could confuse the virtual switch? Can someone describe the actual packet format, and what MAC and IP address are used? I would assume the MAC address would be the MAC of the switch port that the Kiwi host would use to get to the original source host, and the IP address would be "spoofed" to look like the original source host. IS this a correct assumption?

If so, wouldnt the host IP address be associated with two separate switch ports in the bridging table? 1 for the upstream port to the actual location, and 1 for the port that is spoofing the address?

Find more posts tagged with

spoofing

transparent

udp

kiwi

proxy

Accepted answers

Kuz

Hi aliendan,

Thanks for the feedback. We're very much aware that this is a priority bug for people, and acknowledge it as an issue in the current version (9.0) of Kiwi Syslog Server. It is our intention to have this issue fixed in a forthcoming release, although I can't comment on when exactly that will be.

If possible, can you please raise a support ticket, so we can track it back to you as soon as a fix is available?
http://www.solarwinds.com/support/

For internal folks, this issue is already being tracked as TT#960.

If you could mention TT#960 in your support ticket, that would help in getting the fix to you.

Kind Regards,
Mike Kuzman.

All comments

Kuz

The key difference between normal UDP syslog sending and the UDP packet spoofing option, is that the packet spoofing option creates an entire Ethernet II Frame from scratch and sends it from the selected adapter. In order to do this, Kiwi Syslog Server needs to fill in the MAC address of the destination (a required part of the frame) - so that the IP packet can be routed by the network to the recipient device.

The error message " Unable to send custom packet: Cannot determine MAC address of destination, or the default gateway MAC address for the selected Network Adapter" means that (for whatever reason) Kiwi Syslog Server was unable to obtain the MAC address of either the destination or the default gateway (in the case of the destination being on a different subnet). Kiwi Syslog Server's normal behaviour in this instance is to Query the ARP table for the MAC address, and if not found; Send and ARP request, populating the ARP table, and thereby obtaining the MAC address (for the gateway).

snakethejake

I am having this same issue. I have verified in the ARP table that the MAC for the Gateway is there and valid and have even added a static entry for the IP address and MAC of the other server.

In my case both the Kiwi Syslog server and the server I'm forwarding to are in VMs on ESX 3.5. Anyone have any more ideas? Syslog is a perfect candidate for virtualization and this would be really nice to have working since we use Kiwi as our central repository . . . . but then forwarding to other systems as needed is key.

Thanks.

Kuz

Hi snakethejake,

We've recently discovered that this is a bug with Kiwi Syslog Server (that we don't have a workaround for currently). The bug happens when Kiwi Syslog Server tries to determine the Gateway IP address for the selected adapter. This call fails, and so the MAC address of the Gateway cannot be determined either. It's something that we are aware of, and it is on the list of bugs to fix in a forthcoming release.

aliendan

This is a big bug. Is there any update to when this will be fixed?