Fortinet like all vendors supports BGP and has many ways to configure it. In this case almost all settings are configured VIA the CLI. In this post I will show how to configure the Local preference attribute to influence what routes a device will take to leave the network. For example, if you have two ISPs, and we use one for primary, and the second for a backup then we would want to change the local preference to make ISP 1 more a better choice.
Changing the local preference of routes from the default 100, to a higher value makes those routes the best choice when leaving the network. Also you can use a prefix-list to change just the preference of one or more routes, you do not have to do all routes advertised by the neighbor.
Steps needed are:
– Get BGP instance configured
– Configure neighbors
– Create route map
– assign preference in Route map
– Apply route map to neighbor
– Clear BGP routes, and check new preferences.
After you get BGP configured VIA CLI or GUI we can start with creating the route map.
You can name the Route map whatever you like, for example if you have two ISPs, you might say ISP-1-Local-Pref. Then modify the rule you want, and change the local preference. Remember the higher the local preference the more preferred.
Command:
config router route-map
edit name
config rule
edit 10
set local-preference X
end
Next we can apply the route-map to the neighbor we want to set preference on.
Once that is configured, we can check the perfernce of the routes with the command:
get router info bgp networks
You might notice that the preference has not changed. This is because we will need to clear the routes first. We can do this with a few different commands:
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.
Thats it! now we should see the new preference associated with our routes:
Notice the 500 instead of the default of 100. Everything is working, now all my routes going to the 10.0.0.0/16 network will take the 169.254.255.77 neighbor. Also notice the > symbol. This means it is the best route, and therefore the one put into the routing table. Other routes will not show up in the GUI routing table.
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.
Steps:
– 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.
Route-map Creation
Lets then drop to CLI and create our Route-map
Commands:
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.
end
Assigning Route-map
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.
Status
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
That’s it!
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.
The maximum segment size (MSS) is the largest amount of data, specified in bytes, that a device can handle in a single non-fragmented piece. The MSS is essential in internet connections especially web surfing.
I once had a very crazy issue, where I could surf to almost all http websites, but many https sites such as USPS.com, hotmail.com would not work. The header would come up, look like its working and .. nothing. After a few packet captures I noticed that it was fragmenting some of the https packets coming in. The crazy thing is many websites worked perfect.
To troubleshoot I put a Cisco PIX I had laying around into production to replace the Fortigate. Everything worked no problem.
So after many hours researching, I changed the TCP-MSS to 1360 and boom, no issues. I asked Fortinet support why this was happening in contrast to the Cisco PIX. They said that the cisco will automatically change its settings (I have not researched) but the Fortinet will not. Go figure.
So if you hear problems like : Can’t get to HTTPS sites , USPS will not load, Browser loads certificate but site does not come up. Check these commands:
In MR4:
config system interface
edit port X
set tcp-mss-sender 1360
set tcp-mss-receiver 1360
end
MR5:
config system interface
edit port X
set tcp-mss 1350
Logging into the firewall with Active directory accounts can be a great thing. You can base login privileges on A.D. security groups, and track what the users do. For example if you had help desk users and only wanted them to only have read access, no problem. Also, what if you wanted to audit what a user does on the firewall, no problem. You can do this through a mix of Logins and admin profiles.
There are a few things we need to do, create the LDAP connection, create our security groups in A.D. to match in the firewall, create the user group in the FW and assign it the correct admin profiles.
1. Create the LDAP connection
You do not have to be a super user to query the LDAP account, I would just create a Fortinet service account, and use that to query with.
2. Create AD security groups. If you want domain admins to log in, great just match it in the firewall. If you have help desk users that you want to have restricted privilege than you would have to create that in A.D. and add the needed members.
3. Create local firewall groups that match the LDAP groups.
Here we create a “Firewall” Group, and add our remote server to the list. If you notice you can query LDAP from here, and select the group you want by clicking on the folder to the left side of the group name.
4. Add the group as a admin that can login
Under system – admin – administrators add a new admin.
Create the name you want, and select the group we just created. Then select the admin profile we want. This is for admins, so they will be super admins when they log in. If you wanted a custom profile, lets say restart the device, but that’s it then we can create that, then add it. There are more options here such as using Forti-token, and email.
Notice that the wildcard option is checked – A wildcard admin account is an administrator account with the wildcard option enabled. This option allows multiple different remote administration accounts to match one local administration account, avoiding the need to set up individual admin accounts on the FortiGate unit. Instead multiple LDAP admin accounts will all be able to use one FortiGate admin account.
5. Create a different admin profile for privileges.
In this example I will create a help desk account, that can only configure system settings (IP address, etc). Otherwise everything is read only.
After saving this, you can go back and add it to the admin group.
After setting up a SSL VPN tunnel, one of the biggest complaints I get is “I cannot get to my shares”. This is because the Domain suffix has not been pushed out to their tunnel interface. This is easy to remedy, but seems to be in CLI only.
Within cli you have many options under the ssl vpn config that are not presented in the GUI.
You can edit the VPN tunnel with the command:
config vpn ssl settings
Here are a list of all the settings:
as you can see, the dns-suffix is an option, as well as DNS servers.
The Suffix option is not presented in the GUI, but the dns servers are.
The command to set the suffix is:
set dns-suffix corp.local
end
Make sure your DNS servers are also set for your internal network and it should now work without a problem.
The best information available for anything fortinet is always found at docs.fortinet.com. This entry will show the needed steps to create a SSL VPN via the web interface.
Creating the SSL VPN has many working parts that come together to make one of the best Remote access VPNs out there. In this example we are creating a Split tunnel VPN, and enabling Tunnel mode.
The SSL VPN is one of the best features of the device, it has an open license, so you can have as many people connect as the device hardware supports. No crazy licensing for SSL VPN as with Cisco and Sonicwall. You can also utilize the VPN to get select information to users based on their AD security group. For example if you have a business with users traveling all the time, you might have a certain portal for one group of users and have their internal bookmarks and file shares, and completely different portal for office staff users. Another great benifit is in the protocol itself, SSL is almost never blocked by outbound firewall policies. A lot of companies (hotels, hospitals) and educational institutions block IPSEC from leaving the network which stops your remote access VPN from connecting.
Steps:
1. Create Address object for SSL Subnet and Internal networks
2. Create route for new subnet
3. Create Users/User group for user authentication
4. Config the VPN Portal
5. Config the VPN settings
6. Create the SSL VPN policy, including the projected subnet for Split Tunnel.
7. Create policy to allow traffic from the Lan to SSL, and from SSL to Lan.
1. Create Address object for SSL Subnet and Internal networks
We will create an address object with the Subnet of our SSL VPN clients. I would recommend using a crazy private IP subnet as to not conflict with Home/work local subnets.
Then we need to create another object for our Protected subnet. This is our internal network that we want the remote user to be able to access. If there are multiple subnets it might be better to add an address object group.
2. Create route for new VPN subnet
Since the SSL VPN is a “interface” we will route our subnet across of it. Notice our device is ssl.root, and that removes our needed gateway.
3. Create Users/User group for user authentication
There are many different ways to configure authentication within the device. You can authenticate VPN users against LDAP, Radius, or local accounts. In this example I am just using local accounts, but using LDAP or Radius is a much better option. You can use just individual users, or groups to authenticate to within the VPN policy. I would go ahead and create a User group so that you can add any local, radius, or ldap users into it in the future.
I am creating a user group call SSL_VPN and in this case its just local. If I wanted to add a LDAP/Radius server to authenticate against, I could just add the remote server. If I wanted to get even more specific and say authenticate against a security group within LDAP I would just modify the remote server portion of the user group to add that.
4. Config the VPN Portal
The portal is the landing page of the SSL VPN. It is a great place to add book marks, shortcuts for RDP, or info for users. For example, we have an internal sharepoint site for users, by placing a link on the portal, users they just have to click and Whola, instant access. This is great because installing the VPN client which allows tunnel mode requires admin access to the PC. If a user is traveling or at a hotel they might not have this access. Other great uses are RDP session, and file shares. Both will launch in a Java applet window and allow you access to RDP/SMB.
We are using the “Full-access” Portal, this is just a name. I added the IP Pool for the clients to get tunnel addresses. You can customize the page to any specification. A note, you can also fully edit your VPN login page to reflect your company logo, etc. You can do this by adding in the feature under system – admin- features and enabling it.
5. Config the VPN settings
The VPN settings consists of the IP pool, Port used, encryption strength, and of course DNS/WINs servers. If you want to push your domain name so that DNS will resolve to this interface, its a CLI command. I will do another entry on it.
6. Create the SSL VPN policy, including the projected subnet for Split Tunnel.
This is where we actually allow access from the internet to our VPN portal. It is also where we specify our Protected subnets, which are the subnets injected into the clients routing table. You can also specify what portal certain users will see. For example, if you had a group of teachers who needed to get to the Teacher portal, and an admins group that needs to have a different portal and ACL to get to all servers.
Notice we select VPN as type, then incoming interface. The Local protected subnets are what we are pushing into the routing table of our client.
Next create an new Authentication policy.
From here select your user group that we created earlier, if you want individual users select those as well. You can also enable UTM if you feel its needed.
Now just save all the settings
7. Create policy to allow traffic from the Lan to SSL, and from SSL to Lan.
For the last step we need to create policies to allow traffic in both directions. By default all traffic is blocked between interfaces int he firewall. The SSL VPN is an interface, so we need to allow traffic to it.
Just create a policy with Source interface being ssl.root, and allow all traffic to your LAN (or however you see is best to secure) and then another policy from LAN to ssl.root.
Thats it! There are some optional configs dealing with Certs on both sides, and much stronger encryption methods.
Notes*
If you have a MPLS, or DMZ interface where you need VPN clients to access you will have to create another VPN policy going from WAN to – DMZ, or WAN to MPLS and just mirror the WAN-to-lan SSL VPN policy. You will also have to modify the protected subnets with that interfaces network. If anyone has trouble with this feel comment and I will explain better.
On top of that you will need to create more ssl.root to DMZ and DMZ to ssl.root policies to allow access between the interfaces.
In 5.0 Fortinet offers the option of using DDNS to register a DNS name if you have a dynamic address. This is great for remote offices who might need a IPSEC site-to-site tunnel to a corporate office. No static IPs! Its very easy to configure and free if you use Fortinets own service. You can configure this under System – Network – DNS.
Notice that this is set to only port15. What if you had two dynamic interfaces from two separate ISPs and wanted to create redundancy for your VPN? From the GUI you cannot. CLI to the rescue! Fortinet has a lot more options for this in CLI. You can create other DDNS interfaces and use more services then just fortiddns. For instance I use dyndns and could actually use my account with dnsalias.com.
Check out these options:
So from here you can select any interface to monitor or use any of those ddns-servers – crazy this is not in the GUI!
One thing to note is that when multiple DDNS entries are created only one shows up in the GUI.
Fortinet does a great job with almost every aspect of the Fortigate device. There are a few hidden , but very important options that you cannot configure in the GUI of Fortinet. One being DHCP options, for Voice, Wireless, Etc. Below are the setups to setup a DHCP scope in CLI, and add options. Another option is to configure the scope through GUI, and then just modify the scope through CLI to add the options.
Within the Gui in FortiOS5 the DCHP config is in the network interface. This is a great place to have it. In CLI the option to configure it is
config sys dhcp server
Below image shows all commands needed in CLI
Once you edit the dhcp scope (config sys dhcp server.. then edit the scope id. )
You can add the following commands:
So, lets add option 46. This could be used with Ruckus wireless to push AP broadcasts to the Zonedirector.
To set the option for example here to an IP address, it requires you to convert this to HEX.
I used this : http://www.kloth.net/services/iplocate.php
after setting this command, my APs hooked up to my ZD.
So to recap, with DHCP and FortiOS5 you can create the DHCP scope totally in CLI, or it works great in the GUI. You can configure this under network – interface. If you need to add options such as WINS, NTP, or other options it might be best to configure these through CLI.
sFlow uses sampling to send real time monitoring updates to your favorite sFlow analyzer. Fortinet supports sFlow but it can as of now only be configured in CLI.
To configure sFlow for fortigate:
The following commands configure a FortiGate appliance to sample packets at 1-in-512, poll counters every 30 seconds and send counters to an analyzer which in my network is PRTG. PRTG is free for 10 sensors, and the sFlow sensor counts as just one of them :). sFlow uses UDP and by default uses port 6343, which you can change to anything you would like.
config system sflow — remember changes don’t take effect until this command is entered.
set collector-ip 10.10.10.200
set collector-port 6343
end
Then for each interface:
config sys interface
edit port1
set sflow-sampler enable
set sample-rate 512
set sample-direction both
set polling-interval 30
next
end
In PRTG setup the sFlow sensor, make sure to set the port and you should start seeing some really good statistics come in. A tip with PRTG is create a new sFlow sensor with a different port for each device sending flows.
TravelingPacket - A blog of network musings 