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 22.214.171.124 soft out
exe router clear bgp ip 126.96.36.199 soft out
After you clear you should see a good drop in routes being advertised to those neighbors.
get router infor bgp neigh 188.8.131.52 advertised-routes
Today I had an issue while configuring two 60c’s in an HA configuration. This usually takes about 2 minutes and is extremely easy. Unless your hardware doesn’t match. HA requires that hardware matches on the two different units. When these were purchased the hardware did match, but at sometime in the past, one was RMAed and we received one with a hard drive. This broke the HA capability.
The error I kept seeing was about the hardware not being the same. The error was: “slave and master have different hdisk status. Cannot work with HA master. Shutdown the box! The system is halted.”
This command can get you past that:
exec ha ignore-hardware-revision enable
This will allow the HA cluster to ignore the hardware-revision for the frigates and come up.
There are a lot more things that will cause problems, for example if your drives have been formatted with a pervious version of fortios. You might need to run :
Fortigate supports many HA options. They have a great active/passive HA option, as well as Active/Active. VRRP is another option that is supported. VRRP (Virtual Routing Redundancy Protocol) is a open standards protocol that helps eliminates the single point of failure for a network by allowing another device to take over routing automatically.
Basically one router is the Master (active), the other is a Backup (passive), the selection of which device is active or passive is based priorities of each device, highest priority (1-255) is the most preferable. The priority of 100 is default, and 255 the best. There is a heartbeat which is just a Multicast packet, that goes across a link that both devices use (normal lan link is fine). If for some reason that heartbeat is lost , then the backup router will take over as the master.
VRRP is a great way to make sure that if one router fails the passive router will become active and take over routing for the network. VRRP creates a virtual mac address that is shared between the two devices, the active device answers for the virtual mac and takes control of the Virtual IP that is also shared between the two.
You can use VRRP to load balance traffic as well. Load balancing is achieved by using to different VRRP groups, and balancing which router is primary for what group. The below image should help clarify what I mean.
You can use those two VRRP groups as primary and secondary’s for the default gateway in different vlans. So in this case, you could have Vlan 10’s default gateway on Fortigate A, and Vlan 20’s on Fortigate B, therefore having fail-over for both, but splitting up the load. This might be a great thing to do if you have a HA cluster of 60C’s, and they just cant handle the full traffic load in a HA scenario. Remember. each config is different on these firewalls, there is no config sync. There is an option to sync sessions between the firewalls, so that if one firewall were to fail, things would pick right back up and not have to establish the sessions again.
Things to note in this config – There is already an IP address assigned to the Vlan interface for management when when the VRRP address might not be active. I am also using the Preempt option to make sure Active is always Active if its online. The Physical interface the Vlans are configured on are trunks on both links going to Fort-A, and Fort-B.
The config for VRRP is interface based, and CLI only.
config system interface
config vrrp edit 10 set vrip 10.10.10.1 set priority 255 set status enable set preempt enable end set vrrp-virtual-mac enable next
edit Vlan-20 config vrrp edit 20 set vrip 10.10.20.1 set priority 100 set status enable end set vrrp-virtual-mac enable end
config system interface
config vrrp edit 10 set vrip 10.10.10.1 set priority 100 set status enable end set vrrp-virtual-mac enable next
edit Vlan-20 config vrrp edit 20 set vrip 10.10.20.1 set priority 255 set status enable set preempt enable end set vrrp-virtual-mac enable end
This config will do exactly what we want, create a Virtual IP that is shared, and make sure the configured active (priority) unit takes back over the role of active if it goes offline and comes back online (preempt),
*Note – Most of these issues have been fixed in 5.2. By default now, if you select https inspection – Certificate inspection you will just get a blank page when you go to a https that is not allowed.
The Fortigate Web filter is amazing! I think it stands up to the best web filters out there.
But, like all webfilters SSL can be a bit tricky. Fortigate offers its own SSL Certifcate “Fortigate-CA-Proxy” to the client when it does a few things:
1. Deep packet inspection (imagine a man in the middle attack). This way the Fortigate sees all traffic that comes in the session even if it was encrypted.
2. When it sends its replacement message (Blocked) to the client.
Some problems come up with this. The cert has to be trusted by clients, this can be easily done if you have a internal CA, or you could create a Windows group policy to push the certificate into their trusted store. I know you might ask, what if I get a signed cert for this? The certificate is a CA-True certificate. That basically means you would have to get a certificate from a trusted publisher that says you are a public CA. I would say most CA’s would not give us one. But what if you want SSL inspection for Guest clients but don’t want them to see the cert error? The answer lies below friends. Something to remember is you have to have SSL inspection enabled on the firewall policy to get HTTPS inspection to work.
To have the Fortigate block the website without giving an error there are a few things that need to be done:
1. Select the webfilter to use https-url-scan to only look at the URL, not to use deep scanning
2. set the Fortigate to not respond with a replacement message. Remember it responds with a HTTPS blocked page – so therefore you see the HTTPS cert.
As of Patch 7 this is a CLI command.
To enable HTTPS-url-scan which looks that the URL not the traffic going through:
config webfilter profile
edit default (or your profile name)
set options https-url-scan
To disable the HTTPS replacement message:
config webfilter profile
edit default (or your profile name)
set https-replacemsg disable
To give an example:
Lets say I block the category “social networking” and go to http://facebook.com it will be blocked. If I go to https://facebook.com it will show a blank screen – no error message, but will not work. Before enabling these commands I would see the error message, then after accepting the cert I would see the block page.
Note* there might be a way to have the replacement message be http, instead of https. I am looking into this.
Hard coding speed and duplex settings on a device is very important. Some times it is essential to hard code your settings to work with and ISP or neighboring device. To change the speed/duplex settings manually you will need to use a CLI command. The default setting is to Auto Negotiate, but as we all know sometimes on the ISP or local side it can negotiate to half duplex, or never correctly negotiate.
How check speed and duplex of the interface:
Fortinet now has the ability to see speed/duplex by hovering over the interfaces in the GUI. This option became available in MR5 patch 4 i think.
To check this through the CLI there are a few ways to accomplish this. two command that can do this are:
get system interface physical
This command shows the IP, status, and speed/duplex.
The next command is:
get hardware nic X
This command gives you much more info, such as errors and drops.
To set the Speed and Duplex of the interface to 1 gig full duplex use the cli commands:
Config system interface
set speed 1000full
Thats, it! Notice that get system hardware nic gives you all kinds of stats about that interface.
The Fortigate SSL is an amazing feature, but when users do not log in that often to any internal resources their AD password may expire and the user will not know. What really stinks is if that user has to post data for the month, and logs in at midnight for an 8 a.m. deadline! Luckily Fortigate has the ability to push the LDAP password expiration notification to the user, and can even let them change the password through SSL VPN login.
– Get SSL VPN up and going with LDAP Authentication – This has to be an LDAPS connection to change the password, and your account to query LDAP has to be a domain admin!!!
– In CLI modify the LDAP server to allow password expiration notification, and change.
First create or modify your LDAP server in the GUI, and make sure its set to use LDAPS. The image below should be a good guide. Remember, the service account you use to query LDAP does not have to be an admin account, but if you want to change passwords then it does have to be a Domain-Admin. A good idea is to always create a service account to use for the Fortinet to query LDAP. That way if your admin password changes it will not affect this this account.
After that is configured, and tests/querys successfully then lets drop down to CLI and get the following configured.
Config user ldap
edit “Server name”
set password-expiry-warning enable
set password-renewal enable
For a look at all the options see picture below:
And that’s it, after this LDAP will push those messages to the client when they log in.
Remember, that the LDAP connection has to use SSL (LDAPS) to change the password.
Docs.fortinet.com is always the best place to get any Fortinet info.
Fortinet like most firewall vendors supports almost all Dynamic routing protocols. BGP is one, the GUI has simple to setup BGP options, but many do not exist in CLI, which might be for the best. In this post I will show how to create a Route-map and prepend the AS path influence ISP/neighbor routing.
First lets talk about why you would want to prepend an AS path. You would want to do this to influence how neighbors get to your routes. For example, if you had two ISPs, or neighbors and wanted to broadcast your routes to both neighbors, but wanted everyone to take neighbor 1 to get to your router, with a backup of Neighbor 2 you could prepend the AS path and make this happen.
BGP is a very deep protocol and there are many different ways to influence routing. Routers will always take the shortest AS path to get to its destination so that is the preferred method for this.
– Add BGP neighbors/networks – you can do this in GUI
– In CLI create route-map and use the commands to prepend YOUR AS path
– Assign Route-map to neighbor
– Clear BGP routes.
Create BGP in GUI.
This includes our AS number, the Neighbors and their AS numbers, and our networks we are advertising.
Lets then drop to CLI and create our Route-map
config router route-map
config “Name” —- create route map
edit rule X — from there you can set your Prepend
set set-aspath “x x x “
set action permit — I did not add this in the image. Routes will be blocked if this is not added.
Now lets assign the route map to our neighbor. Since we are wanting to control how routing will get to us, we will apply this route map to outgoing routes.
the command “set route-map-out” is what sets the route map on the outbound routes.
Last but not least, lets clear the IP routes so our prepend takes effect. You can do this through the command:
exe router clear bgp ip x.x.x.x out
This will clear all routes from this neighbor. If this is a live production network, it would be better to run the command:
exe router clear bgp ip x.x.x.x soft out
A soft reset uses stored prefix information to reconfigure and activate BGP routing tables without tearing down existing peering sessions. Soft reconfiguration uses stored update information, at the cost of additional memory for storing the updates, to allow you to apply new BGP policy without disrupting the network. Soft reconfiguration can be configured for inbound or outbound sessions.
So now we need to take a look at the routes we are sending out to see if our AS has actually be altered. After resetting the peer it might take a minute or two before this shows up correctly.
The command is:
get router info bgp neighbors x.x.x.x advertised-routes
Now we are controlling how devices will get to our networks in a Dual homed situation (two connections to ISPs). The querying devices will always take the lower AS path to get to its destination.