Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
NBhatti
New Contributor

SNAT not working on Firewall itself

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

1 Solution
ede_pfau
SuperUser
SuperUser

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

 

Ede Kernel panic: Aiee, killing interrupt handler!

View solution in original post

Ede Kernel panic: Aiee, killing interrupt handler!
6 REPLIES 6
ede_pfau
SuperUser
SuperUser

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

 

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
NBhatti

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?

ede_pfau

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 Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
NBhatti

ede_pfau wrote:

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.

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?

Andreas77_FTNT

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.

 

dkraljevich

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.

 

https://kb.fortinet.com/k....do?externalID=FD47104

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors