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

Source IP passthrough to nat clients

Hi All, I am NATing 2 servers through a fortigate firewall. Internet | Fortigate (NAT) | | VM1 VM2 When I check the access logs on the servers being NATed (VM1, VM2) all the traffic has the source IP of the fortigate server. How can I make it so the original source IP is sent down the NAT to the destination servers? Thank you
16 REPLIES 16
ede_pfau
Esteemed Contributor III

Uncheck the NAT checkbox in the policy in which you use the VIP.

Ede

"Kernel panic: Aiee, killing interrupt handler!"
junglecom

If I uncheck the NAT box then NAT no longer works and I can no longer access my server. I am using static nat Are you sure about this?
ede_pfau
Esteemed Contributor III

There are 2 sorts of NAT: 1. destination NAT - the destination address is substituted in FortiOS this is realised via VIP 2. source NAT - the source address is substituted in FortiOS, if you check " NAT" in the policy, source address is exchanged for the address of the egress interface if you check " dynamic NAT" and specify an IP pool, then addresses from the pool are used instead of the interface address. The symptoms you gave indicate that you are using source NAT. Public access to an internal server via VIP works without source NAT. So if you cannot reach your servers anymore after disabling (source) NAT then your setup is incorrect. - to which interface does your default route point to? - how do you check that a server is accessible? ping doesn' t work if you port-forward!

Ede

"Kernel panic: Aiee, killing interrupt handler!"
junglecom
New Contributor

OK i must have this configured wrong then. Default route I am not sure about. I have 3 interfaces: Global with static route gateway02 Management with static route gateway01 Private with no gateway I have a VIP (59.222.94.5) that is mapped to a server with the private IP (172.18.0.67). It is a one to one mapping. (static NAT) My policy is attached as a screenshot. I test by trying to ssh into the server.
emnoc
Esteemed Contributor III

Disable the enable NAT check box and you should be fine. With VIPs you don' t need to enable NAT.

PCNSE 

NSE 

StrongSwan  

junglecom
New Contributor

If I do that I can no longer access the server via ssh or anything else. Thats my issue here. Here is my VIP settings
ede_pfau
Esteemed Contributor III

You haven' t answered my question yet: which routes do you have installed, esp. for the private LAN? -> Routing Monitor

Ede

"Kernel panic: Aiee, killing interrupt handler!"
junglecom
New Contributor

Sorry, I didn' t know how to answer. Thanks for the tip. Here are my routes.
ede_pfau
Esteemed Contributor III

OK, imagine you are a packet from an arbitrary address coming in on port2, destination 59.22.94.5 which is your server. The FGT translates your destination IP address to 172.18.0.67 and forwards you to port3 where the server is found using ARP. All of this WITHOUT checking the NAT box in the policy, as it should be. Now, the server responds. Destination address now is some address on the internet. First, the server looks up it' s own routing table where hopefully it finds 172.18.0.1, the port3 address of the FGT, as the default gateway. IF THIS IS NOT THE CASE any return traffic must fail! Now you (the reply packet) reach the FGT on port3. Looking into the routing table, this address is matched by 2 routes: one to port1, one to port2. Which one to take?? Depending on the server' s address, being either odd or even, port1 or port2 will be chosen. So depending on the server' s address you are forwarded to the wrong port and discarded. From the outside it looks like the packet has never reached the server but that' s not true. So, do the following: - clarify which port leads to the internet - create one default route to this port - if you cannot reach any host on the port1 subnet anymore, the routing there is wrong - you should be able to ping your server from the internet now

Ede

"Kernel panic: Aiee, killing interrupt handler!"