FEATURE REQUEST - Full Pre/Post NAT IP Visability

Issue:

After working with support apparently for devices that perform NAT (such as netflow export from a Palo Alto Firewall) where the flow includes an IP that is NATTED you can only see some of the IPs involved in the actual NTA conversation.

Example 1 (no NAT):

10.10.10.1 access an internal IP 10.20.20.20.

In NTA you see a conversation between 10.10.10.1 and 10.20.20.20

Example 2:

10.10.10.1 access a public website 179.179.179.1, the firewall NATs all outbound traffic to the internet to a public IP of 75.75.75.1

In NTA you only see a conversation between 75.75.75.1 and 179.179.179.1

This is not very useful as you cannot see the actual LAN host/IP in the conversation (10.10.10.1).

All IPs are being sent via netflow as seen in packet captures on Orion.

Feature Request:

Simply add four fields in NTA showing SRCADDR, Post NAT Source IPv4 Addres, DSTADDR, Post Nat Destination IPv4 Address when you drill into conversations. This would allow anyone with a device performing NAT and sending flows with NAT involved to drill in and see the relevant information needed.

Thanks!

Ken

Find more posts tagged with

postnat

palo alto

post nat

nta

nat

natted

Status: None

Comments

abdulraheemsidz

A must feature, NTA Netflow data would be useless without showing actual source/destination IP address in case of NAT environment, instead of enabling the netflow on device before the NAT device.

gmalveaux

This feature is definitely a must.

rschroeder

I like this idea, and have voted it UP.

Until your idea actually becomes an deployed new feature, I wonder if you don't have another option for seeing the source and destination information using NetFlow.

It looks to me as if you're capturing your NetFlow data at an external-facing interface, perhaps on the firewall, perhaps on an external edge router, where the true internal address is hidden by NAT so it looks like the firewall's external IP address. Obviously NetFlow has no idea about the firewall's NAT; it's pretty basic, and can only show you the firewall's NAT'd address as the source. It's because you're monitoring after the traffic hits the firewall.

That's not the only place you can capture NetFlow, and until SW adopts your excellent suggestion, you can get the data you want from the internal L3 interfaces that route traffic from access devices towards the Internet. Netflow on the router upstream from your PC will show you the true address of the internal source device, along with conversations or attempts to communicate with an external address on the Internet.

Simply set up NetFlow on L3 interfaces between the access devices and the firewall. This will allow you to capture traffic destined to specific sites, or from specific internal addresses.

Caveat: If your internal devices are forced to point to a proxy server before they can get to the firewall or Internet, the "easy" part of this just went out the window. Proxies mean you're going to see the proxy server's address as the source of the traffic hitting the firewall unless the firewall itself is your proxy server. If the firewall IS the proxy server, then all you need do is set up NetFlow on the Internal interface of the firewall and send the output to NTA.

Or, if you happen to be the firewall administrator, you can read the correct src & dst right on the firewall's packet captures and audit logs. If the audit logs are sent to an external SIEM like Splunk, it's super easy to query the SIEM and see the true src and dst addresses.

If the proxy server is NOT the firewall, you're still OK if you can set up NetFlow on the L3 interfaces between your access devices and the proxy server.

I have that setup now, and it works well, despite my company's reliance on proxy servers for filtering web access and content. I simply open up NTA and search for the source address (my PC, for example). I find all traffic requests from my PC because I have NetFlow enabled on the L3 interface routing my PC's subnet upstream. It shows my request to visit any site, it shows the source & destination address, and the proxy server isn't a problem unless your NetFlow monitoring happens AFTER the proxy server.

Even better, I can search NTA for Conversations associated with either an Internal source address or an External destination address and see ALL the traffic. Or I can open up NTA to show me End Points, or filter on a specific time frame, and more.

I believe you should be able to get the data you need without having to wait for your Feature Request to come through, as long as you set up NetFlow on the L3 routing interfaces or SVI's for the first hop away from your PC or other access device.

Swift packets!

Rick Schroeder