The IP header will definitely be different before and after forwarding. Log Insight won't pretend to be the original sender. The original TCP/UDP syslog connection had a source IP of the log generator and a destination IP of Log Insight (VIP or individual node). The forwarded TCP connection will have a source IP of the Log Insight node and a destination IP of the third-party tool. If the third-party tool inspects or uses the source IP of the TCP connection for anything, it will observe only the previous hop: the Log Insight forwarder.
The content of the syslog message will behave differently depending on where the message came from and what version of Log Insight is in use.
Log Insight 3.3 can receive messages via Syslog, CFAPI, or create them internally as a result of outbound integrations (e.g., vCenter Server).
Syslog messages are sent through unmodified (with a <14>1 priority header added to messages which lack it). This means that Log Insight 3.3 will can receive and re-transmit non-RFC compliant messages, but also means that additional metadata can't be added to the message during syslog->syslog forwarding yet.
Other messages, such as those sent by the Log Insight Agent or an earlier Forwarder, have discrete fields like hostname and appname outside of the message body. When CFAPI messages are forwarded via syslog, a syslog message is created by combining the various fields into the header (hostname, appname, msgid) or as RFC 5424 Structured Data (other fields).
For example:
curl -X POST 'http://172.16.50.143:9000/api/v1/messages/ingest/0' -d '{"messages":[{"text":"messagebody","fields":[{"name":"appname","content":"theappname"},{"name":"hostname","content":"clienthostname"},{"name":"procid","content":13},{"name":"msgid","content":"MID"},{"name":"custom","content":"extra"}]}]}'
<14>1 2016-04-12T19:49:45.493Z clienthostname theappname 13 MID [custom="extra" __li_source_path="172.16.50.1"] messagebody
