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

Routing / "public ip"

Hi! I'm trying to crack the code behind this Fortigate, and must admit I'm not there yet.

Given the schematic below, how do I get a public IP behind a fortigate in NAT mode without adding a second transparent v-dom.



5 Solutions

Your diagram has no public IPs behind the FortiGate.  This needs to be done on the router in front of the FortiGate obviously.


Once the packet reaches the FortiGate there are 2 possibilities depending on what you need

1) You need to change that public IP to a private destination

Configure a Virtual IP on Wan1,  set it to translate the public IP to a private IP and create a firewall policy using that VIP as a destination.


2) You need the leave the destination IP unchanged

This requires 2 simple steps.

     i) A firewall policy to allow the packes to grom from WAN1->(whatever interface the public IP is behind)

     ii) a route to that public IPSince the default gateway is going to be out WAN1, then you need to route that IP another way.



View solution in original post


Well i guess just break it down step by step.


Step 1) Get packets routing from Cisco to FortiGate wan1

Step 2) Get packets through FortiGate.


So assuming there's no issue on the cisco side i will assume you have packets coming from the Cisco and reaching the FortiGates WAN1 interface.

That can be double checked with a packet sniff -- diag sniff packet any 'net mask' 4


Using your diagram what you need in addition to this on the FortiGate is

1) A firewall policy WAN1->Port2 (to allow communication from the outside)

2) A firewall policy Port2->WAN1 (to allow communication from that device to the internet)

3) A route to the hosts subnet behind port2

Destination IP/Mask: Device: Port2

Gateway: (none) - Give Port2 a 192.168.1.x/ IP address that doesn't match the host and the route will be added automatically

View solution in original post


Normally you can't have multiple route to the same IP that are the same distance out different interfaces. The FortiGate won't let you.

In order to do this you need to enable overlapping subnets. 

As long the same IP does not exist behind both interfaces at the same time you won't have a problem.  If you do, then your going to have an issue since the MAC address table will show whichever host last sent a packet.


config system setting

   set allow-subnet-overap enable



You only need to have a gateway IP in your route if the IP address/range you're trying to connect to is outside the range of the interface itself.

You diagram doesn't include Port IP addresses of the FortiGate, but i would assume that Wan1 has an IP in the subnet.  Not sure what IP port 2 has right now, but it's not ia 192.168.1 IP obviously.


Once you enable the subnet overlapping you could assign a IP to port2 or setup port2 with a secondary ip in the range.  Once you associate a IP to port2 (through either method) you probably won't need to add a route. (not 100% certain about that ... say 80%)


Pretty sure that you can do a secondary IP from the GUI in any firmware version.



View solution in original post


I wonder why nobody mentioned that routing only occurs between different networks, per definition. And the FGT is in Routing/NAT mode.


There have already 2 solutions been proposed:

- use a small switch in front of the FGT,  feeding the FGT WAN port and the device needing the public IP address

- create a transparent VDOM


If you want the traffic to be protected you will have to use the VDOM approach. This isn't really difficult and done in 10 minutes. At least less time than this thread is already going on...just my 2 ct.

Ede Kernel panic: Aiee, killing interrupt handler!

View solution in original post

Ede Kernel panic: Aiee, killing interrupt handler!

I do not really get the issue.. creating overlapping subnets sounds like a pain in the eh... 


Most of the time i am asked for a similar solution, you can either convince the people that a natted address is fine, as they need a device being reachable by the offical IP, but do need to have the offical IP configured at the device.


Therefore instead of you give a and map this IP to the offical/public IP.


If they insist on a public ip configured at device level you simply can't have the (nat) firewall in between -> a internet Switch (or a VLAN on a existing switch) depending on your needs/security policys (e.g. Internet traffic may not reside on the same switch even if vlan sepearted) should do.





View solution in original post


I guess some have longer experiences but i doubt that anyone knows the perfect solution for everything.

Often i encounter setups where someone "has heard something" and not propagates this without any knowledge: 


e.g. a Citrix Admin has problems with his servers and he found a KB Article about spanning tree problems with citrix servers. The server Admins soultion: have STP disable for the citrix network, not realising that this is a "very brave" decision.. 

In the KB Article it was about port-fast as stp may take to long for DHCP request to go into forwarding. 


Result: loops in the ctrix networks as stp was disabled. Enabling STP and everything was fine (Portfast by default, the citirx problem was never related to any stp.. but hey thats the way it rolls pointing to others if any errors occur).


therefore: Ask yourself/your customer whether he really wants such a strange solution. And keep in Mind: while fortinet does not do routing of same IP Networks through another interface Cisco ASA do not do this as well - as this is just a [strike]stupid[/strike] unusual Idea.



Yeah, I agree, not your fault OP.


Just to clarify: there simply is no routing between the same networks. Full stop.This is just the way the IP protocol is designed.


And no, the FGT can route quite well without NAT. Just an example: it does so all the time when traffic crosses between local ports. That's what the automatic static routes ('connected') are for. There is no NAT involved in this.

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

Select Forum Responses to become Knowledge Articles!

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

Top Kudoed Authors