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?
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 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:
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!
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.
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?
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.
Created on 10-06-2022 02:23 PM Edited on 10-06-2022 02:41 PM
HI Debbie,
I have the same setup even before, but website is still inaccessible when inbound NAT is disabled.
I've even tried the outbound default NAT, and even the IP-pooled outbound NAT for the LAN-to-WAN policy, but still the same.
What's funny is that I could only ping up to the port1 of Fortigate right? and not able to ping to Public IP right? But weird that I have internet from the VM webserver. But no traffic logs are going thru the Fortigate even if my VM webserver's gateway is Fortigate Port2.
I've looked up that Azure has its own NAT gateway. Looks like this might be the cause. When I access "What's My IP" from web browser of VM, it shows different Public IP and not the Fortigate-assigned Public IP. Website is still inaccessible though when no NAT inbound.
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?
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
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:
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!
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.
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 |
---|---|
1517 | |
1013 | |
749 | |
443 | |
209 |
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.