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!
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.
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
config vpn ssl web portal
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.
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 184.108.40.206 (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.
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.
The entry is written for a 90d, but will work the same for a 60d or 80d, even some C models.
By default the Fortigate is in “Switch mode” you will only be able to see the “internal” switch, and cannot add or remove interfaces from this switch. In this mode you can add more switches, but not remove the current ports.
In the next few parts we will change the switch mode to interface, and be able to add/remove ports and switches.
Before doing anything to the Firewall make a backup. When we actually change the interface mode it will delete the IP address on the internal interface. So connect to a WAN or DMZ port and use the GUI, or make sure to be consoled into the firewall VIA the serial port (console).
First we need to remove any reference to the “internal” switch itself. If you have a default config then there will be only two. The internal->WAN policy, and the DHCP server under the “Internal” interface.
You can see all references attached to the interface by navigating to System-Network-Interfaces and modifying the settings to show the Reference tab.
once those references show up, you can click on the number and navigate to the exact location of that reference. For example, let say you added an address object a long time ago and added the interface. Bingo – shows you exactly where.
After removing all the references by deleting them (yes, deleting.. so make a backup!) you should now see a 0 balance in the references. We can now change the interface mode in CLI.
You can either do this through a terminal such as putty, or through the GUI CLI app. Remember after changing the interface mode, it will delete your IP address on the internal network. So do this VIA Console, or go to the GUI on the WAN or DMZ interface.
config system global
set internal-switch-mode interface
Then click y to reboot the firewall, when it comes back it will be in interface mode.
Once it is back up, login VIA the GUI on either the WAN1, WAN2, or DMZ ports. Then you should see something like this:
Now, under this page System-Network-Interfaces lets click the “Create” Button. From here you can create your switch. Select the type as Software or hardware switch depending on your model. You can also add your ports, set the name of the interface and the IP.
Once you press OK, you should see your new interface listed under system-network-interface as seen below
Recreate all of your policies, to allow access to and from and everything should work great. If you have any questions or I failed to explain anything please let me know.
You can use a different IP address to answer for the SSL VPN.
Lets say that your interface IP (The default IP address that is used with the SSL VPN) already has HTTPS (443) forwarded in to a internal server, and you really want the SSL VPN port to be 443. You have an option.
You can add a secondary IP address under the WAN interface that does not have a reservation already for 443. Then use this IP address for the SSL VPN.
To do so:
Add your secondary IP address – Note this has to be a public address, given to you by your ISP..
Then go into the VPN settings and modify the port for what you want. Notice that the address it says will work is still the primary IP, even though the secondary will work just fine.
Recently I needed to make sure select traffic would flow over a certain ISP link. Unfortunately that link had a dynamic address, which meant the address and gateway of that route could change anytime. Also I wanted to have my primary ISP failover to this link if needed.
To accomplish these things I needed to have both default routes in my routing table at the same time. This means that they both have the same distance, but different priorities. One way to accomplish this is to configure a static default route, and just change the priority of the link , but how can you do this when you do not know the gateway?
You can create a dynamic-gateway static route in the Fortigate.
Through CLI you can create a dynamic gateway route using the above syntax. Remember, the higher the priority the less preferable the route.
You can also create basically the same thing under the interface of the WAN link by using the distance, and priority interface commands listed below:
So now if we check our route monitor:
We have both default routes, and can successfully use a policy based route to push the needed traffic out.
On 1500D’s and other large devices the command is a little different. See the bottom.
on 1500D’s it seems the command changes a little bit to : “diag hardware nic port40“— this was the results from a 1500D that is running 10 gig. The output is at the bottom.
I started doing some research and found that there was a command that would drop you down to a very limited Linux shell. There are a few commands that are support such as “ifconfig”. This blew me away. I have been wondering if there was a command like this for a long time.
Log in through CLI, and run ” fnsysctl <command>” for example “fnsysctl ls”.
So to get the interface stats, I would just run: “fnsysctl ifconfig port16” or whatever port you want to look at.
And there we go. I have search for some other ways to get this, and have not found anything. If someone finds something better please pass it along.
Recently I had a project where 1 Fortigate had two MPLS networks connected for redundant connections. These two MPLS networks were from different providers. I had a few problems where networks from other peers were transiting through my device to be advertised out to these links. I did not want this to happen. There are many ways to do this exact thing, but what I did was use an AS path filter with regular expressions to find anything passing through my remote peers and block them going out on the opposite peer. The image below will sum up what I just wrote a little better:
So as with almost all BGP commands on Fortinet – they have to be done through CLI. The following are the commands needed to create the AS-Path list, Create the Route map, then apply the route map to our neighbor. We are using regular expressions to map grab our AS path, you might say what the heck is a regular expression? Here is a link that explains how to put an expression together http://blog.ine.com/2008/01/06/understanding-bgp-regular-expressions/ . If you notice what I am doing “_65000_” This basically says that if 65000 is in the AS Path block it. the _ is a space so my expression reads – Anything before 65000 or after 65000 gets blocked. For example, if you wanted to block routes that originate from 65000 you could do “_65000” or “_65000$” The dollar sign means that is the end of the string, so nothing else beyond that.
config router aspath-list
set action deny
set regexp _65000_
set action deny
set regexp _65400_
config router route-map
set match-as-path Match-WS
edit 11 — Note- There is a deny all on the Routemap, this rule 11 basically says permit anything else
set match-as-path Match-L3
next — Note- There is a deny all on the Routemap, this rule 11 basically says permit anything else
set capability-default-originate enable
set remote-as 65400
set route-map-out “Block-L3”
set send-community6 disable
set remote-as 65000
set route-map-out “Block-WS”
set send-community6 disable
Now we have to flush those routes, we can do this with the command:
exe router clear bgp ip 220.127.116.11 soft out
exe router clear bgp ip 18.104.22.168 soft out
After you clear you should see a good drop in routes being advertised to those neighbors.
get router infor bgp neigh 22.214.171.124 advertised-routes