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.
Thanks!
Solved! Go to Solution.
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.
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 192.168.3.0 mask 255.255.255.0' 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: 192.168.1.0/255.255.255.0 Device: Port2
Gateway: (none) - Give Port2 a 192.168.1.x/255.255.255.0 IP address that doesn't match the host and the route will be added automatically
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
end
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 192.168.1.0/24 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 192.168.1.0/24 IP to port2 or setup port2 with a secondary ip in the 192.168.1.0/24 range. Once you associate a 192.168.1.0/24 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.
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.
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 192.168.1.3 you give a 172.16.1.1 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.
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.
Sorry for not clarifying enough.
In the diagram I used 192.168.1.x/24 as the "public" ip. I know the 192.168.x.x are not public, but the routing / nat / setup should be the same. So I'm pretending the 192.168.1.x is my real address here. And sure enough I don't have a /24 public ip range here at home ;)
I wan't the ip to be left unchanged so, option two
I've setup a firewall rule without NAT from WAN1 to Port10(policy number one)
From wan1
To port10
Soure All
Destination all
Schedule always
service all
action accept
nat disable
What I'm struggling with is the route.
Destination IP/Mask: 192.168.1.3/255.255.255.0 (I guess thats wrong)
Device: Wan1
Gateway: 192.168.1.1
Edit: I've changed a little the diagram to try to get it as close the the real world as possible. I could have solved this with adding a vdom in transparent, but wan't to solve this with shouldn't have been easy. Well, it doesn't work, and it bugs me.
Edit2: Superthanks for your answers and taking your time to solve my mess.
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 192.168.3.0 mask 255.255.255.0' 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: 192.168.1.0/255.255.255.0 Device: Port2
Gateway: (none) - Give Port2 a 192.168.1.x/255.255.255.0 IP address that doesn't match the host and the route will be added automatically
So lets see.
I don't have a 192.168.3.x network. The wan side has the 192.168.1.x network. And I'm trying to get the same 1.x network to one (or many) hosts behind the firewall with the only vdom in use in NAT-mode.
When I try to set the ip addess for the port 2 to ex 192.168.1.199/24, I get the error-message "IP address is in same subnet as the others". The interface is of type physical and is not tagged to any vlans. Tried to add the interface to a new vlan as well, but I got the same error.
When I try to add a static route with 192.168.1.0/255.255.255.0 and leave the gateway empty I get the error message "Blank or incorrect address entry".
I guess I have to read (even more). Tried to find a video that covers routing on the fortinet, but didn't find any, just many videos of other topics, that I'm looking forward to watch, once I solve this one.
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
end
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 192.168.1.0/24 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 192.168.1.0/24 IP to port2 or setup port2 with a secondary ip in the 192.168.1.0/24 range. Once you associate a 192.168.1.0/24 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.
Still find Leif's description/diagram of the request to be confusing. lol.
If both WAN1 and port2 (shown in diagram) are suppose to be on the same subnet, I would consider just adding a secondary IP to WAN1 and route through that to the server on port2. Alternately, create either a hard or soft switch combining WAN1 and port2... but I don't like this method because of the CPU load on the Fortiate (if it is a soft switch).
Closest real life situation I have encountered to Leif's request was installing VC units (that needed pubic IP addresses) in sites we have deployed Fortiates at -- in those cases we just install a small network switch between the Fortigate and WAN device -- we then connected the VC unit to another port on the same switch.
NSE4/FMG-VM64/FortiAnalyzer-VM/6.0 (FWF30E/FW92D/FGT200D/FGT101E/FGT81E)/ FAP220B/221C
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.
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 192.168.1.3 you give a 172.16.1.1 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.
Really thanks for all your answers!
So why do I want't this? Well, it's a learning by doing, one has to fail (or learn by others faults) to get the knowledge of why and how. And I do agree that subnet overlapping doesn't sound like a good idea. I just thought that the fortigate could route without NAT and it wouldn't be this messy.
In the end it sounds like I should use the vdom (or vodka as my autocorrection says) and use a tagged vlan to the wan as suggested above (the solution that we uses today).
It feels that all of you got a solid amount of experience witch I seems to lack. Well, I'll get there hopefully one day. Just have to study more...
Oh, and no, I didn't get it to work even when I activated the subnet overlapping. I write that to my fault, and I guess it would have worked if I just could figure out how. Though I'm now scratching this design, and will start all over again :)
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 |
---|---|
1737 | |
1108 | |
752 | |
447 | |
240 |
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.