Destination NAT by Interface

Hi, you need to define a VIP (Firewall -> Virtual IP) on the incoming interface of that traffic with that mapping and use it in a corresponding policy. best regards, Roman

Could you please describe what you plan to do exactly? Do you want to exchange the (public) destination IP to a private one AND route that packet through a tunnel? Routing occurs before NAT, and I see a problem with that here as it calls for 2 consecutive routing decisions. But maybe I got you wrong.

thanks for your responses guys. This might help: http://www.gliffy.com/pubdoc/2695894/L.png Here is what' s going to happen: I have workstations that need to access a resource that' s on the other end of an IPSEC tunnel. The outgoing IPSEC packets must have the NATed source of 192.168.115.40. The router in front of the firewall routes by source address... it accepts packets from 192.168.115.40 and routes them all to 144.12.145.10. Therefore, I need to qualify traffic for a NAT, when it is outgoing on a port, with a given destination. The traffic will not be sourcing from another port, but on the Fortigate itself. Now, in addition to this, the destination 144.12.145.10 is a VPN, so this will reveal another subnet to be routed to that first hop, where I wish that to also be NATed. This source of this traffic will be off an port, internal1, destined for the hop on the other side of the VPN. source workstations>internal1>[IPSEC tunnel on fortigate]>{IPSEC packets NATed to 192.168.115.40}>dmz>router>{{cloud}}>router>[IPSEC endpoint]>destination resource I need to qualify traffic for a NAT, by destination IP, and destination port on the Fortigate. So... NAT to 192.168.115.40... if the traffic is destined for 144.12.145.10, and it' s leaving the dmz. Again, the only traffic that is destined for 144.12.145.10 will be the IPSEC packets. Any ideas? The VIP won' t work, since it is qualified by " incoming traffic," which no traffic will be incoming! It will only be outgoing. It' s funny, because this is an absolutely trivial thing on Cisco, but seems very complex on FortiOS. Any help is appreciated. Thanks! Matt

No that' s not complicated at all. From your detailed description it' s now clear that you need SOURCE NAT not destination NAT. The means for this is a) create an " IP pool" with just one address in it, namely 192.168.115.40 (Firewall>IP pool) b) check the NAT option in the corresponding firewall policy c) check the option adjacent to the NAT box and specify the IP pool. ...and hope that all works as expected. From other (recent) posts we learned that there might be issues if you use FortiOS 4.00MR3 on your FGT; when using IP pool the FGT won' t arp correctly. Use 4.2.6 instead.

Thanks for the reply. Either I' m confused by your response, or I' m not explaining it right. Your response makes sense to designate the traffic flowing from the LAN (ingress to internal1), and the policy that forces it to ENCRYPT over the IPSEC tunnel. But, I' ll be creating the VPN, and this VPN will have to use the NATed to address for it' s (IPSEC) packets, in which qualified packets from internal1 are encapsulated. Is the NAT designation part of the VPN phase configuration settings? Thanks very much for all your response! Matt

Hi Matt, Do you mean you want the tunnel itself to appear to be initiated from a different WAN side address than the actual WAN interface address ? In that case you can set up an Interface type IPSEC tunnel and specify the Source IP there (all done within the Phase 1 VPN settings). Or maybe I have completely misunderstood ? Matt

I think I get it now. Let' s assume that you build your VPN in interface-based mode - no action ENCRYPT but ACCEPT. I won' t say it couldn' t be done in the (old) policy-based mode but for processing the traffic itself it' ll be much more logical. As the VPN interface you obtain is a sub-interface of the WAN port it usually inherits the WAN IP as the source IP of outgoing (ESP/whatnot) packets. The tunnel itself carries no IP but you can assign one in the interface setup. But this doesn' t affect the ' outer' source IP seen by the next hop router. Same for the NAT in the policy: it only affects the tunneled traffic not the ESP packets. Seems there is no easy way to do it. What you can do is create a second VDOM to pipe your WAN traffic through, doing NAT, after the payload is encrypted. You separate the WAN traffic by destination address in different policies and then you can configure to NAT or not to NAT.

<Matt> I' m guessing you you mean the " Local Gateway IP?" I do not have the config info for the other end of the tunnel yet, but I just put in dummy info in the phase 1 and phase 2. for reference: http://www.gliffy.com/pubdoc/2695894/L.png I just did this:

  diag debug flow filter addr 144.12.145.10  diag debug flow trace start 100  diag debug flow sh console enable  

Then went to VPN>IPsec>Monitor then " Bring Up" the Phase 1. I see no traffic reflect in the flow trace. There should be some traffic in the flow trace, no? Thanks, </Matt>

<Matt> Thanks very much! This will work, as confirmed with Fortigate support (already had a ticket opened for 7 days when I created this thread). I wish they did change that wording to even " IPsec packet NAT" or something more clear. Thanks, </Matt>