This is because the syslog service on the sensor has been switched to work on port 515 because the nr.packetd service has to monitor port 514 for syslog messages coming from Cisco routers.
A few versions back, a feature was added to nr.packetd which allowed it to receive syslog messages from Cisco Routers and generate alarms when certain ACLs denied ip traffic.
To do this nr.packetd had to open up the UDP port 514. The router could not be configured to send to a different so port 514 was manditory.
The syslog service on the sensor itself, however, was using UDP port 514.
So the syslog service was modified (in the /etc/services file) to use UDP port 515 instead so that nr.packetd could open up UDP port 514.
Cisco does not support users making changes to the sensor's operating system or adding of their own files to the sensor. Users who choose to do this, do so at their own risk without the support of the TAC or Cisco's development teams. There multiple different modifications that were made to the underlying operating system that could cause user's problems when they try implementing their own scripts. You've run into one of these minor modifications while trying to get syslog to work to an exernal box.
So what to do?
You can't force syslog on the sensor to use port 514. If you edit the /etc/services file and change syslog back to 514, then it will compete with nr.packetd for control of the port. This will result in nr.packetd errors, and could prevent your sensor from monitoring.
Since Cisco doesn't support making modifications to the sensor OS files, or adding of use custom scripts, then I would consider deploying a solution that Cisco would support.
Cisco supports the execution of user scripts by it's enterprise IDS Management products. The new Security Monitoring Center (part of VMS2.1), and the older CSPM and Unix Director, all support the automatic execution of user created scripts when alarms of certain severities have been seen.
So instead of generating syslogs directly from the sensor, the sensor would send the alarm to your enterprise management station, which would then be configured to executed your custom script when it sees the alarm. You custom script would then generate the syslog message from the enterprise management station.
Review the documentation for your specific management product to determine and how to configure this functionality.
NOTE: IEV which comes at no extra cost with the 3.1 sensor does not support the execution of user custom scripts, if you are using IEV then you need to consider purchasing one of the supported enterprise management systems. I would recommend purchasing VMS 2.1 and using the included Security Monitor.
