Hi Guys, I am new to FortiNet family and trying to learn things. I am trying on a FortiGate 300D factory reset box with version 6.2.1. The configuration is simple where I have a VLAN interface which communicates to a Cisco 7201 over private IP address. Since Cisco 7201 does not support NAT, I have to SNAT my source IP to the default gateway (Router). The problem I am facing is that if I try to use FortiGate as a default gateway for internal LAN, everything works fine and I am able to do SNAT just fine. I am just not able to SNAT from the firewall itself. Have tried all sort of possible in/out interface, source/destination addresses. But my trace goes to my default gateway with private IP address without source nat.
FortiGate-300D # diag sniffer packet any 'host 1.1.1.1 and icmp' 4
interfaces=[any]
filters=[host 1.1.1.1 and icmp]
7.084324 wan out 10.99.99.39 -> 1.1.1.1: icmp: echo request
7.084326 port2 out 10.99.99.39 -> 1.1.1.1: icmp: echo request
Where as if I try to ping public IP from my LAN, SNAT works fine
FortiGate-300D # diag sniffer packet any 'host 1.1.1.1 and icmp' 4
interfaces=[any]
filters=[host 1.1.1.1 and icmp]
1.212742 vlan-101 in 10.2.20.100 -> 1.1.1.1: icmp: echo request
1.212876 wan out 103.83.89.39 -> 1.1.1.1: icmp: echo request
1.212878 port2 out 103.83.89.39 -> 1.1.1.1: icmp: echo request
1.237508 wan in 1.1.1.1 -> 103.83.89.39: icmp: echo reply
1.237516 vlan-101 out 1.1.1.1 -> 10.2.20.100: icmp: echo reply
1.237518 port1 out 1.1.1.1 -> 10.2.20.100: icmp: echo reply
This is my current SNAT policy which works for LAN only,
config firewall central-snat-map
edit 1
set orig-addr "vlan-101 address"
set srcintf "vlan-101"
set dst-addr "all"
set dstintf "wan"
set nat-ippool "103.83.89.39"
next
end
And I can't seem to figure out why the firewall itself not able to SNAT for it's source IP. :S
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.
I agree it would be elegant to treat FGT's own traffic ('local') identically to other traffic. But, this is not the case.
FortiOS has a (obscure) algorithm to attach one of it's interface addresses to local outbound traffic - which sometimes results in funny traceroute output. Over the years FTNT has realized that sometimes local outbound traffic needs to have a specific source address.
So for local outbound services you may (for the most part) set a 'source-ip' in the CLI where the service is configured. FortiAnalyzer traffic, ping, FMgr come to my mind. For example, in the CLI type
'exec ping-option source 1.2.3.4' and then 'exec ping 9.9.9.10', and in the sniffer output you will see that SNAT is effective. Of course, the source IP needs to come from one of the 'connected' networks, so that routing can take place.
If you want to find all places where you can 'set source-ip', do
'show full | grep -f source-ip'.
I agree it would be elegant to treat FGT's own traffic ('local') identically to other traffic. But, this is not the case.
FortiOS has a (obscure) algorithm to attach one of it's interface addresses to local outbound traffic - which sometimes results in funny traceroute output. Over the years FTNT has realized that sometimes local outbound traffic needs to have a specific source address.
So for local outbound services you may (for the most part) set a 'source-ip' in the CLI where the service is configured. FortiAnalyzer traffic, ping, FMgr come to my mind. For example, in the CLI type
'exec ping-option source 1.2.3.4' and then 'exec ping 9.9.9.10', and in the sniffer output you will see that SNAT is effective. Of course, the source IP needs to come from one of the 'connected' networks, so that routing can take place.
If you want to find all places where you can 'set source-ip', do
'show full | grep -f source-ip'.
I agree as well, but ping and trace is not the only concern. The F/W needs to download A/V signatures and check for updates etc, check other security stuff online and for that it needs to go online to the internet. I was able to get ping work by having specific source address, but like I mentioned there are other things which needs internet access.
I am assign a public IP address to the firewall itself and let do the f/w take care of reaching internet for itself, but would that be the only, perhaps a good approach?
Certainly the least cumbersome. I think that for subscriptions you can specify a source-ip but you can never be sure you catch them all.
Have you had a look into the Central NAT table? It governs NAT regardless of which policy traffic takes. Maybe local traffic can be influenced by that.
ede_pfau wrote:Central NAT table only showing defined interfaces it does not shows anything related to local traffic. I tried all possible combinations of in/out interfaces, security policies but it just won't work. Maybe there is something in the CLI which can influence local outbound SNAT?Certainly the least cumbersome. I think that for subscriptions you can specify a source-ip but you can never be sure you catch them all.
Have you had a look into the Central NAT table? It governs NAT regardless of which policy traffic takes. Maybe local traffic can be influenced by that.
Hi,
From where is this echo request packet being sent :
7.084324 wan out 10.99.99.39 -> 1.1.1.1: icmp: echo request If this is from the FGT itself using ping command ?If so, this is local traffic and I'm afraid you cannot use SNAT on that.Hi all.
I am in a similar situation, where a local traffic needs a SNAT to be applied to it, which will not happen because the traffic is started in the FW and it is not through it, for which I indicate a KB that talks about that , I hope it helps.
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 |
---|---|
1709 | |
1093 | |
752 | |
446 | |
231 |
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.