The Fortianalyzer is a great product. It can give very deep analysis of exactly what is going through the network and allow you to create/schedule reports to show this data. You also have very quick detailed monitoring at hand with the Fortiview. By default the Fortigates connect to the FAZ  via SSL, all logs are encrypted. Recently, and I am not sure what the issue is, I have been having issues with certain FGTs connecting to the FAZ via SSL (I think its a cert issue..but still checking). So, we have a different option, to use IPSEC to create a tunnel and allow everything to be encrypted that way. This works great.

What we need to do

FAZ: add the device manually in the FAZ, enable “Security”, change the Local ID, Set the PSK.

FGT: Go in through CLI, disable SSL encryption, enable IPSEC, set the PSK.

So lets go to step one – adding the the device in the FAZ.

Log into the device, and select whatever Adom you want to add the FGT into. Then select to add a device, once this pops up fill in the needed info, you will need an admin account.

Select “Next” and fill in the needed info, you will need the S/N for this.

Once that is added you will be able to edit the device. Right click on the device name and select Edit.

From here you will need to enable IPSEC by checking “Secure Connection” and change the PSK. Notice Local ID this is what will identify the FGT. By default its the S/N but you can change it to anything. In this case I am using FGT1.

Now you should see something like this, notice that “Secure connection” is red.

Great, now its time for the device settings. I am going to do this through the CLI, its the only way to set the PSK as far as I know.

The commands are listed below. One thing to note is that once you select “Encrypt” you disable SSL and enable IPSEC.

After all the commands are entered, you should be able to go to Log-Log Config-and test the connection to the FAZ. It should pop up that everything is working as listed below:

Lets check on the FAZ, to make sure everything looks correct.

Ok, this all looks great. That’s it, now we are using IPSEC to encrypt the logs. Its a good alternative to SSL if you find your self in the situation that the FGTs will not connect do to cert issues.

Hello, I noticed one thing I have never created a blog entry on creating a Virtual IP to allow access from the internet into a local server. This entry is for  a VIP and Policy creation on firmware 5.2> . Remember all the best documentation is located at docs.fortinet.com

So what is a VIP, a Virtual IP is one way to allow external traffic going to a Public address to be forwarded in to a Local server with a Private address. Basically, its a NAT object consisting of external IP and port and  Internal IP and port. Before this firewall will allow traffic to access the NAT object (VIP) it needs to have a Firewall policy allowing the destined traffic to the VIP.

So, lets create a VIP. First lets navigate to Policy & Objects, Objects, and Virtual IPs. Lets create a new object.

Now, lets input the information needed to have external connections reach our internal network. In this example my outside web server listening address is 2.2.2.1 (my fake public IP) , my internal web server at 172.16.1.10 and my answering interface (the interface accepting connections) is WAN1 (QXnet). So, start out naming the VIP something that will have meaning to you. Then select the incoming interface, and apply the correct IP information. You will then have the option to do a port forward (1 port or a range forwarded into the server), or a 1-1 nat, where all ports are forwarded. If you do a Port Forward, select the protocol, and then set the ports.

In this example I am allowing port 80 on my public IP to be forwarded to port 80 on my private server.

Great, we have created the VIP object. But, as of now no traffic will be allowed to go to the private server. We have to add a Firewall policy to allow that traffic to the VIP.

Lets navigate to Policy & Objects, Policy, IPV4 then create a new policy.

Below shows the settings. The settings read like this : Incoming Interface – This would be where traffic is coming from, in this case the WAN1 interface. Source address: this would be the actual address its coming from, in this case it could be anyone on the internet, so I will select all. Source users, and devices can be left blank. Outgoing interface: this is were the traffic is going, in this case its going to my server located on my LAN interface. Destination address, this is the tricky part. The destination address will be the VIP you created. In 5.2 notice the ICON. Its different then normal address objects, thus specifying, if your name didn’t, that this is a VIP.  You then have to specify the server you want to allow in, I am creating the VIP to allow HTTP into the network, so I will only specify HTTP traffic to be allowed in.

For traffic coming into the firewall we do not need to NAT this traffic, please turn this off. In 5.2> it is on by default when you create a policy.

If you require any UTM features to be on, this is the time.

That’s It! Fortinet makes it very easy to create these VIPs.

If you are not sure if your VIP is working, there are many ways to check/troubleshoot. One way would be to test it, does your server answer? You can also do an online port scan using any many tools online. you can also check the hit counts on the policy (See below). The hit counter should be there by default, but if not add it in by right clicking on the tool bar and selecting Count as one of your columns. I have used the hit counter many times to troubleshoot my VIPs not working. For example, if I try to access my server VIA the public IP, and I get hit on my policy – I know that everything is correct on my VIP. I will then make sure my ports/server settings are correct. You could also do more advanced troubleshooting like debugging the traffic, or do a packet capture on the firewall.

Ruckus brought in the Guest Self Service portal in firmware 9.10.0.0 build 218 – so if you are looking to configure it please install this update first (Check release notes for proper upgrade path). After we are on build 218, lets get configuring.

So the Ruckus Guest self service portal is Ruckus’s first step in creating an “on boarding”  process. It allows administrators to make sure that there is at least some kind of authentication on their guest WLANs. The portal gives guest users the ability to create their own guest pass, and the admin can set many options of the guest pass such as expiration, amount of devices that can be registered with this pass, and how the pass is given to the user – for example you can send it through text, email, just show it to them on the screen, or a combination of all. So this feature is great, and helps admins authenticate guest users with very minimal intervention.

So how do we configure this?

First we need to create a new Guest access policy. This is located under Configure – Guest Access. Create a new portal.

Lets now configure our portal page. A few options that are very important are:

Enable Zero IT Registration from the Guest Portal – Use this if you are also planning to register devices. I was confused by this at first. As you will see you have the option to use guest pass, or register a device. When you register a device you are just using Zero IT as normal to get on the secured network.

Authentication – Use guest pass for this. Since thats the goal.

Next you have a lot of options such as Terms of service and time out.

The main box you have to check is the “Guestpass Self-Service” box , you will then get a lot of options to do with that process and how to get the guest pass to the user. A few things to note, if you want to txt them, or send the pass through email you will need to configure a mail server and/or SMS server in the settings of the ZD.

If you notice there is a small “Restricted Subnet access” – Its kind of hidden in my opinion. This is very important. If this is used for guest access more than likely you will want to make sure that guests cannot access internal hosts. This is where that is done. This or the Layer 3 access list. Remember Ruckus does the filtering on the AP, so having to have a ACL on the router is not needed. Below if the full Guest access config.

That is about it for the Guest portal. Now we need to create a WLAN and use it for our guest access.

So, lets create a WLAN at configure – WLAN- create a new one.

Things to note – Select “Guest Access” Then select your Guest access Service portal you created.

Great!! All done, so what happens when you connect?

First you will be presented with the on boarding portal that asks if you would like to use Guest Access, or Register a device (Zero-IT).

Select “Guest Access”

On the next screen it will ask you for your Guest pass, but you don’t have one yet. Select the button to create a new pass. Note that you have the option to Query the status. This is a feature if you want to approve guests of getting a Guest pass before they do.

On the next screen you will be asked to fill out your information.

And here you go! you have your guest pass, which is valid for the length of time that you configured in the policy. Copy and keep this key. The ZD will automatically copy the key into the next page for you. Select to go to Guest Access portal.

You can see the the ZD copied the key for you. Just Press submit.

And there we go!! We are online. Ruckus does it again with making getting on Wifi easier. Now we have a built in On boarding portal.

You can view the Guest Pass and its config under Monitor-Guest pass to find out who the GP was assigned to, when it expires, and you can delete them from here as well.

Ruckus has done a great job giving us a simple but effective way to on board users for Guest and/or internal use.

When Brocade purchased Vyatta I was nervous, but they have done a really good job with it. They keep it updated, and now have added a lot of functionality and increased services with the 6400 version. Both the 5600 (pretty much old vyatta) and the newer 6400 vyatta IOS for free from Brocade. They are good for 60 days.

This blog entry is just showing some very simple things such as adding a IP address to an interface and enabling the HTTPS and SSH service. In another entry i will show how to use other user authentication methods for user logins. Although all of these commands are very easy, this post could help someone who might be in a bind.

Configure an IP address.

The Vrouter CLI has always been intuitive for me. Each config option is really an objects configuration. You can delete the config altogether or just an individual config setting of the object. To set the IP address first you have to go into configure mode.

configure

set int ethernet eth0 address 192.168.252.1/24

commit — remember nothing is set, until this is entered.

The image below shows these commands in the actual CLI.

We can also save the config in config mode by issuing the command “save”.

That’s, it we have now set an IP address.So on to enabling SSH and HTTPS access.

HTTPS

To enable HTTPS we need to issue the command (from config mode)

set service https

commit

As you can see from the image below, after those commands are entered the Vyatta generates a certificate, and restarts its web server.

SSH

Enabling SSH is as easy as the other commands.

From config mode

set service ssh enable

commit

You also have options to allow root login, set the listen address, and change the port.

I was working with some wireless bridge the other day that I had never used. I needed to get VLAN tags to pass through this wireless bridge, but for some reason they were not. I thought.. this is a bridge it should pretty much be plug and play. I was wrong. These bridges seem to do a great job, and are easy to setup, but I had problems finding out how to do this. I thought I would write up a simple post on how to allow VLAN tags to pass through this bridge.

My first issue was the bridges were on a very old firmware. I was on version 5.3, after finding some documentation I thought it was best that I upgrade. I upgraded all the way to the newest version which is 5.6.

Next I noticed that the WDS was not checked. To give some background on why this is so important:

WDS, which stands for Wireless Distribution System, is a feature that enables single-radio APs to be wirelessly inconnected instead of using a wired Ethernet connection.WDS connections are MAC address-based and employ a special data frame type that uses all four of the (MAC) address fields allowed in the 802.11 standard, instead of the three addresses used in normal AP <-> STA (client) traffic. (In the 802.11 frame header, address 1 is the destination address, address 2 is the source address, address 3 is the BSSID of the network and address 4 is used for WDS, to indicate the transmitter address.)

So that’s the reason that Vlan tags would not pass – WDS was not checked, so basically this was a acting as a switch instead of a transparent bridge.

Here are my settings that in the end fixed my vlan tagging issues. First had to upgrade the firmware, the next enable WDS on both aps, one being a Station (Client) the other being a AP. Last, of course make sure that switches both bridges plug into are trunk ports, and have the vlans created.

Recently I was seeing this error pop up on many Windows desktop clients:

The system detected an address conflict for IP address 0.0.0.0 with the system having network hardware address Ed-Ef-A9-B8-CC-2E. Network operations on this system may be disrupted as a result. Mac will vary.

