Charles,
Thank you for your question. The VDB mount scripts are generated with the mount-from address determined by the interface on the Delphix Engine that is closest to the target. Thus, only addresses that the Engine is aware of would be used, which rules out NAT. Typically, the Engine is in the same security domain as its targets, so NAT between them isn't an issue. There is currently no supported method to override this, but I have raised the issue with Engineering, requesting they add a configurable setting to allow use of the NAT address to mount VDBs. This will obviously not be a short-term solution for you.
If your target is Linux, or a *nix that has iptables installed, you can overcome the NAT issue using a DNAT (destination NAT) for outbound traffic from the target. A rule similar to this would work:
iptables -t nat -A PREROUTING -d 10.2.0.1 -j DNAT --no-destination 192.115.106.31
This instructs iptables to NAT the destination of outbound packets destined to 10.2.0.1 (substitute the actual address of the Delphix Engine here) to 192.115.106.31 (substitute the Engine's NAT address here) before putting the packets on the wire. This will add CPU load on the target and add latency to every packet transmitted, so performance will suffer, probably noticeably, but should at least allow VDB provisioning to succeed.
A better option may be the creation of a private network for the NFS traffic between Delphix Engine and its targets. The Engine
does not route traffic, consequently can't bypass the security between production and non-production domains that the NAT is intended to maintain.
Cheers,
Michael