The MIP will NAT the destination IP from Public ip to private IP. The source IP is not changed, with src-nat enabled, FW changes the source IP as well and NATs it to the trust interface ip address.
If you are not able to get the connection without src-nat, then it will indicate that the server in trust zone is unable to reply the packet back to the source public ip of traffic. This can happen when the server in trust does not have the FW interface IP as its default gateway.
Hope this helps.
If this update is helpful, you may mark it as accepted solution for others to benefit from it.
Check your interface mode whether route or nat mode first for both internet facing and inside interfaces.
And second thing clearly mention what type NAT you think to deploy, Source NAT, Destination NAT. MIP is basically used to Destination NAT.
is the public IP 202.58.xx.xx used for MIP same subnet of internet facing interface or not ? is there Routing device between firewall and ISP if you use different subnet IP than internet facing interface ?
I have checked the Interface and both are using route. We have about 6 external IP that I can assign to an interface.
Here is an example of a policy I have on the firewall (I changed the IPs)
ID Source Destination Service
106 Any MIP(205.251.xxx.xxx) AutoSyn (TravelerNotes), HTTPS, PING -- Untrust/Internet to DMZ
104 Any MIP(205.251.xxx.xxx) Winframe, Ping, HTTPS -- Untrust/Internet to Trust
103 Any MIP(205.251.xxx.xxx) Mail, Ping -- Untrust/Internet to Trust
All of the policy above is not using NAT Source Translation (Under Advance Settings of the Policy).
ID 106 is working ok, means I can ping it from external network and it receives data inbound and outbound ok.
ID 104 and 103 does not work and will only work if I enable NAT Source Translation. Again I have almost the same settings and configuration on the 2nd firewall we are using and everything is working ok without enabling NAT Source Translation.