After some research I found http://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/8021x/116529-problemsolution-product-00.html

To give some highlights : “Cisco IOS^® uses the Address Resolution Protocol (ARP) Probe sourced from an address of 0.0.0.0 in order to maintain the IP device-tracking cache when IP device tracking and a feature that uses it is enabled (such as 802.1x) on a Cisco IOS switch. ”

“If the switch sends out an ARP Probe for the client while the Microsoft Windows PC is in its duplicate-address detection phase, Microsoft Windows detects the probe as a duplicate IP address and presents the user with a message that a duplicate IP address was found on the network for 0.0.0.0”

So we now know the issue is with IP Device tracking, but what the heck does this do? IP Device tracking keeps an active list of devices that are connected VIA ARP. The function has as Cisco put it “Always been around”, is extremely beneficial when using MAC ACLs or using 802.1x. Recently it has really been used with Network Mobility Services Protocol (NMSP), this feature manages communication between the mobility service engine and the wireless controller in newer switches.

So how it works – When a  link is detected, it sends unicast Address Resolution Protocol (ARP) probe with a default interval of 30 seconds; these probes are sent to the MAC address of the host connected on the other side of the link, and use Layer 2 (L2) as the default source the MAC address of the physical interface out of which the ARP goes and a sender IP address of 0.0.0.0, — Bingo there’s are default IP that pops up.

So how do we remove device tracking? Easy huh.. just “no ip device-tracking” – this currently gives an error in certain firmwares. Firmware 03.02.02.SE and below give, the error is:

% IP device tracking is disabled at the interface level by removing the relevant configs

So, you could upgrade to 3.3 and then use the no ip device-tracking command, or if you cannot upgrade still disable all the features of IP device tracking. To do this:

Under each interface use commands:

nmsp attach suppress

no ip device-tracking max

I would recommend using a range command to get all the ports at once. This has fixed the issue for me.

I thought I would blog on this. It could be useful for someone who might have an IOS router instead of an ASA and need to create a IPSEC Site-to-Site VPN to a remote peer, then NAT VPN traffic to a different address or subnet if needed, or the local subnets conflict with each other.

Here is a nice little Visio to kind of show what I am going for with the traffic:

Because of duplicate subnets on both sides, I need to nat traffic going to 172.90.0.20 from 192.168.10.10, otherwise traffic should flow normally. How can I achieve conditional nat? By using a route-map and then natting only the traffic in the Route-map. So, lets get our VPN setup first. Remember, we add the NAT network or host IP to our interesting traffic ACL that will be used to define our Phase2

These are my commands:

ip access-list extended VPN-to-Remote
 permit ip host 10.255.232.10 host 172.20.0.192

crypto isakmp policy 50
 encr 3des
 authentication pre-share
 group 2
 lifetime 28800

crypto isakmp key … address 1.1.1.1 no-xauth

crypto ipsec transform-set Transform esp-3des esp-sha-hmac

crypto map Crypto 6 ipsec-isakmp
 set peer 1.1.1.1
 set transform-set Transform
 match address VPN-to-Remote

That pretty much gets the VPN up and going. Now for the interesting part – we need to create a new ACL, match my private 192.168.10.10 address and the destination address of the remote server, then match that ACL in my Route-map.

ip access-list extended Nat-for-VPN
 permit ip host 192.168.10.10 host 172.20.0.192

route-map VPN-to-REMOTE permit 10
 match ip address Nat-for-VPN
!

Great! So, we now have the route-map created.. so now what? We need to create a NAT statement that references my Route-Map. Then of course with any VPN we need to modify the “NO-NAT” ACL to include the traffic for both the 192.168.10.10, and the 10.255.232.10 to my remote destination.

ip nat inside source static 192.168.10.10 10.255.232.10 route-map VPN-to-HCN extendable

ip access-list extended NO-NAT
 deny   ip host 10.255.232.10 host 172.20.0.192
 deny   ip host 192.168.10.10 host 172.20.0.192

Now, if we try to access the remote side, does it work? Yes it does, but lets check to see if our nat is really working. It is! As you can see, 192.168.10.10 going to 172.20.0.192 is being natted into 10.255.232.10, but all other traffic gets natted out of the WAN interface.

Lets just check for translations of 10.255.232.10

Bingo, everything works great. Lets make sure that we are getting hits on our Route-Map.

This is an amazing method for getting users in their correct groups in Fortigates. This way we can apply different security profiles to individual groups, all through one 802.1x login. This example is using Ruckus wireless , but will work exactly the same for any wifi vendor..

This method works by using 802.1x WPA2/AES logins on the Ruckus , and passing the users info over to the Fortigate by Radius accounting. Then on the Fortigate we are using RSSO (Radius single sign on) groups to collect the username/group that is sent to the Ruckus by the Windows NPS server. Lots of moving parts here, but it is really simple. I have had problems finding good documentation about Fortigate’s RSSO profiles – but they work great.

The goal of this project/entry is to have the Fortigate know the Username, IP and group (if assigned) of the user who just authenticated to the wireless network. Once you know these things you can apply different UTM policies to users VIA RSSO groups in the Fortigate. There are many good scenarios and uses for this – one example that I have is for a school network. I set this up recently for a school that has students and faculty authenticate through the same Ruckus controller, but to different 802.1x WLANs (SSIDs: Student and Faculty). The fortigate can then apply correct policies to each user (student or faculty) and therefore lock down student web surfing much more than a faculty member. You might be saying – you could just use captive portal on the fortigate,with LDAP groups. I would say yes, but that is another step users have to take, and its called “Single Sign on” for a reason.

