Using the CLI can be a substantially faster means of editing settings if you know what you are doing. Sometimes, people just prefer the CLI. This is completely understandable as half the time there are features (important ones at that) that aren’t even visible in the GUI. The following video shows how to connect to a FortiSwitch via Serial and change the IP settings as needed.
Category Archives: How To
How To Upgrade FortiSwitch Firmware
I had someone ask me how they should go about updating a FortiSwitch firmware out of the box. I created a video that shows the process of making the FortiSwitch manageable on your local network and upgrading the firmware from 3.3.3 to 3.4.3.
How To Upgrade FortiGate Firmware
This is my first ever custom video so please take it easy on me. I get nervous and tend to ramble but I hit the high points. These videos will become very frequent and obviously the quality of the presentation will improve as I get more comfortable and in the groove. Anyways, here is a video that explains how to upgrade your Fortinet FortiGate to a newer version of firmware.
Something to consider: I didn’t mention this in the video but you need to verify you can upgrade to your destination Firmware from the version of code you currently have loaded. Sometimes, changes are drastic enough that you have to “step” your upgrade process. An example of this would be you have 5.2.3 loaded and you want to go to 5.2.8. You can’t do this until you have at least 5.2.6 loaded so you have to upgrade to 5.2.6 THEN upgrade to 5.2.8. These requirements are listed in the release notes so be sure to read those for your Firmware Version!
Indexing of Old Archived Logs on FortiAnalyzer
Question: The FortiAnalyzer divides logs into indexed and archived. Once an old log is archived, can this be brought back in order to be indexed?
Answer:# exec sql-local rebuild-db
http://kb.fortinet.com/kb/documentLink.do?externalID=FD36458
Awesome tip from Paulo R on the Fortinet Forums. See the thread by clicking here
Policy Based IPSec and NAT
Think of the little things
This is going to be a quick guide on things to check when your Policy based IPSec tunnels decide to not work properly with NAT enabled.
Have this client, they were getting ready to migrate a bunch of IPSec tunnels from one of their client’s firewalls. The firewall that was originally hosting these tunnels is a Dell Sonicwall (threw up a little in my mouth right there).
We get the tunnels loaded and all are working fine except for the ones that require NAT due to overlapping subnets.
Just a reminder boys and girls, when your settings APPEAR to be correct but things still aren’t working…..it’s going to be something simple.
It is always something simple!
When you create a phase 2 for your tunnels through the GUI certain parameters are predefined. This is fine if you are using a simple tunnel with no NAT being applied.
One of these settings is the “use-natip enabled” setting that comes swinging right out the gate. If you have never looked at your phase 2 through the CLI you wouldn’t even know this existed.
Proof is in the pudding:
There is nothing more frustrating than having your policy setup improperly (no NAT applied through policy) and the tunnel come up, but no traffic flows……but if you enable NAT in the policy all of a sudden no tunnel OR traffic.
The two conflict. So if you are doing policy based IPSec tunnels that ALSO happen to be performing NAT on the policy (which you can only enable on the policy through CLI by the way…) you are going to be in for a bad time until you turn off the NAT setting on the phase 2
In Conclusion:
I know this entire post is basically a giant run on sentence but I wanted to get it on paper as it was fresh in my head. I tend to forget things you know. By all means express your findings on these types of situations in the comments. Would love a healthy dialogue regarding these types of things! If I need to expand on anything to make it easier to understand please let me know. I am always available to answer questions.
Zones Will Save Your Sanity
FortiGates are interface driven firewalls. Policy is relatively straight forward. Port 1 to Wan 1 Allow HTTP NAT you get my drift. In more complex environments though where you can easily have 5-10 interfaces (even more if you bring in VLAN’s) you will most certainly want to use Zones.
What is a zone? A zone is a created “Interface” that you assign other interfaces to. For instance, my common deployment has 2 main zones, INSIDE and OUTSIDE. This keeps policy extremely simple.
The train of thought with this ZONE setup is traffic is either coming in or out. From there you just create the policy and work accordingly. This makes deployments for my clients super easy.
The setup at my house is utilized this way as well (I have a FortiGate 92D at home). My setup is slightly more advanced though thanks to having dual internet connections, SSL VPN, and other capabilities kicked on. But as you can see in the policy set below I have an INSIDE zone. That zone has my work network, my personal home network, and my DMZ wireless network (for when I am cleaning peoples deranged and abused machines). I have each one assigned to the INSIDE zone so that I can apply the same policy for traffic that is traveling from inside sources to the internet. This greatly reduces policy count and helps keep things uniform.
Disclaimer: Make sure to click the “Block Intra-Zone Traffic” check box when creating a zone that includes a set of networks that you don’t want to communicate without policy. For instance, my INSIDE zone has my work network which I need to make sure only my work laptop can see, My personal network which sees everything on the personal net, and a DMZ network that I absolutely don’t want ANY of my other networks to receive traffic from or send traffic to. So I check the “block intra-zone traffic” box when I create my zone (can be edited after the zone is created as well) and then manually allow it via policy (work network is able to access printer on personal net etc). Remember, the more granular you are the better your security will be. Also, the only traffiic that should be able to flow is the traffic you explicitly allow.
Dedicated Management CPU
Have a FortiGate that is getting slammed with traffic? Tired of not being able to manage the damn thing because of resource utilization? Boy do I have the fix for YOU! Hah, seriously though. If you suffer from these issues then there is definitely a way to guarantee management access to the device as long as you are running FortiOS 5.2 or newer and it is a 2U / blade firewall with mutliple CPUs.
Below are the commands to configure this
conf system npu
set dedicated-management-cpu <enable | disable>
end
Stop logging of local broadcasts
So as you may have noticed, your logs can often be filled with local broadcasts and traffic of that sort. You can remove these from your logging to help clean things up. This never crossed my mind until I was reading some other blogs that belong to Fortinet TAM’s, consultants etc. This little tid bit is thanks to FireWall GURU. Below you will see commands on how to do this for specific devices:
FortiAnalyzer:
config log fortianalyzer filter
set local-traffic disable
end
Log Disk
config log disk filter filter
set local-traffic disable
end
Memory:
config log memory filter
set local-traffic disable
end
Syslog
config log syslogd filter
set local-traffic disable
end