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

What does enabling/disabling the NAT option in a Policy exactly do?

Hello, I have been wondering what is the precise behavior of the NAT option in an IPv4 Policy. I have several machines connected through a Fortigate 200D and I don't need NAT since they're all in a private network. However, I noticed a strange behavior when I enable the NAT option (at least it sounds very strange to me). I have two Windows servers with an SQL database and they communicate through the Firewall (each server needs to connect to the other one's database). It works but the connection to the DB is very slow one way (slow enough to cause problems in some applications). I tried without the Firewall and the issue remains (so not a FW problem).

BUT, I noticed that when I enable the NAT option in the policy between these two servers, the issue seems to go away (connection to the DB is fast). I don't change the policy in any way apart from the NAT option.

 

I know it might be out of topic since the problem exists without the FW but I want to figure it out and knowing what the NAT option exactly do (and why it "fixes" my problem) could help me. The IP addresses are as follows : Server 1 : 10.1.10.2/24   connected to the FW interface1 (10.1.10.1/24)

Server 2 : 10.1.11.2/24   connected to the FW interface2 (10.1.11.1/24) Does anyone have a clue what is going on? Thanks in advance, Simon.

1 Solution
ede_pfau
Esteemed Contributor III

The NAT option enables source NAT, that is, all outgoing traffic will have per default the interface's address as it's source address. To experiment further, you could create IP pools with just one single address, and specify it in the NAT policy. You will see an adverse effect at last when you put in the real address of the server...

 

No idea why the servers behave in this way, sorry (I'm not into applications).


Ede

"Kernel panic: Aiee, killing interrupt handler!"

View solution in original post

Ede"Kernel panic: Aiee, killing interrupt handler!"
5 REPLIES 5
ede_pfau
Esteemed Contributor III

The NAT option enables source NAT, that is, all outgoing traffic will have per default the interface's address as it's source address. To experiment further, you could create IP pools with just one single address, and specify it in the NAT policy. You will see an adverse effect at last when you put in the real address of the server...

 

No idea why the servers behave in this way, sorry (I'm not into applications).


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
tanr
Valued Contributor II

Is it possible something else has the same IP as one of your servers?

Does a tracert/traceroute from Server 1 to Server 2 show with NAT disabled give any insights? 

Any VIPs or Policy Routes?

 

lhsit
New Contributor III

Hi Simon,

I would investigate the routing paths between the two networks.

Without the NAT option, when Server1 talks to Server2, Server2 will reply via the default gateway, and traffic will be routed to Server1 via the router.

With the NAT options, Server2 will reply direct to the FG's interface on Server2's network, so the default gateway / router doesn't get involved.

Cheers,

Chris.

emnoc
Esteemed Contributor III

Maybe the DBS instance are doing some  sort of DNS lookup and enabled/disable of NAT the name is being  looked up and does not match the  PTR

 

Just a guess

 

Ken

PCNSE 

NSE 

StrongSwan  

PCNSE NSE StrongSwan
aagrafi
Contributor II

I suspect a routing issue here. When doing NAT (I guess you are NATing to the outbound interface address) the firewall uses it's own IP address to do the translation and this IP address is been properly routed. Without NAT, the packet carries the real server's IP address and maybe this address is not properly routed (for example, if you are routing only with default route, this might not be enough).

Labels
Top Kudoed Authors