So what is needed to make all this happen: Ruckus wireless using 802.1x, NPS (or any radius server) , Fortigate  – that’s it.

I am going to assume that we already have Ruckus using 802.1x and NPS with no problems.

I had trouble at first setting this up, because I thought that that the NPS server should send the radius accounting info to the Fortigate, I was wrong. The controller is the Authenticator – therefore the device that knows about the authentication, and needs to pass on the info to the Fortigate. The Authenticator (Controller) needs to send the radius accounting info to the Fortigate.

That means you have a AAA server setup on the controller for 802.1x authentication, and a AAA radius accounting server pointing to the Fortigate.

Setup Radius accounting between Ruckus and Fortigate

First we need to create the connection between Ruckus and Fortigate via radius accounting.

On the Ruckus system, go to Configure – AAA servers – create a new server. Then click the box that says “Radius accounting” Fill in the IP of your Fortigate, and create a PSK between the two.

Next on our Fortigate we need to create a RSSO profile for the Ruckus system.

Feel free to name this Ruckus or whatever. The PSK has to match what you created on the Ruckus system. By default the RSSO profile uses the Class variable to match the users. You can change what to match, for example you could match by NAS-Port, User-Name, Class, etc.

So, if we go into CLI we can modify many of these settings. Below are the settings I have used

config user radius
edit “Zonedirector”
set rsso enable
set rsso-secret ENC eoTXOqectoW0sjb5lLVW/7rr3BB0DocxlKeW64yfoIq7NTblyMc1TT9/V2M8m2LJmotwNrDYS+hOBSWV68wWULjuT88tOZHli7Nqqe8k5hoK4iHmLuG6x9R7apR9b+JU6O48mY8jiUaf48pY8wamagNdOALtrew6k+yWFzfd7gzo+qgag2sOI+Q46GnI1ybGPo6YQQ==
set rsso-endpoint-attribute User-Name
next
end

Next we need to modify NPS to send the values that we will match on the Fortigate. In this example I am matching I am saying that if any Domain users authenticate through the ZD, then send the IP/Username/”Tag” to the Fortigate so it knows who to apply the correct firewall policy to. My “Tag” I am sending in is the Class Variable of “Domain Users”..  Something to note is this is not the given AD group, but a variable I am assigning that just references the group. I could say “Social media” if I wanted, then match on that.

So lets modify the Microsoft NPS policies to reflect what we need.

Remember, we are going from the assumption that 802.1x is up and working, and NPS is great. So, how do we match a variable from NPS on the fortigate? We could really use a ton of different variables. Lets use the class variable. To assign the class variable we will modify the the Network Policy in NPS that we want to apply a to a certain criteria.

I will modify my “Connections to Wireless VIA AD Authentication” Policy. Then once, you edit the policy and go to “Settings” tab, there will be a few attributes already listed . You may have some already or not. We will add the “Class” variable, and then assign it to what ever value we want to match in the firewall group. In this case I am setting my value to “Domain Users”.

So from the settings tab, lets click “Add” under the Radius Attributes standard section.

Select “Class” from the list of attributes that comes up, it will then  ask you to enter a string that you want to set. This is the Keyword you will use to match the user to group in the Firewall. Just like use a FSSO group and matching the domain group. Some examples might be students vs teachers, or Domain users.

Press OK, and now we have the variable added, you can confirm as seen below:

Great, now we have the hard part done. Now, have some users log in to wireless, and see if you get correct RSSO users found in the firewall. you can check this my navigating in the firewall to User&Device – Monitor – Firewall

Awesome, it found my username, and my IP, but my group is blank, how can you apply a policy to user if they have no group? The answer – is just the same as the FSSO. If you do not have a firewall policy that references the Radius group that you created then no group, no filtering, nothing. So you need to create a new firewall policy and select the RSSO group you created as the source group. In my example the group is called Radius Domain Users.

To show a policy example check out below: My domain FSSO is above my RSSO policy.

Now that that is created and enabled, lets check the user monitoring – BAM! there it is, my group included.

Using RSSO and 802.1x is awesome, it allows you to kinda use a single pane of glass aspect and have Firewall, and Wireless be able to know who the user is just my them logging into the wireless network. Also, using 802.1x for wireless authentication and Key management is very secure. Having users known that are on wireless no matter what device can really be beneficial in reporting, either through Forticloud of FAZ.

Errdisable is an extremely cool feature on Cisco switches that can place a port into a disabled state due to some reason/errors on the port. There are many reasons a port can be disabled:
Duplex mismatch
Port channel misconfiguration
BPDU guard violation
UniDirectional Link Detection (UDLD) condition
Link-flap detection
Security violation
Port Aggregation Protocol (PAgP) flap
DHCP snooping rate-limit
Incorrect GBIC / Small Form-Factor Pluggable (SFP) module or cable

And many more. Here is Cisco’s Documentation :http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/69980-errdisable-recovery.html

The beauty of this feature is that if I screw something up, or if for example a I configure Port security and there’s and error it will shut down the port so that horrible things like loops or security violations are not allowed. By default Err-disable will shut down the port and it will take a manual shut/no shut of the port.

