We are implementing a Fortinet infrastructure into one of our main buildings. We are essentially building a new network for these users and we are looking for this system to mesh well with our existing devices. I am currently setting up a Fortigate 600D running v5.4.4.
I am trying to set up the WAN port on the Fortigate but every IP I assign to the port is erroring out, claiming that it belongs to our main firewall. The goal is to have a PAT so one external IP address (that belongs to our organization) should do it. At first we were trying to chase down ARP tables from different devices to figure out why that specific IP might be claimed, but as I started to toy around I noticed that even private IPs, externals that didn't belong to us, and IPs I was making up on the spot were claiming to be taken by our main firewall. Is this a bug with the Fortigate Software?
As a work around, I was able to set the WAN IP to 0.0.0.0/0.0.0.0, disable the port, set the IP correctly to one of our globals, then enable the port but it's triggering all sorts of ARP flaps on multiple devices now, so I'd like to avoid that route. Any suggestions?
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 know what Bob is suggesting. My feeling is that it won't help, and no, this is not common practice.
There are 3 ways to associate an address with an interface:
- define it as primary address (GUI/CLI)
- define it as secondary (tertiary,...) address (secondary in GUI, others in CLI)
- define a VIP (virtual IP) associated with this interface
All of which would work even as a single measure (ie., a VIP would even work if there is no interface address at all).
But the common way is to define a primary IP on the WAN interface. Throwing an error message could be a bug but could as well be rightful.
One thing to keep in mind is that the FGT is a router. No 2 interfaces may use addresses from the same collision domain. You can check address overlap for instance by looking at the routing table (Routing > Monitor).
Lately, I've had serious trouble with the GUI blocking an address setting because "address overlap with management port setting". Management ports have the special quality that they explicitely allow an address from a otherwise configured subnet, for instance the LAN port.
It turned out the the new "role" parameter in the GUI/CLI caused this. Setting the address in CLI always worked, and setting the role to "undefined" let me set the address in the GUI as well. You might check this.
If you still have problems then please provide more info on the address spaces used: which addresses are assigned to the ports, which netmasks are used (check them!). I guess you use a transfer net between the HQ FGT (WAN port) and the branch FGT.
I think the key point from ede_pfau was that in general no two interfaces on the FortiGate can use addresses that are in the same subnet. If they did, since the FortiGate is a router and (mostly) not a switch, you would have some messy routing problems.
*However*, there are some ways to have multiple IPs on the same interface (such as defining secondary IPs on a single interface) or to have multiple physical interfaces (with the same IP) that are all on the same subnet or part of the same vlan (defining them as members of a hardware or software switch, or as an aggregate depending on what you're doing). If you want to get complicated you can even define multiple VDOMs on the FortiGate and since each VDOM functions like a separate router each could have their own interface with its own IP for each of your subnets.
I think the confusion is that we're not really clear on what you're doing. If you could provide a simple network diagram of what you want to do, and maybe what the motivation is, we could probably give better answers.
The FortiGate can do switching, but it is more of a router and firewall. If you create a switch interface on the FortiGate that contains multiple physical interfaces that switch interface will still normally have only a single IP.
I'm afraid I'm still not clear if you are trying to have separate subnets, or a single subnet? Are the switches with the .10, .11 and .12 IPs all on the same subnet? Or are you wanting to have separate subnets and separate vlans for layer 2 separation?
If all you want is to have everything connected to all the switches under the FortiGate be on the same subnet you can do that relatively simply with FortiGate switch interfaces or aggregates. Let me know and I can elaborate.
Assuming this is a more complex setup, some thoughts:
Note that the FortiLink (Dedicated Switch) interface itself isn't anything but a FortiLink interface. You mentioned wanting to make 1 SFP port the dedicated switch port port AND your lan port. You can't do it quite that way. But you can easily create a vlan interface (or multiple vlans) on top of the FortiLink interface to be your lan. More below.
Your clients needing to get an IP address through DHCP might request it from the APs or the switches, but unless you've got your own separate DHCP server(s) you probably want DHCP IPs handed out centrally from the FortiGate. The FortiGate makes creating a DHCP server on a vlan interface easy.
You'll have to decide if you want the various SSIDs on your FortiAPs to tunnel back to the FortiGate or to just be bridged onto an existing vlan (you can do both on the same FAP). Its generally easier/faster to have them bridged, but not quite as secure. Bridged also means you can easily have WiFi users and wired users on the same lan without doing much extra work. I use bridged for non-publicly reachable AP locations, and tunnel for our guest SSID and for another SSID that connects to vulnerable hardware.
If you don't manage the FortiSwitches with the FortiGate (so no FortiLink connection) then you can connect multiple switches to multiple ports on the FortiGate using vlan tagged interfaces. I have a 300D in this configuration. For example, one physical interface on the 300D has 4 vlan interfaces created on it, and it is connected to a single port on our main switch which allows only those 4 vlans and only tagged packets. Similarly, I have other physical ports with their own vlans connected to that same switch, and to other switches. I could have create a hardware switch group on the FortiGate with its own vlan or vlans, which was connected to multiple switches that matched those vlans if desired. Or an aggregated interface for more bandwidth, etc.
If you do manage the FortiSwitches from the FortiGate with a FortiLink connection, you can connect multiple switches, but how you connect them has some specific rules. See http://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-managing-fortiswitch-330-54/Stacking.... for details.
I'm part way through setting up a 5.4.6 100D with a few FortiSwitches. My understanding is that with 5.4.x you can only have a *single* FortiLink interface on a FortiGate dedicated to the FortiSwitches. (5.6.x is a different story.) You could do VDOMs on a single FortiGate to work around this if needed.
Only having a single FortiLink isn't quite as bad as it sounds, since that FortiLink interface can be a hardware/software switch interface (so comprising multiple physical interfaces), with multiple vlans created on it, connected directly to multiple FortiSwitches. Or it can be an aggregate interface, with multiple physical interfaces, either all connected to one FortiSwitch in a stack of FortiSwitches connected by InterSwitchLink, or with some of the connections also going to the bottom of the stack as a standby connection. Again, all of your vlans will get created on that single FortiLink interface.
With 5.6.x, according to the docs, you can have multiple FortiLink interfaces, but this has to be enabled from the CLI:
config switch-controller global
set allow-multiple-interfaces enable
end
Unfortunately, it looks like the 5.6 GUI only supports working with vlans for the first FortiLink, so if you have mutliple FortiLinks you need to work with them through with CLI. I really hope they add GUI support for multiple FortiLinks. 5.6 also gives you the option to MCLAG the switches together for switch HA. I don't consider 5.6.2 stable enough to switch to yet, though.
5.4 Managed FortiSwitch Vlans:
5.6 Managed FortiSwitch Vlans:
Hope this helps instead of making things murkier!
Welcome to the forums.
What is your goal here? If you simply want outside traffic to see you as an IP address, create an IP pool with that single address and use it inside of the outgoing policies.
Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com
Thank you!
My goal here is to set this up a completely segmented network dedicated to monitoring traffic/altering bandwidth/blocking protocols for one of our main buildings we service. It will feature a separate DHCP pool than the rest of our campus utilizes.
This is my first run in with FortiNet and I'm still in the beginning phases of setting up this device. Let me make sure I am understanding what you are saying... You are telling me not to define an IP of the WAN port? Instead to simply add the external IP I would like to use as a "pool" and alter my route to send all traffic out that pool? Is this standard practice for the FortiGate? Seems like a round-about way to do things.
Sorry, I do not have time to elaborate. (this thing called work is getting in the way) Please look for the Fortigate Cookbook. It explains in pretty good detail (from what I have heard) about how to configure a Fortigate Firewall. If time permits later, I will get back to this.
Bob
Bob - self proclaimed posting junkie!
See my Fortigate related scripts at: http://fortigate.camerabob.com
I know what Bob is suggesting. My feeling is that it won't help, and no, this is not common practice.
There are 3 ways to associate an address with an interface:
- define it as primary address (GUI/CLI)
- define it as secondary (tertiary,...) address (secondary in GUI, others in CLI)
- define a VIP (virtual IP) associated with this interface
All of which would work even as a single measure (ie., a VIP would even work if there is no interface address at all).
But the common way is to define a primary IP on the WAN interface. Throwing an error message could be a bug but could as well be rightful.
One thing to keep in mind is that the FGT is a router. No 2 interfaces may use addresses from the same collision domain. You can check address overlap for instance by looking at the routing table (Routing > Monitor).
Lately, I've had serious trouble with the GUI blocking an address setting because "address overlap with management port setting". Management ports have the special quality that they explicitely allow an address from a otherwise configured subnet, for instance the LAN port.
It turned out the the new "role" parameter in the GUI/CLI caused this. Setting the address in CLI always worked, and setting the role to "undefined" let me set the address in the GUI as well. You might check this.
If you still have problems then please provide more info on the address spaces used: which addresses are assigned to the ports, which netmasks are used (check them!). I guess you use a transfer net between the HQ FGT (WAN port) and the branch FGT.
Thanks for the response. I have only tried setting the WAP IP using the GUI, so I can't speak to results via the CLI. I was able to set the IP using the method I discussed in the original posting, but I am now unable to change any information on it without resetting it back to 0.0.0.0, then making the change.
One of my MGMT ports is set to the default IP (which does not overlap with my created range) and the second is set to an address that allows the FortiGate to be managed via our internal network, so again, no overlap there.
Thanks for the suggestion of setting the interface to undefined. I'll give that a shot and let you know how it turns out. I'll go back to the drawing board and take a look at my designed IP ranges to ensure there's no overlap or faults.
Thanks again!
EDIT: I found that what was throwing me off was indeed an overlap in the network ranges.
I think the key point from ede_pfau was that in general no two interfaces on the FortiGate can use addresses that are in the same subnet. If they did, since the FortiGate is a router and (mostly) not a switch, you would have some messy routing problems.
*However*, there are some ways to have multiple IPs on the same interface (such as defining secondary IPs on a single interface) or to have multiple physical interfaces (with the same IP) that are all on the same subnet or part of the same vlan (defining them as members of a hardware or software switch, or as an aggregate depending on what you're doing). If you want to get complicated you can even define multiple VDOMs on the FortiGate and since each VDOM functions like a separate router each could have their own interface with its own IP for each of your subnets.
I think the confusion is that we're not really clear on what you're doing. If you could provide a simple network diagram of what you want to do, and maybe what the motivation is, we could probably give better answers.
Thanks for chiming in, everyone. Your information is very helpful.
After the original posting, I went back to check my configurations on the FortiGate and I did find that I was trying to assign multiple ports with the same IP range. My understanding was that I could not only use the FortiGate as a Firwall/Router, but also as a distribution switch (the 9 SFP ports on the FortiGate are to blame, I guess).
Could you speak more to the Hardware/Software switch and Aggregate configurations? Since I am not allowed to configure multiple ports with the same range, I'd like to configure 1 switch port from the FortiGate and this switch in-turn link the other switches.
Anyhow, this is our setup: We have 1 Fortigate 600D, 5 FortiSwitch 224D's and 50 or so FortiAPs. My intent is to do the following:
[ul]
The FortiGate can do switching, but it is more of a router and firewall. If you create a switch interface on the FortiGate that contains multiple physical interfaces that switch interface will still normally have only a single IP.
I'm afraid I'm still not clear if you are trying to have separate subnets, or a single subnet? Are the switches with the .10, .11 and .12 IPs all on the same subnet? Or are you wanting to have separate subnets and separate vlans for layer 2 separation?
If all you want is to have everything connected to all the switches under the FortiGate be on the same subnet you can do that relatively simply with FortiGate switch interfaces or aggregates. Let me know and I can elaborate.
Assuming this is a more complex setup, some thoughts:
Note that the FortiLink (Dedicated Switch) interface itself isn't anything but a FortiLink interface. You mentioned wanting to make 1 SFP port the dedicated switch port port AND your lan port. You can't do it quite that way. But you can easily create a vlan interface (or multiple vlans) on top of the FortiLink interface to be your lan. More below.
Your clients needing to get an IP address through DHCP might request it from the APs or the switches, but unless you've got your own separate DHCP server(s) you probably want DHCP IPs handed out centrally from the FortiGate. The FortiGate makes creating a DHCP server on a vlan interface easy.
You'll have to decide if you want the various SSIDs on your FortiAPs to tunnel back to the FortiGate or to just be bridged onto an existing vlan (you can do both on the same FAP). Its generally easier/faster to have them bridged, but not quite as secure. Bridged also means you can easily have WiFi users and wired users on the same lan without doing much extra work. I use bridged for non-publicly reachable AP locations, and tunnel for our guest SSID and for another SSID that connects to vulnerable hardware.
If you don't manage the FortiSwitches with the FortiGate (so no FortiLink connection) then you can connect multiple switches to multiple ports on the FortiGate using vlan tagged interfaces. I have a 300D in this configuration. For example, one physical interface on the 300D has 4 vlan interfaces created on it, and it is connected to a single port on our main switch which allows only those 4 vlans and only tagged packets. Similarly, I have other physical ports with their own vlans connected to that same switch, and to other switches. I could have create a hardware switch group on the FortiGate with its own vlan or vlans, which was connected to multiple switches that matched those vlans if desired. Or an aggregated interface for more bandwidth, etc.
If you do manage the FortiSwitches from the FortiGate with a FortiLink connection, you can connect multiple switches, but how you connect them has some specific rules. See http://help.fortinet.com/fos50hlp/54/Content/FortiOS/fortigate-managing-fortiswitch-330-54/Stacking.... for details.
I'm part way through setting up a 5.4.6 100D with a few FortiSwitches. My understanding is that with 5.4.x you can only have a *single* FortiLink interface on a FortiGate dedicated to the FortiSwitches. (5.6.x is a different story.) You could do VDOMs on a single FortiGate to work around this if needed.
Only having a single FortiLink isn't quite as bad as it sounds, since that FortiLink interface can be a hardware/software switch interface (so comprising multiple physical interfaces), with multiple vlans created on it, connected directly to multiple FortiSwitches. Or it can be an aggregate interface, with multiple physical interfaces, either all connected to one FortiSwitch in a stack of FortiSwitches connected by InterSwitchLink, or with some of the connections also going to the bottom of the stack as a standby connection. Again, all of your vlans will get created on that single FortiLink interface.
With 5.6.x, according to the docs, you can have multiple FortiLink interfaces, but this has to be enabled from the CLI:
config switch-controller global
set allow-multiple-interfaces enable
end
Unfortunately, it looks like the 5.6 GUI only supports working with vlans for the first FortiLink, so if you have mutliple FortiLinks you need to work with them through with CLI. I really hope they add GUI support for multiple FortiLinks. 5.6 also gives you the option to MCLAG the switches together for switch HA. I don't consider 5.6.2 stable enough to switch to yet, though.
5.4 Managed FortiSwitch Vlans:
5.6 Managed FortiSwitch Vlans:
Hope this helps instead of making things murkier!
My apologies for not clarifying. The switches would all be on the same subnet. The FortiLink connected to Switch1 will define the Subnet. .10 would be the SW1. SW2 would be .11 and would be connected to SW1. SW3 would be .12 and would be connected to SW2. So on and so forth. We would also create a VLAN for Access Points and a VLAN for Wireless Access. This can be defined inside of the SSID I will create. This is the second time I’m hearing about switch interfaces and aggregates. Could you elaborate further?
We would definitely like to manage the FortiSwitches from the FortiGate (one central location). As of now we’ve got a FortiLink connection from the FortiGate to SW1. Thanks for clarifying in regards to the FortiLink/LAN port. Having two being run to the same device seemed a bit redundant.
In regards to the SSID’s, I would definitely like to tunnel them back to the FortiGate. There will be no wired clients utilizing the FortiNet Infrastructure. The only devices running on this setup will be the FortiGate, the FortiSwitches and the FortiAPs. Traffic would tunnel back to the FortiGate via the LAN and with the correct policies applied, traffic should exit the FortiGate via the WAN port. I am however planning to utilize traffic shaping/bandwidth control using this SSID. Not sure if that is relevant to the conversation…
Thanks a ton for your help. Your information is very valuable.
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 |
---|---|
1688 | |
1087 | |
752 | |
446 | |
226 |
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.