1 to 1 nat vip

[ctrl_alt_del3t3]

Hello guys i have a fortigate 100d. I think it is a simple deal but i wanted to confirm either way. I have a phone system that is receiving sip traffic for telco. This telco system was connected directly to the net with a public address. I wanted to bring the phone system behind the firewall and nat all traffic to it. Please let me know if this is the right way to do it

FG100d

7.7.7.7 255.255.255.252 

telco

7.7.7.8 255.255.255.252 

First i would setup a vip like so External IP Address/Range 7.7.7.8-7.7.7.8 with a mapped internal address to 192.168.1.5-192.168.1.5

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" next

edit 4 set srcintf "wan1" set dstintf "lan" set srcaddr "all" set dstaddr "Cisco-SIP" set action accept set schedule "always" set service "Cisco-Phones" next

FGT100D # show firewall service custom config firewall service custom

edit "Cisco-Phones" set category "VoIP, Messaging & Other Applications" set tcp-portrange 5090:0-65535 5000:0-65535 set udp-portrange 9000-9049:0-65535 5060:0-65535 5090:0-65535 next

[emnoc]

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

[ctrl_alt_del3t3]

i chatted with support

Emran (09:19:43): Yes, you need to create a policy from lan to wan Emran (09:19:58): and NAT it to 7.7.7.8 IP address

Emran (09:23:00): First you need to create an ippool Emran (09:23:18): Firewall Object -> Virtual IP - > IP pools Emran (09:23:30): Create New Emran (09:23:37): Type: Overload Emran (09:23:56): EXternal IP range : 7.7.7.8-7.7.7.8 Emran (09:24:06): ARP reply : check Emran (09:25:34): Then create a policy Emran (09:25:37): LAN to WAN Emran (09:25:50): Enable NAT and select the ippool that you created

[ede_pfau]

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.

[emnoc]

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.

[FortiAdam]

First section in this doc is called "Life of a Packet".  It's a great troubleshooting resource that I have referenced many times!

http://docs.fortinet.com/...roubleshooting-522.pdf

[Shawn_W]

Thank you for the doc.  Nice to have a good resource to reference for troubleshooting.

[emnoc]

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....)

[afoglia]

The other obvious path you could take for the outbound nat is to build a one-to-one ip pool with the public ip of 7.7.7.8 and then in your outbound policy for the phone system, set the nat to use the ip pool.