Finding out what ports and why they were put into ERRDisable

It is very frustrating to see ports come online, and then get shut off for some unknown reason. We can find out why they were shut off with a few simple commands

to find out what ports might be having errdisable problems we can do a :

show interfaces status errdisable

This command will show us all ports that are currently shutdown due to errdisable and the reason why. You can also get more specific with the :

show interfaces gig 1/0/12 status errdisable

to get more information just from that port.

You can of course also see what is happening through the logs or syslog showing something like this

%SPANTREE-SP-2-BLOCK_BPDUGUARD: 
   Received BPDU on port GigabitEthernet4/1 with BPDU Guard enabled. Disabling port.

Auto Recovery options

So how can we make this a temporary setting – what if I was putting a switch in a school, and I want to make sure that if someone plugs up another switch, and I see a BPDU, I shutdown the port and then want that port to come back online in x amount of time. There are two parts to that problem. 1, you have to set BPDU Guard on the port or whole switch. Once that is setup, it will automatically be put into Err-disable state. Now, to bring it out of that state automatically, we have to modify the err-disable recovery option, and the cause option (unless we want all causes to automatically come back up – which might not be good). There are a few commands to help us figure out what has been set already:

Show errdisable recovery

This command will report back to you any recovery options that have been set, and the default recovery value of 300 seconds.

Show errdisable detect

This command will show you if we are detecting this error. By default all should be detecting.

So, lets say I only want BPDUguard to recovery iteself every 60 seconds. This is what I would do:

Config t

errdisable recovery cause bpduguard

errdisable recovery interval 60

This will effectively enable recovery only for BPDUguard, and will change ALL recovery times to 60 seconds.

The following is the show recovery after the change:

Errdisable is a great feature that Cisco implements in almost all of their switches. It can really save some pain if you incorrectly configure a etherchannel, or have a bad cable that is really sending a ton of CRCs.

No one is probably trying to even do this anymore due to the new Dell switching lines, but thought I would see if I could help. I had this issue the other day, and it took a good bit of googlefu before I could my answer .

The problem I had was getting SSH enabled on a Dell PowerConnect 7048P. I created my user/passwords , and then generated my certificate, and then enabled the SSH server.. I got this error

PC-7048(config)#crypto key generate rsa

RSA key generation started, this may take a few minutes……..
RSA key generation complete.

PC-7048(config)#

PC-7048(config)#ip ssh server

SSH could not be enabled.

Hmmm… Why is that, all of my needed components are there, so why is it not working. The reason is there is no Cert to be used by SSH. These models use the Digital signature Algorithm (DSA) Certificate instead of the RSA cert. SO we need to create the DSA Cert.

PC-7048(config)#crypto key generate dsa

DSA key generation started, this may take a few minutes………………….
DSA key generation complete.

PC-7048(config)#ip ssh ser

No error!! and it works just fine.

Good reading for the comparison of RSA vs DSA: http://security.stackexchange.com/questions/5096/rsa-vs-dsa-for-ssh-authentication-keys

I was presented with a scenario the other day where we had two sites connected with a Site-to-Site VPN. The VPN was up and working great, but FSSO and LDAP would not connect to servers on the other side of the VPN for lookups.

This made sense because I knew the fortigate was using its outside (Public) IP for lookups and obviously that was not in my Phase 2 subnets to encrypt. So how can I change this?

Note, these steps change the source IP that the FGT uses to query LDAP or FSSO.

There are options in both objects (FSSO, and LDAP) In CLI to change the source IP address. See below

LDAP Source IP change

First log in through CLI, and edit the object, Then set the source IP. Once you end the CLI session it should be changed.

Now set the source IP address of the connection

Once you enter this and then end the session via the key word ‘end’ you will set the command.

Before moving on to the FSSO settings, here is a list of options available:

FSSO Source IP change

In CLI edit the FSSO object with the below commands, modify the source IP as below, and end the console to set the commands.

Once you enter this and then end the session via the key word ‘end’ you will set the command

That should be it! You modified your source IP to something in the encryption domain and it should now talk to the remote side and be able to do lookups.

Just in case below are all the options available under the FSSO.

Login banners are a great way of explicitly asking users if they are authorized to log in, show your legal terms, or just leave a message for users when they log in such as ‘don’t forget to backup the configuration’ .. etc.

In Fortigate login banners are very easy to write and enable. Just a few options need to be tweaked.

The banner can be modified by going to – system – config – replacement messages. Select the extended view at the top right, and then you will see the login banner, both pre and post. Pre is show before you login, post is shown after. The messages can differ. After you modify the message, remember to save.

Switch to extended:

Editing banner:

Now we need to enable the banner to show in CLI – to do this modify the global settings .

Now the banner will prompt.

If Pre-login-banner is enabled the banner will show as soon as you go to the page to login – before you even get prompted to log in. Post will prompt after login. This is what the banner looks like:

I have been working with Fortigate for a long time now, one thing that bugged the life out of me (and most clients I work with) is that Fortigate’s SSL VPN feature would not allow you to specify certain settings per portal or group. For example DNS servers and Domain suffixes. Most firewall/router vendors have been able to do this for years and with no problem.

Starting in firmware 5.2.2 you can now specify individual DNS servers per portal! That’s right, if I have two different domains using the SSL VPN and I specify individual user groups and portals, now I can give each side their own specific DNS servers.

