Netcat, Syslog, UDP, and <134>

I wasn't clear if you configured syslog on all of your clients or not. Your tcpdump seems to show inbound syslog traffic, but you might want check that you aren't simply seeing traffic from one remote syslog client. Be sure that Syslogd is configured on each client machine as well. You need to add a line which looks something like this, where syslog.example.org is your syslog server:

# Log all messages to central syslog server
*.*     @syslog.example.org

To verify this is working, use the logger(1) utility. I run a command like this on all of my machines in one window, often in a loop like for HOST in ALLOFMYHOSTS; do ssh $HOST 'logger'.....

logger -t stefantest stefantest1

Then in a separate window connected to the syslog, I do a tail -f /var/log/YOURLOGFILE |grep stefantest. This will confirm if syslog itself is working from each host or not. Then, go from there.

There is no such thing as an "open" UDP port, at least not in the sense most people are used to think (which is answering something like "OK, I've accepted your connection"). UDP is session-less, so "a port" (read: the UDP protocol in the operating system IP stack) will never respond "success" on its own.

UDP ports only have two states: listening or not. That usually translates to "having a socket open on it by a process" or "not having any socket open". The latter case should be easy to detect since the system should respond with an ICMP Destination Unreachable packet with code=3 (Port unreachable). Unfortunately many firewalls could drop those packets so if you don't get anything back you don't know for sure if the port is in this state or not. And let's not forget that ICMP is session-less too and doesn't do retransmissions: the Port Unreachable packet could very well be lost somewhere on the net.

A UDP port in the "listening" state may not respond at all (the process listening on it just receives the packet and doesn't transmit anything) or it could send something back (if the process does act upon reception and if it acts by responding via UDP to the original sender IP:port). So again, you never know for sure what's the state if you don't get anything back.

You say you can have control of the receiving host: that makes you able to construct your own protocol to check UDP port reachability: just put a process on the receiving host that'll listen on the given UDP port and respond back (or send you an email, or just freak out and unlink() everything on the host file system... anything that'll trigger your attention will do).