The term external network comes from OpenStack terminology, in OVN world it would be a logical switch with logical router gateway port. Currently if such logical topology is created, then the reply packets (eg. ARP, ICMP, TCP acks) don't get tunneled back to the sender. For instance let there be a LS called `external`, a LS called `internal` and a router. The external LS is attached to the router and the LRP is set as the gateway. The internal LS is also attached to the router. Let there be an LSP on each LS respectively. Each logical entity has is bound to its own chassis, the LRP is hosted on the gateway chassis. The two crucial scenarios are as follows:

1) SNAT: The internal LSP talks to the external LSP using snat type NAT entry that NATs the traffic with the GW IP address. In this scenario OVN the traffic is centralized through the gateway node but the reply is dropped on the node hosting the external LSP and is never sent back through the tunnel to the gateway node for the reverse NAT.

2) DNAT: The external LSP talks to the internal LSP using the dnat_and_snat NAT entry type. In this case the ARP resolution of the DNAT external_ip was not successful because the ARP responder is located on the chassis where the IP is hosted - where the internal LSP is bound and the ARP request was not sent to the tunnel between the chassis hosting the external LSP and the gateway chassis.

There is attached DB with following objects of interest:

LS internal_geneve with LSP 192.168.101.38 with associated dnat_and_snat entry with external_ip set to 192.168.100.232

LS external_geneve with LSP 192.168.100.53

LR router_between_geneve_networks connecting the two networks treating the exterenal_geneve as external