The DNS setting per portal is CLI only as of firmware 5.5.5 – I see this changing in future firmwares (Still has not changed in 5.4.1 either) .  The modification is under the VPN – SSL  – Web portal options. You can also specify individual WINS servers. This entry is written for someone who already has the SSL VPN up and working. Something to note is that these portal settings override the global DNS settings configured under VPN – SSL – Settings

edit “Sales-Portal”
set tunnel-mode enable
set ip-pools “VPN-Pool”
set split-tunneling-routing-address “SSL-VPN-ROUTES”
set dns-server1 10.60.134.5  — DNS Server 1 , Overrides global config
set dns-server2 10.60.134.6 — DNS Server 2 , Overrides global config
next

And there we have it! We then can of course associate the portal with a certain group of users, so for example Domain 1 get Domain 1’s server and same for Domain 2.

The Fortigate firewall has a limitation of 10 LDAP servers that you can have on one FGT to do look ups. Normally this is not a problem in the least. Unless you have over 10 domains that you need to do lookups on. To get past this limitation there are a few options, one – Fortiauthenticator, or another option is to use Radius, and authenticate against all the domains. The latter is what I chose. I needed this to authenticate many user groups for different domains for the SSL VPN. So this is Radius authentication for the SSL VPN.

So setting up Radius, and the Fortigate to use radius for authentication was no problem. What was a problem though, was sending the group that the user should be in over to the radius server. I found that if I set the remote server group under the user group properties that authentication would fail. If i removed the group all would work perfectly but if you have multiple network policies on the Radius server, and maybe a user lives in two different policies then there’s a chance that it could authenticate incorrectly and give access to a user who should not have it. This could be bad.

After doing a lot of research I found that Fortigate should be sending in the group when configured under the user group as an attribute value pair, and given the NPS server understands how to handle the attribute it should work very nicely. I found the documentation on this KB article to be very old so I am writing my own, which you are reading.

So to recap what the below shows:

• Creating a radius server int the FGT
• Creating a user group, which references the Radius server, and then specifying a user group to match in Radius (NPS)
• Creating the radius policy, with the needed attribute pair within NPS.
• Results in Wireshark and exactly what is happening

Below are the links from Fortigate:

http://kb.fortinet.com/kb/documentLink.do?externalID=FD36464

http://kb.fortinet.com/kb/viewAttachment.do?attachID=Importing_Fortinet_VSAs_into_Windows_2003_Server.pdf&documentID=FD30830

First lets setup the Radius server in the Fortigate

Below is the image of my Radius server setup – pretty simple. Take note that I changed my authentication method from default to MS-CHAP-V2, this is what I set on my NPS server.

Next lets setup the user group. Notice this is a firewall group. You also have to manually type the user group since it does not exist .

I will omit the sections showing creating the SSL VPN tunnel policy, and the IPV4 policy allowing traffic in.

Now lets modify NPS. We will have to add a vendor specific attribute for the group name, and then match that in our policy.

Fortigate lists their attributes as below. Lots of cool options you could add like Vdom.

VENDOR Fortinet 12356
BEGIN-VENDOR Fortinet
ATTRIBUTE Fortinet-Group-Name 1 string
ATTRIBUTE Fortinet-Client-IP-Address 2 ipaddr
ATTRIBUTE Fortinet-Vdom-Name 3 string
ATTRIBUTE Fortinet-Client-IPv6-Address 4 octets
ATTRIBUTE Fortinet-Interface-Name 5 string
ATTRIBUTE Fortinet-Access-Profile 6 string

In NPS we have create our policy to grant access to the group we want. That’s no problem. I will omit steps to add the Network policy to allow access. After we get all the policy options we want , and select the group we want to grant access to we need to configure a Vendor specific option to match the group to the Fortigate.

Below are the pictures of exactly how to do that.

on the settings part of the Network Policy, click on “Vendor Specific” and select the option to add one.

Add the vendor specific attribute

Now lets configure our needed vendor/attribute. , and set it in the policy. Notice that we are entering the Vendor code that Fortinet gave to us through those links. Then we will configure the attribute itself.

Here we are filling in the values for the attribute. VPN-Users is what I am matching for my attribute string. If the user is not in the group VPN-Users, then it should deny them.

Thats it! our attributes are in and if the user is not specifically in the group VPN-Users then they will be blocked from accessing the VPN.

Under the hood

So what is actually happening here? it seems that when the user attempts to log in, the Fortigate will query the radius server and send the user credentials over and if access is granted – will allow the user to log in.

In Fortinet documentation they show that the Fortigate will be sending the group over to the radius server, if it matches the Vendor attribute we set, then access is granted. This is not what I have found to be the case (could be wrong). What I have seen happen is, the user attempts to login, Fortigate send the user creds to Radius , the Radius server grants access to the user (if the user meets the policies) and sends the group specified in the Vendor attribute back to the fortigate. The Fortigate then checks to see if that attribute matches what is configured in the Fortigate user group. If that matches, it allows the user to login.

To back this up – check out these Wireshark logs.

Fortigate to Radius server –

Notice that the User name is sent, but no group name

Radius response to Fortigate – Notice the group name (which in this case is infosys-VPN) that group is what in this example is being matched by the Fortigate, and the code of Access-Accept.

To go even further I have tested by removing the group or changing it to something other than whats in the Fortigate and it will fail, even though radius said the user was accepted. When running those tests where I change the group that was passed back to the Fortigate, I got an error on the FGT that said the user group was wrong.

