Unable to set HA mode on FortiGate

I recently had to configure a FortiGate Active – Passive HA cluster.  I did the configuration through the GUI, but no matter what I did it always reverted back to Standalone mode.

I then dropped into jedi (aka the CLI) mode and tried to configure the cluster from there, like so:

-------------------------------------------------------------------------------------------------------------------------------

FORTIGATE # config system ha
FORTIGATE (ha) # set mode

standalone    Standalone mode.

The system may run in HA A-A or HA A-P mode only when all interfaces are NOT using DHCP/PPPoE as an addressing mode.

-------------------------------------------------------------------------------------------------------------------------------

And there is our problem – no interfaces are allowed to be set to DHCP if you want to enable HA.  I corrected this and then proceeded to configure HA.

FORTIGATE (ha) # set mode a-p
FORTIGATE (ha) #

I tested and was also able to set this via the GUI now.  First prize would of course be if FortiNet properly handles the error in the GUI, but nice to know that the proper error message is given the CLI.

Effort vs. Recognition

Today I'm writing only the second ever non-technical piece on my blog.  The first can be found here, and touches mainly on ethics in dealing with customers and putting the customer first, always.  Today's post is a bit more introspective, focusing on why we do what we do, and the rewards, if any.

Me, I am a techie, I want to know and understand how things work and then I want to put that know-how to use so that my customers can obtain the maximum benefit out of their investment.  My boss also comes from a technical background, which is brilliant because he “gets” it, even though he has long since left the technical side of things behind.  In fact one might say he went over to the dark side, since he is much more involved in sales nowadays.

That said, a lot of what I do is impossible for my superiors to grasp nor does it immediately reflect on a financial balance sheet.  A big part of that is also undoubtedly the fact that oftentimes I simply do not know how to elucidate or explain it in terms that anyone than a peer would understand.  I do know however, that what I do will save someone a lot of trouble and effort down the road.  It might not be today or tomorrow, but it *will* prove to valuable.

Every manager will tell you that something that can't be quantified can't be measured, and what can't be measured can not be recognized.  It follows that what cannot be recognized can not be rewarded.  This brings us to an important question - do we do something the right, proper and ethical way because it is right, or because we want to be rewarded?  

I feel that we are defined by our actions, thus we become what we do.  So put in the effort.  Chances are you won't get credit or recognition for it, but that is OK.  Even if no-one sees it, *you* know.  You do it because that is who you are.  And if it's not who you are now, it is who you want to become.

I really believe that integrity and the excellence that goes with it will get rewarded in the long run.  You might find yourself thinking "what did I do to deserve this opportunity", or how a seemingly random encounter turns into an amazing and rewarding professional journey.  But it's not just random luck – this is the reward.

I've been very fortunate in that I have been able to choose my bosses and managers very carefully and I can honestly say that my interaction with each and every one of them has left me a better person, both professionally and personally.  That said, bosses come and go, but you remain.  So do the right thing, not for their recognition (though it is certainly welcome!), but for yourself.

The biggest reward of all is being able to hold your head up high, and be proud of what you have created.  Be proud of who you are and what you do.

Disabling the Symantec DLP Agent notifications

I’ve been branching out from the normal infrastructure stuff I’ve been doing into more security oriented fields.  Part of what I now do includes Data Loss Prevention, and I’m proud to say that I’ve recently completed my first Symantec DLP deployment.  It also happened to be the first deployment in Africa, outside of South Africa.

By default the Symantec DLP endpoint agent displays a notification when it scans for sensitive content, like so:

In this case the customer did not want to let the end-user see what was going on so we had to disable.  Unfortunately this seemingly simple UI option is not so simple – here is what you have to do

Log into the DLP Console.  Go to System -> Agent Configuration

-> Edit config -> Advanced Agent Settings

Set the UI.NO_SCAN.int to any value other than 0 and the scan dialog will not be displayed.

