Syslog device source IP Address


I have setup a Graylog instance (4.2.8) on an Azure Virtual Machine.
It works fine, I used to run another instance locally for several months.

The issue I have is that every device that send syslogs to Graylog has its gl2_remote_ip as the WAN IP address and not the LAN IP address.
This is an issue since in some cases I have multiple devices behind the same router and I can’t differentiate them.

My question is, is there another hidden field that would allow me to know the LAN IP address of the device? I’ve checked on the fields sent by the devices and none of the have the source IP.

I hope you can help me.


What Input are you using to receive the syslog? In some cases the Syslog inputs will break things out differently than the raw inputs will. I think the gl2_remote_ip is generated by Graylog by what it sees coming at the Input so you would either have to have the IP embedded in the syslog or perhaps create a DNS lookup table and translate from the source field… assuming the source field was hostname.

All first reaction conjecture since I have not had this particular issue.

I am using the Syslog UDP input.
Unfortunately I cannot rely only on the host name since sometimes it cannot be changed on some devices and there can be 2 devices with the same host name.

What I am sure of is that the IP is not in the syslog messages. So I am wondering if it is stored by Graylog in another field.


I had a similar issue using Syslog UDP and had to either switch o GELF UDP or create new fields.

I have a couple question on your environment network.

If you do have multiple DMZ’s and with different network/s for each, how are they routed to your Graylog server( i.e. ACL’s. Port forward, etc…)?

Normally when a a device is in another network you should have a source IP address or at lest FQDN when those messages arrive at Graylog. This would depend on how your shipping those logs. I personally used Nxlog and applied a configuration to show FQDN for the host.

Exec $Hostname = hostname_fqdn();

In the message packet it should have the IP Address from where it came from. Data packets usually have a source and destination header.

Can you give us a mockup of the message without IP Address?
What log shipper are you using? and how did you configure it?
Have you tried using a different INPUT beside Syslog UDP?

As @tmacgbay

This is also a good idea, perhaps your missing the lookup :thinking:

Regarding our environment network, we don’t use DMZ.
The syslogs are shipped directly from the devices to the Graylog server (on Azure) using its public fqdn.

There is a network security group on the Azure VM that only allows incoming traffic from our different sites.

Here is a mockup of one of the message :

device=“SFW” date=2022-04-28 time=08:14:01 timezone="+04" device_name=“XG210” device_id=serialnumber0001 log_id=010101600001 log_type=“Firewall” log_component=“Firewall Rule” log_subtype=“Allowed” status=“Allow” priority=Information duration=0 fw_rule_id=13 nat_rule_id=62 policy_type=1 user_name="" user_gp="" iap=0 ips_policy_id=0 appfilter_policy_id=0 application=“DNS” application_risk=1 application_technology=“Network Protocol” application_category=“Infrastructure” vlan_id="" ether_type=Unknown (0x0000) bridge_name="" bridge_display_name="" in_interface=“Port1” in_display_interface=“Port1” out_interface=“Port5” out_display_interface=“Port5” src_mac=02:11:FF:11:83:3B dst_mac=FF:11:86:FC:00:01 src_ip= src_country_code=R1 dst_ip= dst_country_code=REU protocol=“UDP” src_port=65088 dst_port=53 sent_pkts=0 recv_pkts=0 sent_bytes=0 recv_bytes=0 tran_src_ip= tran_src_port=0 tran_dst_ip= tran_dst_port=0 srczonetype=“LAN” srczone=“LAN” dstzonetype=“WAN” dstzone=“WAN” dir_disp="" connevent=“Start” connid=“3772391424” vconnid="" hb_health=“No Heartbeat” message="" appresolvedby=“Signature” app_is_cloud=0

Here the src_ip field is not related to the device that sent the message but rather the firewall traffic the message was extracted from.

Here is another example which is better with a screenshot, it is from a completely different device

These are only two examples from two of our devices, but we have multiple of them, from different maker that don’t include the source ip address.

Try a different input - I have seen other posts where community members have said they are missing information in the Syslog input. Either GELF or maybe RAW, see if the correct sending IP comes in then…


Thanks again for taking the time to help me.
I have tried with RAW/Plaintext input but I have the same issue.

I am not able to make GELF usable with syslog though, I only have errors like this.

2022-05-02T05:25:48.902Z ERROR [DecodingProcessor] Unable to decode raw message RawMessage{id=53485150-c9d8-11ec-9b23-000d3ae770ba, messageQueueId=26272, codec=gelf, payloadSize=1120, timestamp=2022-05-02T05:25:48.901Z, remoteAddress=/15.169.716.208:34326} on input <626f6b0e2ff82922070d9e4d>.
2022-05-02T05:25:48.902Z ERROR [DecodingProcessor] Error processing message RawMessage{id=53485150-c9d8-11ec-9b23-000d3ae770ba, messageQueueId=26272, codec=gelf, payloadSize=1120, timestamp=2022-05-02T05:25:48.901Z, remoteAddress=/15.169.716.208:34326}
com.fasterxml.jackson.core.JsonParseException: Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null')
 at [Source: (String)"<30>device="SFW" date=2022-05-02 time=09:25:48 timezone="+04" device_name="XG210" device_id=serialnumber01 log_id=010101600001 log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" status="Allow" priority=Information duration=0 fw_rule_id=48 nat_rule_id=62 policy_type=1 user_name="" user_gp="" iap=0 ips_policy_id=0 appfilter_policy_id=0 application="" application_risk=0 application_technology="" application_category="" vlan_id="" ether_type=Unknown (0x0000) bridge_name="" brid"[truncated 620 chars]; line: 1, column: 2]
        at com.fasterxml.jackson.core.JsonParser._constructError( ~[graylog.jar:?]
        at com.fasterxml.jackson.core.base.ParserMinimalBase._reportError( ~[graylog.jar:?]
        at com.fasterxml.jackson.core.base.ParserMinimalBase._reportUnexpectedChar( ~[graylog.jar:?]
        at com.fasterxml.jackson.core.json.ReaderBasedJsonParser._handleOddValue( ~[graylog.jar:?]
        at com.fasterxml.jackson.core.json.ReaderBasedJsonParser.nextToken( ~[graylog.jar:?]
        at com.fasterxml.jackson.databind.ObjectMapper._readTreeAndClose( ~[graylog.jar:?]
        at com.fasterxml.jackson.databind.ObjectMapper.readTree( ~[graylog.jar:?]
        at org.graylog2.inputs.codecs.GelfCodec.decode( ~[graylog.jar:?]
        at org.graylog2.shared.buffers.processors.DecodingProcessor.processMessage( ~[graylog.jar:?]
        at org.graylog2.shared.buffers.processors.DecodingProcessor.onEvent( [graylog.jar:?]
        at org.graylog2.shared.buffers.processors.ProcessBufferProcessor.onEvent( [graylog.jar:?]
        at org.graylog2.shared.buffers.processors.ProcessBufferProcessor.onEvent( [graylog.jar:?]
        at [graylog.jar:?]
        at com.codahale.metrics.InstrumentedThreadFactory$ [graylog.jar:?]
        at [?:?]

Any idea?

If you can’t see it in the RAW message, Graylog is likely not equipped to pick it up because of the way the message was routed. The fallback solution would be to create a DNS lookup table.

1 Like

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.