So in the end, the Fortigate is making the decision to allow the user to authenticate based on the user group after radius allows the user based on credentials and policy.

I like to keep routing tables as clean as possible, and if your IP design and structure allows for very classful subnetting then there is no reason, I see to advertise all of your individual subnets when you could just have one aggregate address advertise out instead. Of course there are numerous reasons why you would not want this, route manipulation, etc.. but not in this case.

At this site my networks all fall into the 10.56.0.0/22 subnet.

As of now, my networks that are broadcasting to my BGP peer look like this:

The commands to enable route aggregation is listed below. What happens is that any networks within our aggregation block will stop advertising and in their place one summary route is added and advertised.

Now a get router info bgp will show that we went down from advertising 5 networks to advertising 2. This might not seem like a big deal, but if you had a large BGP network, with 100 sites like this, then aggregation can make a huge difference in router performance.

In 5.4 you now have the option to change the interface color. This is a great setting, because I am not a fan of the emerald green interface that’s default.

This is a great option, and easy to change.

To change the color just navigate to System – settings. At the bottom under view settings you will see the option to change the theme. There are currently 4 colors available. Green, red, blue, and my favorite Melongene. Good Job Fortinet!

Below are screenshots of how to do this.

Default color theme:

Changing the theme to Melongene

The best docs are always at docs.fortinet.com

Sometimes I get asked by clients how to block know attacking countries like Russia, or China from accessing their websites. I often hear that only US connections would be accessing their services so why allow others who might not be on the up and up.

Of course most attackers might pivot from compromised computers in the US, and thus bypass this security feature, but either way its not a bad idea. The below gives a good example on how to create a firewall “country” group and then block those countries from accessing any services hosted through the firewall. This will be done in Forti-OS 5.4.0. Its really the exact same steps in 5.2.

Also, there are many ways to do this. Instead of blocking Geographic regions you could only allow the ones you want to give access to.

Before beginning it might be a great idea to check out the new Fortiview feature to see what countries access your services the most. Under Fortiview- you can now see the countries tab.

Great, so in this example lets block the region of China – I know its not one of the top countries accessing my services.

First lets create the address object that we want to block. In this case I am setting the name of the address object as the country I am blocking. After creating the country object, I will create an address group call “Country blocks” add this to my firewall policy. That way in the future if I want to block Ireland, I can just add that object in the group and I am done.

Creating the address object for “China”. First go to “Policy & Objects” and create a new object.

Next we will fill in the needed info, and change the address type to “Geography”.

Now lets great that group, and add the “China” object to it.

Awesome, now just one more step – creating the firewall policy to block this address group.

Press OK, move this policy to the top of all WAN-LAN or your interfaces policies. This way it gets hit before anything else.

There are more ways than 1 to do this. when allowing traffic into your VIP or policy you could instead specify only the allowed countries.

The other night I had need to stop receiving a default route advertised from my BGP peer. I  also thought it would be helpful for anyone that is needing to do this – and to help myself, since I forget often, to write it up.

First thing we need to do is create a Prefix list to either allow or deny the routes we want. In this case I want to filter out the default route that is being propagated to me.

config router prefix-list

.

The things to note, rule 10 – I match that route exact (default). then in rule 100 I allow any other prefix – hence the “le 32”. that means anything that starts from 0.0.0.0/0-32 and since the 0/0 is blocked already in policy 10- everything else is allowed.

The we need to create our Route map to allow these routes on our in bound direction

config router route-map

Then lets apply the route-map to our peer.

config router bgp

After applying the route-map to the inbound direction we need to clear BGP either soft, or full to make our routing changes take effect.

Run this command to check the BGP advertisements for changes, and synchronize after that.

exe router clear bgp all in soft, or clear both directions (softly) with exe router clear bgp all soft

That should do it, and you will see the default route disappear from the routes learned from your peer. You can also do this to filter routes to any destination network.

Before learning the more about Manual or “Twice Nat” I would use individual object NAT (Auto NAT) for my incoming services, and use Manual NAT for my No-NAT or if I had to NAT VPN traffic before encryption (Policy NAT).

Recently though I started using it for everything. Once you get the hang of it, it is much more applicable to everyday NAT needs.

Something to note about Manual NAT:

• Processed before Auto NAT (Nat under the object command)
• Considers source, or source and destination together (Policy)
  • For example – I need to  NAT traffic to this IP, only when it goes to this network
• Configured directly from global config
• Uses objects only, cannot specify direct IPs
• Can specify to come after auto NAT.

Lets get started with a few examples. A list of all examples is below:

Static NAT – Public address/server to Private address/service

Group/Range of services forwarded into private server

Port redirection

Dynamic NAT

Policy Based Nat

Something to always note – 8.3 and above firmware’s require you to put in the private or real ip address of destination , not the public or Natted address.

Static NAT – Public address/server to Private address/service

Lets say my internal web servers  is at 10.20.20.10. The external IP I am using is 23.4.3.10. I want to NAT in only HTTP (80) traffic to my server. No problem.

Lets create the our address Objects

object service OBJ-TCP-80
 service tcp source eq 80

object network OBJ-10.20.20.10
 host 10.20.20.10
object network OBJ-23.4.3.10
 host 23.4.3.10

Great! Now lets create our Manual nat rule to allow that traffic in.

nat (inside,outside) source static OBJ-10.20.20.10 23.4.3.10 service OBJ-TCP-80 OBJ-TCP-80