All Fortigate FSSO users are placed in the FSSO_guest_users group

Getting AD authentication going on a Fortigate is a slightly finicky, but well documented process and once you get it working it works well.  If it’s something you battle with, leave a comment and I’ll do a HowTo.

That said I recently had an issue with a Fortigate unit that absolutely insisted on putting all FSSO users in the FSSO_guest_users group, which means none of my Policies using authentication was working.  This is what the Fortigate saw my logged on users as:

The fix in the end was fairly simple, turns out that on the Fortigate I had the groups configured in Advanced mode, like so: CN=Internet Access,OU=Security Groups,OU=Head Office,DC=corp,DC=root. 

The Collector Agent, however, was configured to use Standard mode.  The fix was to switch the FSSO Collector Agent Directory Access Mode to Advanced Mode.

Once the change was made I refreshed the FSSO groups on the Fortigate via the “execute fsso refresh” command and all was well again.

For those of you keeping notes, the Fortigate was running FortiOS v5 Patch 6 and the FSSO agent was v4.0 MR3 B0151

“Unable to launch RDP native” using Fortigate SSL VPN Portal

Recently we started receiving calls from our Fortigate customers that they cannot launch RDP sessions from within their web portal.  After a bit of troubleshooting I discovered that this was caused by a recent Java update (Java 7 Update 51).  More information can be found here, here and here.

The exact error looks like this:

Workaround

The workaround in this case is very simple, just add your Fortigate Portal address to the Exception Site List in your Java configuration, like so:

More information about the exception list can be found here.

Configuring a 4G USB modem on a Fortigate Firewall

Fortigate is a deserved market leader in the UTM space, but as with all products there is always room for improvement.  Point in case is getting a 3G / LTE connection via a USB dongle up and running.  There is minimal support in the GUI, and they’ve removed a lot of options in FortiOS 5.

Fortunately for an old Cisco hack like myself we’ll always have the CLI to fall back to so below are the steps to get it up and running.  Note that the below is for a device that is on the Fortigate HCL.  If yours is not then you’ll have to configure that first.

config system modem
    set status enable (Enables the modem functionality)
    set pin-init "at+cpin=1111" (If you have PIN security, I tend to disable the SIM PIN check)
    set dial-on-demand enable (self-explanatory)
    set phone1 "*99#" (replace *99# with whatever your dial-up number is)
    set extra-init1 "at+cgdcont=1,\"ip\",\"internet\"" (replace internet with your APN)
    set altmode disable (enable if you're in China, rest of the world disable)
end

VLAN Up, Line Protocol Down

Creating a VLAN and a SVI

Today, not for the first time, I was asked to troubleshoot a issue with an SVI (Switch Virtual Interface) not coming up.  The customer had created a SVI like so:

switch# conf t
switch (config)# int vlan 10
switch (config-if)# ip address 192.168.10.1
switch (config-if)# no shut

The problem was that the SVI stayed down, and the VLAN did not even show up when you do a “sh vlan”.  Why did this happen?  Because the customer created the SVI without first creating the Layer 2 VLAN for it to live in.  Here is what the customer should have done:

switch# conf t
switch (config)# vlan 10 ***this creates the layer 2 VLAN***
switch (config-vlan)# name VLAN_NAME
switch (config-vlan)# exit
switch (config)# int vlan 10 ***this creates the layer 3 SVI for the VLAN***
switch (config-if)# ip address 192.168.10.1 ***assigns the IP and netmask to the SVI***
switch (config-if)# no shut

Now if we do a “show vlan” it should show as active.  Whilst we’re on this topic, let’s have a look at what exactly is required for a SVI to come up and be ping-able on your network.

Requirements to get a SVI to the Up/Up state

An SVI must meet all of the below requirements to transition to the “Up/Up” state

• Its VLAN must exist and show as active in the VLAN database “sh vlan”
• One switched port in the VLAN (can be access or trunk) must be up
• The port must be in a STP forwarding state