[Cisco Meraki]: Align NAT field mapping with ECS standards in IP flows pipeline

[WesselPinew]

Integration Name

Cisco Meraki [cisco_meraki]

Dataset Name

cisco_meraki.log

Integration Version

1.29.1

Agent Version

8.15.5

OS Version and Architecture

Ubuntu 24.04 LTS (x86_64)

User Goal

I need the Cisco Meraki integration's ipflow ingest pipeline to correctly map NAT fields according to the Elastic Common Schema (ECS) standards. Specifically, I would like translated IP addresses and ports to be stored in the appropriate NAT fields (source.nat.ip and source.nat.port) while preserving the original source information in the standard fields (source.ip and source.port).

Existing Features

The current implementation causes two issues:

• Data loss due to conditional logic: When translated_src_ip exists, the original source IP in src is not stored anywhere, resulting in loss of the internal/private IP address information. This hinders our ability to make targeted rule exceptions for alerts.

• Incorrect ECS mapping: The pipeline places translated_src_ip (the NAT'd public IP) into source.ip, which contradicts ECS guidelines. NAT'd addresses should be stored in source.nat.ip, while the original source IP src should remain in source.ip.

What did you see?

Example of a IP flow event:

<134>1 1751379284.245040794 FW_01 ip_flow_start src=10.140.40.72 dst=8.8.8.8 protocol=udp sport=18212 dport=53 translated_src_ip=1.128.3.4 translated_port=13710

Current behavior

• source.ip: 1.128.3.4 (translated/NAT'd IP)
• source.port: 13710 (translated port)
• Original IP (10.140.40.72) and port (18212) are not stored

Expected behavior

• source.ip: 10.140.40.72 (original internal IP)
• source.port: 18212 (original port)
• source.nat.ip: 1.128.3.4 (NAT'd public IP)
• source.nat.port: 13710 (NAT'd port)

Anything else?

This is the part of the ingest pipeline that is responsible for the behaviour:

integrations/packages/cisco_meraki/data_stream/log/elasticsearch/ingest_pipeline/ipflows.yml

Lines 19 to 39 in 08dd8a2

	# source field IP:port handling
	- convert:
	type: ip
	field: translated_src_ip
	target_field: source.ip
	if: ctx?.translated_src_ip != null
	- convert:
	type: ip
	field: src
	target_field: source.ip
	if: ctx?.translated_src_ip == null && ctx?.src != null
	- convert:
	field: translated_port
	target_field: source.port
	type: long
	if: ctx?.translated_src_ip != null && ctx?.translated_port != null
	- convert:
	field: sport
	target_field: source.port
	type: long
	if: ctx?.translated_src_ip == null && ctx?.sport != null

.

Proposed solution

The pipeline should be updated to always map fields as follows:

• src → source.ip (always)
• sport → source.port (always)
• translated_src_ip → source.nat.ip (when present)
• translated_port → source.nat.port (when present)

This change should also be extended to destination NAT fields (translated_dst_ip → destination.nat.ip, etc.) if they exist in the pipeline for consistency.

This change would:

• Preserve all network information (both internal and external IPs/ports)
• Align with ECS standards for NAT field mapping
• Enable better network traffic analysis, troubleshooting and more precise rule exclusions for alerts
• Maintain consistency with how other integrations handle NAT IPs

References

• ECS NAT Fields Documentation
• Similar NAT handling can be seen in other integrations like Palo Alto Networks and Fortinet FortiGate

[elasticmachine]

Pinging @elastic/security-service-integrations (Team:Security-Service Integrations)

[WesselPinew]

@efd6, thanks for implementing a fix for this so fast! Do you perhaps have any idea how long it usually takes to merge pull requests like this into main? We're really excited to upgrade our integration and have this resolved.

[efd6]

@WesselPinew Sorry, predictions like that are hard since I'd be predicting the behaviour of others. It shouldn't be too long though.