Hi,
I have to Source NAT two voip phones connected by a LAN (A_LAN) with a Fortinet 600D firewall port to speak with a Call Manager and viceversa. I have create a VIP definition and a policy for it. After NAT process the packets sent by phones will address some GRE tunnels. I would like to know if the syntax is ok or in the VIP definition I have to add "set nat-source-vip enable" in the VIP definition or further policies in the firewall policy or use IP pools
---------------
VIP definition
---------------
edit "A_VOIP_PHONE_1"
set uuid 329a7a02-a3db-51ea-a515-68fab7d1ce5f
set extip 10.1.180.171
set mappedip "10.18.1.171"
set extintf "any"
next
edit "A_VOIP_PHONE_2"
set uuid 329ad952-a3db-51ea-dea5-7de08db5ef41
set extip 10.1.180.172
set mappedip "10.18.1.172"
set extintf "any"
next
----------------
Policy Definition
----------------
edit 3
set name "A_AD_VOIP"
set srcintf "A_LAN"
set dstintf "GRE-AD-211" "GRE-AD-213"
set srcaddr "A_VOIP_PHONE_1" "A_VOIP_PHONE_2"
set dstaddr "A_CALL_MANAGER"
set action accept
set schedule "always"
set service "SIP" "A_RTP"
set nat enable
next
thanks
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Well for Source NAT, yes you would use policy ID 3 to configure the appropriate NAT settings (Likely dynamic one-to-one SNAT).
If you have a policy for traffic coming from the CallManager and you need to reach the phones (i.e. not just return traffic that was initiated by the phones) then you also need to do DNAT. This is where VIPs come into play.
See here for more info: https://docs.fortinet.com/document/fortigate/7.0.6/administration-guide/510402/static-virtual-ips
May I ask one question? Why do you need to use NAT here? Why can you not just route the packets directly to/from the phones?
For source NAT you do not need to configure VIPs. Just set the NAT configuration in the Firewall policy for Source NAT.
Some more info:
https://docs.fortinet.com/document/fortigate/7.0.6/administration-guide/29961/dynamic-snat
Thanks for your support Graham!,
does this mean that can use the policy created with GRE tunnels in case modify them (I have two, one for each direction see in the example one of them), or create further policies ?
Well for Source NAT, yes you would use policy ID 3 to configure the appropriate NAT settings (Likely dynamic one-to-one SNAT).
If you have a policy for traffic coming from the CallManager and you need to reach the phones (i.e. not just return traffic that was initiated by the phones) then you also need to do DNAT. This is where VIPs come into play.
See here for more info: https://docs.fortinet.com/document/fortigate/7.0.6/administration-guide/510402/static-virtual-ips
May I ask one question? Why do you need to use NAT here? Why can you not just route the packets directly to/from the phones?
Great Graham, thank you very much!
to reply to your question the phones are in a subnet different from the call manager subnet and call manager want to see only phone source IP coherent with its subnet . I accept your reply cheers, thx for your support!
Created on 09-16-2022 11:41 AM Edited on 09-16-2022 11:42 AM
Hi you are most welcome—always happy to help. However, based on your response, in this case I do not think you need NAT here. Are you sure you need NAT?
I have managed many CallManager deployments in the past and never needed to use NAT for phone communications.
Graham to reply to your question source NAT is required because we interface another function that check the source address to receive the packet and they wish that we translate the our local packet source addresses to the packet source addresses they require
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1733 | |
1106 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.