1 to 1 nat vip

Looks good from here. You'll need one additional policy for outgoing traffic from the phone switch. Not sure how well the SIP helper has matured, but you may need to muck with that as well. (muck as in delete...)

good call on the sip helper i am going to disable it right now. 

Also shouldn't the normal  outbound policy take care of it?

set srcintf "lan" set dstintf "wan1" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ALL" set utm-status enable set av-profile "AV" set ips-sensor "IPS" set profile-protocol-options "default" set ssl-ssh-profile "certificate-inspection" set nat enable

Your VIP will NAT the inbound traffic, but the outbound traffic will always use the WAN interface IP.

If you want to use the IP 7.7.7.8 for your PBX, you will need add the "nat-source-vip enable" on your NAT :

config firewall vip edit "Cisco-SIP" set extip 7.7.7.8 set extintf "wan1" set mappedip "192.168.1.5-192.168.1.5"

set nat-source-vip enable next

Lucas

This is not quite correct I'm afraid.

The option "nat-source-vip" prevents the reverse NAT (source NAT) of outgoing traffic from hosts which are not specified explictely in the VIP definition.

This implies (and is indeed the case) that a VIP definition alone will not only translate the destination address on incoming traffic but will also translate the source address in the reply traffic to the external IP address specified in the VIP. In former versions of FortiOS this had to be done manually by defining an IP pool for source NATting. At least from v4.3 on the VIP will take care of this.

As an example: in the DMZ (with 10.11.12.0/24) you've got a server 10.11.12.1. You want to make this server reachable via the public address 1.2.3.4. You create a VIP "ext2server" like this:

name "ext2server"

external address: 1.2.3.4

mapped to: 10.11.12.1

port forwarding: disabled

To put the VIP into effect you use it in a policy:

source interface: wan1

source address: any

dest interface: dmz

dest address: ext2server

service: ALL

action: accept

Now external traffic can reach the server located in the dmz as the destination address is translated from 1.2.3.4 to 10.11.12.1 . When the server responds, it's source address (which in reality is 10.11.12.1) is translated to 1.2.3.4 so that for the external host the whole NAT is transparent.

Now for the "nat-source-vip" parameter.

Enabling or disabling it will have no effect for the scenario given above, i.e. traffic to and from the intended host. But, if there is another host in the DMZ, it's source address is either the real address (if "nat-source-vip" is disabled) or the 'official' virtual IP address specified in the VIP (if "nat-source-vip" is enabled). Use this if your intention is to cloak or hide the true address space of the DMZ hosts, without creating a lot of VIPs or IP pools, as long as at least one VIP exists.

Ede gave a good example of inbound ( DNAT ) but the following policy as addressed will not be a 1-2-1nat

set srcintf "lan" set dstintf "wan1" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "ALL" set utm-status enable set av-profile "AV" set ips-sensor "IPS" set profile-protocol-options "default" set ssl-ssh-profile "certificate-inspection" set nat enable

The would not  SNAT to the same address of the VIP as stated. What I would do ( just another option ) is to build a ip pool and defined that in your  policy for traffic you allow outbound from the pbx point of view.As rwpatterson pointed out that policy is to broad unless that's what your intentions are but I would at least specifiy the srcaddr of the pbx and the services you want.

e.g

config firewall ippool     edit "MYPBX"         set startip 7.7.7.8         set endip 7.7.7.8         set comments "121-snat mypbx"

        set type one-to-one     next

than you apply this in the policy specifiy the  PBX server;

config firewall addr

   edit MYPBX_priv

     set subnet 192.168.1.5/32

    end

config firewall policy

   edit 0

      set srcintf "lan" set dstintf "wan1" set srcaddr "MYPBX_priv" set dstaddr "all" set action accept set schedule "always" set service "ALL"

set action accept

set utm-status disable set ssl-ssh-profile "certificate-inspection"

set nat enable

set poolname "MYPBX"

end

Ken

OK, the question is whether traffic originating from the internal PBX is NATted by the VIP. I would guess 'no' as you need an additional outbound policy. Use an IP pool with just 1 address to enforce source NAT.

In the inbound policy, you don't need to use an IP pool or enable "nat-source-vip". That was what I wanted to make a point of.

Agreed and traffic will only be nat  ( SNAT ) by whatever  policies you enable and after the route-selection and outgoing interfaces has been determine. This is why you have to fully understand both SNAT and DNAT and packet flow from a fortinet point of view. I remember  fortinet back in the mid 2000s used to have a pdf called "life of a packet" or something to that effect. For FCNSA they had numerous questions pertaining to this on the exam also ;)

A VIP has nothing to do with DNAT outside of services allowed from the inbound rule and returned traffic.

fwiw: the diag debug flow is a magical tool for understanding this process.

FortiAdmin you  the Man.

I would give you a few thumbs but I only have 2 hands 7 don't know howto add thumbs in  this reply ;)

At one time  I remember like a decade ago, the fortitrainers used to make all candidates going thru  fortigate basic 101 study that and the ingress vrs egress and how DNAT is totally determine differently than  SNAT.

I highlight the main items on this page within that section you pulled out. And attached it here. This is why  diag debug flow will teach  you good flow construction across a fortigate. In fact these 2  process are very similar to iptables  chains for pre-routing ( DNAT ) vrs post-routing ( SNAT ) .

DNAT in a fairness has very little to do with routing , while SNAT can only be determine after we've made a route-lookup ( pending RPF checks  pass/fail ) and have determine which interface to go out of.

Packets handled by  the VIP  will always return by the  policies that allowed the packet in the flow ( unless you have something else screwing up the fwpoliciy(s) ) . But traffic in a flow source from the inside has very little to do with the external facing VIP. You can indeed have services static-map or port-forward into a DNAT , but yet have traffic "sourced" from the server SNAT'd via a different source address  ( nat-overload-interface, ippool,etc....)