Traffic Flow of Destination NAT through Edge Gateway

Did you ever wonder how the traffic flows when you create a Destination NAT? If the answer is Yes then you should follow the rest and if no then you already know how it works 😀

Destination NAT (DNAT) maps an unregistered IP address to a registered IP address from a group of registered IP addresses. Destination NAT also establishes a 1:1 mapping between unregistered and registered IP address, but the mapping could vary depending on the registered address available in the pool, at the time of communication.

The typical usage of this is to redirect incoming packets with a destination of a public address/port to a private IP address/port inside your network.

The internal network is usually a LAN (Local Area Network), commonly referred to as the stub domain. A stub domain is a LAN that uses IP addresses internally. Most of the network traffic in a stub domain is local, it doesn’t travel off the internal network. A stub domain can include both registered and unregistered IP addresses. Of course, any computers that use unregistered IP addresses must use Network Address Translation to communicate with the rest of the world.

So now let me show you a example design where we are mapping (DNAT) an External IP Address to an Internal IP Address.



In this example we are mapping to an internal VM IP which is This is pretty straight forward and does not need any explanation. I will now show you the flow diagram and will explain how the packet flows.


Now look at the above diagram. Lets say we have a client in the external network who is trying to connect to the internal VM which is inside the Org vDC network and has an internal IP Address (

Now the client will send an ARP for the external address which is Your Edge device’s external interface has an external IP address. That will listen and will reply saying that ARP is in his external MAC. Once this is done, then your Edge will query the database (Routing Table?) and will see that there is a 1:1 mapping of its internal IP, it will send the packet through the internal interface to the appropriate VM.

So destination NAT changes the destination address in IP header of this packet. It may also change the destination port in the TCP/UDP headers.


About Prasenjit Sarkar

Prasenjit Sarkar is a Product Manager at Oracle for their Public Cloud with primary focus on Cloud Strategy, Cloud Native Applications and API Platform. His primary focus is driving Oracle’s Cloud Computing business with commercial and public sector customers; helping to shape and deliver on a strategy to build broad use of Oracle’s Infrastructure as a Service (IaaS) offerings such as Compute, Storage, Network & Database as a Service. He is also responsible for developing public/private cloud integration strategies, customer’s Cloud Computing architecture vision, future state architectures, and implementable architecture roadmaps in the context of the public, private, and hybrid cloud computing solutions Oracle can offer.

3 Replies to “Traffic Flow of Destination NAT through Edge Gateway”

  1. Pingback: Traffic Flow of Destination NAT through Edge Gateway – Stretch Cloud | IP

  2. Prasenjit, thanks for sharing this. What about SNAT if using a nexus port profile based external network, I was mapping a single external ip to multiple internal private ips. However something was wrong that my edge routed external network was allowing all traffic to pass sometimes and others none.
    I feel my edge firewall rules may be the issue so I disabled the firewall and still could not talk to any external ip.

    • Hi Dinesh,

      Let me get some clarity on this.

      How many IPs you have dedicated there in the external network? Did you put some IP in the sub allocation pool and tried to map that in a SNAT rule?

      There should not be any problem from the Edge perspective, it may have some config issues.

Leave a Reply