Skip to main content
dairu
New Member
October 6, 2022
Solved

Azure Fortigate NAT issue - VIP webserver inaccessible when NAT is disabled

  • October 6, 2022
  • 8 replies
  • 8155 views

I just setup a Fortigate under Azure recently, we have a web server behind the Fortigate with Virtual IP configured. It is working fine, I could access the website externally. But when I disable NAT, web server is inaccessible.  We would need the NAT disabled as there is a script from the webserver that needs to capture the original source  IP of the web visitior.

 

Here's a sample of the network:
(Azure Public IP) --> Fortigate Port1 (WAN facing) --> Fortigate Port2 (LAN Port) --> Web Server IP

Where:
FG port1 = 10.1.1.5
FG port2 = 10.0.0.5
Webserver = 10.0.0.4

 

Currently the webserver only captures the 10.0.0.5 IP because of NAT, instead of the Original IP of web visitor.

What would be the best way for the webserver to capture the original IP of web visitor?

 

Best answer by dairu

I have finally resolved it. Sharing what I found.

 

Found out Azure VMs has built-in NAT gateway that forces the internet outbound connection of VM. (Even if you change the actualy gateway IP inside the VM.) Thats why we get different IP when we run ipchicken or whatsmyip.

 

So there will be two things to fix it,

(1) additional routing within the Fortigate and

(2) create a table route from Azure Route Table and associate it to Vnet connected to Fortigate's internal subnet. 

 

This link helped me, contains the needed IP routing:

https://docs.fortinet.com/document/fortigate-public-cloud/6.2.0/azure-administration-guide/609353/network-interfaces-and-routes

 

After this, webserver could now get the Original IP of web visitors when NAT is disabled. Connection also does not break when disabling NAT. IPchicken on webserver is now the Fortigate-assigned Public IP.

 

Hope this help you also!

8 replies

Debbie_FTNT
Staff & Editor
Staff & Editor
October 6, 2022

Hey dairu,

 

if disabling NAT on FortiGate breaks the connection, it sounds as if the webserver doesn't know what to do with public (non-NATed) source IPs.

Does the webserver have a default route/gateway configured? From your setup, default route/gateway should be port2 on FortiGate.

That way, if the webserver receives traffic with for example source IP 1.1.1.1, it has a route back to 1.1.1.1 via port2 on FortiGate (its default route) and no inbound NAT should be required.

dairu
dairuAuthor
New Member
October 6, 2022

As Azure has also a default route for the VM webserver, do I need to change it via Azure also? or just under the Fortigate? What would be the proper setting.  Also, I noticed that when I'm inside the webserver, webserver could only ping up to port1 (10.1.1.5) only. But not public IPs like 8.8.8.8, etc.

 

Current static route from Fortigate is

0.0.0.0/0 10.1.1.1 port1
10.1.0.0/16 10.0.0.1 port2

 

What would be the proper route?

Debbie_FTNT
Staff & Editor
Staff & Editor
October 6, 2022

Hey dairu,

you would have to set the default route on the webserver itself, destination 0.0.0.0 and gateway FortiGate port2 interface.

The FortiGate might need a policy from port2 to port1 to allow the webserver access to WAN/internet, and for that policy you should enable NAT (set the VIP IP as outgoing NAT if you can).

I don't believe you need to set anything in Azure, but I don't have much experience with Azure environments.

brychrisdet
New Member
October 10, 2022

I am having this exact issue and am uncertain how to overcome it. My server hosted at Azure also needs to be able to see the original IP of the agents connecting in, but it only shows the private IP of the FGT's WAN interface, which is associated to an Azure Public IP. All my agents appear to be coming from the same IP. When I disable NAT on the policy, it breaks the service. Looking up my host's IP in IP Chickent also shows a different Azure IP that is not my Azure Public IP. I am only trialing this FortiGate VM in Azure, and this may be a show stopper. How can we overcome this?

baldchiapet75
New Member
October 10, 2022

I have a similar request from my customer as well. You want the firewall to include the "X-Forward-For" header information, which is the original requester IP address. After doing some digging it doesn't appear there is a way to include that info by default, but there is a way to do it using Transparent Proxy. Unfortunately I haven't tested it out but the configuration info is below.
Handbook | FortiGate / FortiOS 6.0.0 | Fortinet Documentation Library

dairu
dairuAuthorAnswer
New Member
October 12, 2022

I have finally resolved it. Sharing what I found.

 

Found out Azure VMs has built-in NAT gateway that forces the internet outbound connection of VM. (Even if you change the actualy gateway IP inside the VM.) Thats why we get different IP when we run ipchicken or whatsmyip.

 

So there will be two things to fix it,

(1) additional routing within the Fortigate and

(2) create a table route from Azure Route Table and associate it to Vnet connected to Fortigate's internal subnet. 

 

This link helped me, contains the needed IP routing:

https://docs.fortinet.com/document/fortigate-public-cloud/6.2.0/azure-administration-guide/609353/network-interfaces-and-routes

 

After this, webserver could now get the Original IP of web visitors when NAT is disabled. Connection also does not break when disabling NAT. IPchicken on webserver is now the Fortigate-assigned Public IP.

 

Hope this help you also!

brychrisdet
New Member
October 12, 2022

I'm on this same track too. It's all a routing issue due to those default routes that Azure creates. I have the new route tables built, I just need to wait for some planned downtime to flip them over and disable NAT.

Thought Leadership Security Summit. Outpace New Threats with AI - enhanced defense. Tuesday, Septmeber 15, 8:30 AM - 2:30 PM PT. The Golf Club at Newcastle, WA.
Fortinet Flag the Hack. Wednesday, August 26, 9:00 AM - 5:00 PM ET, COSM, Atlanta, GA.