Thats it, we would create our ACL to allow traffic to the Private host (Remember that, big time change in 8.3) and that’s it. Our traffic would be natted from Public, to Private port 80.

The next example will be a 1 to 1 NAT from our private object created above, to our public object also created above.

NAT (inside,outside) source static OBJ-10.20.20.10 OBJ-23.4.3.10

Modify the ACL to allow traffic to 10.20.20.10 and traffic should make it to the host.

Forward in a group or range of services

In this example we will forward in a group of service objects. Lets say HTTP, HTTPS, and SSH . Still using our local/public hosts. You have two options, 1 create a service group full of existing objects, or create a group of Service-objects. Int the below example I will create a group of predefined objects. This is due to having so many different configurations of groups.

object service OBJ-TCP-80
 service tcp source eq 80

object service OBJ-TCP-443
 service tcp source eq 443

object service OBJ-TCP-22
 service tcp source eq 22

object-group service Web-services
group-object OBJ-TCP-80
group-object OBJ-TCP-443
group-object OBJ-TCP-22

object network OBJ-10.20.20.10
 host 10.20.20.10
object network OBJ-23.4.3.10
 host 23.4.3.10

So now our NAT rule:

nat (inside,outside) source static OBJ-10.20.20.10 23.4.3.10 service Web-services Web-services

Port redirection

Sometimes we have the need to make a port such as 8080 on the outside go to our websever on the inside at port 80. The below example shows how to do that. In this example we will forward in port 8080 on our public IP to port 80 on our private webserver. First we need to create the objects for the service and networking addresses, and then apply the nat rule – an don’t forget our ACL. To help visualize whats happening here look at the format of the rule:

nat (source interface,destination interface) source static object ((private) IP) object ( Natted (Public IP))  service Private-Service Public-Service

object service OBJ-TCP-80
 service tcp source eq 80

object service OBJ-TCP-8080
 service tcp source eq 8080

object network OBJ-10.20.20.10
 host 10.20.20.10
object network OBJ-23.4.3.10
 host 23.4.3.10

So now our nat rule:
nat (inside,outside) source static OBJ-10.20.20.10 23.4.3.10 service OBJ-TCP-80 OBJ-TCP-8080

Dynamic NAT

I like to usually do this through Auto nat, but you can most definitely do this through Manual.

object network OBJ-10.0.0.0/8
host 10.0.0.0/8

nat (inside,outside) source dynamic OBJ-10.0.0.0/8 interface

You could also specify “any” instead of the internal address object, or specify the public IP you want to be natted to instead of “interface”.

Policy Based manual NAT

Manual NAT is the only way I believe that Policy based natting is done. You would use this if you had to NAT traffic into some other IP when going to a certain destination address. In this example lets say we need to NAT traffic from 10.0.0.0/8 int 1.1.1.1 when going to destination 3.3.3.3. This comes up a lot in healthcare when both sides need to nat into a Public address so there are no address conflicts.

Lets first create our objects, then our Nat rule.

object network OBJ-10.0.0.0/8
 host 10.0.0.0/8
object network OBJ-3.3.3.3
 host 3.3.3
object network OBJ-1.1.1.1
 host 1.1.1.1

So now our nat rule:

nat (inside,outside) source static OBJ-10.0.0.0/8 OBJ-1.1.1.1 destination static OBJ-3.3.3.3 OBJ-3.3.3.3

This reads that whenever 10.0.0.0/8 is going to 3.3.3.3, nat 10.0.0.0/8 into 1.1.1.1. This might help:

nat (inside,outside) source static Private-IP Natted-IP destination static Real-destination Natted-Destination

So, if this was used for a VPN you would just create an Crypto-ACL and the source would be your Natted-IP, and destination would be your 3.3.3.3 or whatever address lives across the tunnel that you set as your NAT destination.

The other day I had the need to plug a Ruckus Access point directly into the Fortigate firewall. The client only needed 1 AP, and connecting directly into one of the ports on the Fortigate was the best way – PoE was provided by an injector.

The question came up of how to create the Vlan interface when directly connecting the device to Fortigate.

In this example I will create the vlan on the Internal switch “lan”, and control the vlan from the Ruckus Zonedirector. This will create two separate logical interfaces. Internal, and Staff-Wireless, my newly created vlan.  These two interfaces will require IPV4 policies to allow communication. If you have a lot of VLANs it might be a great idea to utilize Zones in the FW to reduce the number of firewall policies needed.

Lets get started

Vlan creation of Fortigate

So, lets create the vlan for “Staff-Wifi” Vlan 200. You can just create

Now lets put in the needed info.

The below shows the status of the interface:

Notice the VLAN ID – this is seen by right clicking the column settings and enabling that.

Thats it! The Ruckus AP will tag “Staff-Wireless” traffic as vlan 200. So, when the FGT sees the vlan tag of 200 on any ports in the lan switch, it will be treated as Staff-Wifi, thus getting all of its network and policies.

To make the AP work correctly, it needs to be plugged directly into the FGT or a switch behind the FGT that has the vlan created and that vlan would need to be tagged on both the AP and uplink to Fortigate.

Below shows the advanced options of my Ruckus  ZD. I am tagging the Staff-Wifi SSID as vlan 200.

Remember on the Ruckus side only vlan 200 is being tagged for Staff-wifi AP management traffic is untagged – so it would be on my “LAN” switch network.