Accessing your GNS3 network from your physical network

To access your GNS3 virtual network from your physical network, you can use the "Cloud" endpoint device in GNS3, plus a secondary network adapter on your computer.

Connect your secondary network adapter to your network (I'm using an USB adapter), and configure a static IP address and subnet mask on this network adapter (do not configure a default gateway).

When you connect the "Cloud" endpoint device to your GNS3 network, you will be able to reach the virtual environment from your own computer. Make sure to select the secondary network adapter when connecting the "Cloud" to your virtual network.

If you have a DHCP server on your pysical network, the GNS3 devices can utilize that.

PS: If you only need access from your virtual environment towards your physical network (or Internet), you can just use the "NAT" endpoint device instead. It has a built in DHCP server.

GNS3 version: 2.2.5

Fortigate web filtering - YouTube and Vimeo problem

The configuration part of the Fortigate web filter is very easy. Fortinet has made a good job with categorising web sites throughout the world, and you can easily select what categories you want to allow, block, and which to prompt the user with a warning.

For full inspection (proxy) you will need to use a certificate; either one from your own CA, or you can use the certificate that's installed on the Fortigate by default. Either way you need the client to trust the certificate or you will get browser warnings.

There is one problem with this, and that is with sites using HSTS. Most browsers supports and use this protection mechanism, if the site is enable with it. Short story, this mechanism blocks man-in-the-middle attacks, which basically is what the Fortigate is doing when you are using full inspection (proxy) of traffic.

So if you want you users to be able to watch videos on YouTube and Vimeo, you will have to disable SSL inspection on the following URLs:
googlevideo.com
vimeocdn.com

Here's a guide on how I did this on FortiOS 5.2.5.
- Go to "Security Profiles", "Advanced", and "Web Rating Overrides"
- Click the "Custom Categories" button on the top
- Create a new category (or rename one of the default custom ones that is built in) and name it "Whitelist". For convenience, you could also create two more: "Warning" and "Block". It's nice to have in case you want to override a category on a website.
- Go back to the "Web Rating Overrides" menu and click "Create New".
- Add the URLs I listed above and select the "Custom Categories" and "Whitelist". Do this for both URLs if you want both YouTube and Vimeo working.
- Go to your web filter profile and change each of the new Local Categories you made to Allow, Warning, and Block.
- Go to the "SSL/SSH Inspection" under "Policy & Objects", "Policy"
- Select you SSL profile from the list (if you have more than one)
- In the "Exempt from SSL Inspection" section, add the "Whitelist" category.

There you have it!  You can still have warning on the "Streaming Media and Download" category, and the users will get the Fortigate warning message, but be able to click proceed to watch YouTube and Vimeo videos.

This is also possible to do in FortiOS 5.0, but you will have to do it through the CLI. The guide above will work for most of the settings (except that Fortinet is moving stuff around like crazy each firmware), but you need to do the "Exempt from SSL Inspection" from the CLI. You find this under the following CLI section:
config webfilter profile
edit [your_profile_name]
config ftgd-wf
Do a "get" to see what the ID of your Whitelist category is
Also do a "show" to see what other category IDs is in exempt-ssl
copy the line with "set exempt-ssl", and add the ID of you Whitelist category at the end:
set exempt-ssl [IDs_of_other_categories] [ID_of_your_Whitelist_category]

As an ending note I want to say that there are more sites using HSTS that can cause you headache, so if you encounter any problems, try adding the URL to the Whitelist category. This will however white list the site completely, but I guess that's not an issue as you want to allow it :)

Backup of Riverbed Steelhead devices with SSH

It is possible to send commands through SSH, and with this, it is pretty easy to set up configuration backup of the Riverbed Steelhead devices.

Example:
ssh admin\@<IP or hostname> < <file with commands to run>
ssh admin\@10.0.0.15 < commands.txt

To save the output to file:
ssh admin\@<IP or hostname> < <file with commands to run> > <output file>
ssh admin\@10.0.0.15 < commands.txt > config.conf

To get the configuration, write the following in the "commands.txt" file:
enable
show configuration running

You can also do "show configuration full" to get default values in the configuration in addition to the configuration that has been added.

Other useful stuff you can add in the "commands.txt" file:
write mem - saves the configuration

show info - shows status, update, temperature, version etc

show version - shows serial, version, model, uptime, memory, CPU etc

The SSH commands will ask you for password. You can easily add an RSA key to the device so you do not need to type the password manually.

First you need to generate RSA keys, and then insert the public key into the Riverbed device by typing: 

ssh client user admin authorized-key key sshv2 "ssh-rsa your public key"

To connect with SSH with your RSA keys, use this command:
ssh -T -i private.key admin\@10.0.0.15 < commands.txt > config.conf

The "-T" option is not needed, but it solved a console error message I had.

If you do not know how to create the RSA keys, I have written it in a previous post:

Fortigate SCP backup

I also want to mention this guy for getting me on track :) He has written this with more detailed explanation than me:
Scripting the riverbed steelhead

Rancid and Fortigate - not straight forward

Today I have been working with Rancid and Fortigate. Everything seemed ok in the beginning, all my tests was working as expected.

This was until I found a problem with one of the configuration files. One of the configuration files was missing a lot of configuration. It has stopped after about 60-70 lines. At the end of the diff email, I found the following text: "\ No newline at end of file"
I am not completely sure why this Fortigate was having this problem. It might be because it has VDOM configuration. I solved this by downloading a new fnrancid and fnlogin file from the rancid git repository (https://github.com/dotwaffle/rancid-git/tree/master/bin)

After this, I was a bit skeptical as Rancid did not give any warnings that the configuration was not complete, so I looked deeper into the configuration files that Rancid had backed up. I found that all Fortigates with VDOM configuration did not have the full configuration files. It seems Rancid skips small parts of the configuration as it only get it by typing show commands in the console. I did a search for "config vdom" and "edit root" in backups, but I did not find it. It may not be a problem, but I think it will be a problem to do a complete restore. Another problem is that Rancid do not get the header of the configuration file. This will certainly cause a problem if you need a complete restore.

Header:
#config-version=FGT80C-5.00-FW-build301-141216:opmode=0:vdom=0:user=admin
#conf_file_ver=155545630586610253649
#buildno=0301
#global_vdom=1

You can of course add this header yourself, but I advice to get it right for the firmware your are restoring to. I am not sure what will happen if you get it wrong.

Because of these problems, I rather download the configuration file from the Fortigates with SCP. I have another article in my blog about this.

IKEv1 vs IKEv2

Summary:

1.IKEv2 does not consume as much bandwidth as IKEv1.
2.IKEv2 supports EAP authentication while IKEv1 doesn’t.
3.IKEv2 supports MOBIKE while IKEv1 doesn’t.
4.IKEv2 has built-in NAT traversal while IKEv1 doesn’t.
5.IKEv2 can detect whether a tunnel is still alive while IKEv1 cannot.

Check this link for more info:
http://www.differencebetween.net/technology/protocols-formats/difference-between-ikev1-and-ikev2/

iFolder on SLES 11 SP 1

After a million problems to get this to work, I found out that mono(mono.WebServer) 0.1.0.0 is (badly) needed by iFolder.

Here's the mono repo that I got this from: http://ftp.novell.com/pub/mono/archive/2.6.3/download/

It's also available for OpenSuse versions: 11.0 - 11.2

List of public IP net

I tried to find a list of all the public IP nets, but could't find any. Therefor, I made one myself :)

PS: I did not take out the lookback range (127.0.0.0/24).

0.0.0.0/5 (0.0.0.0 - 7.255.255.255)

8.0.0.0/7 (8.0.0.0 - 9.255.255.255)

11.0.0.0/8 (11.0.0.0 - 11.255.255.255)

12.0.0.0/6 (12.0.0.0 - 15.255.255.255)

16.0.0.0/4 (16.0.0.0 - 31.255.255.255)

32.0.0.0/3 (32.0.0.0 - 63.255.255.255)

64.0.0.0/2 (64.0.0.0 - 127.255.255.255)

128.0.0.0/3 (128.0.0.0 - 159.255.255.255)

160.0.0.0/5 (160.0.0.0 - 167.255.255.255)

168.0.0.0/6 (168.0.0.0 - 171.255.255.255)

172.32.0.0/11 (172.32.0.0 - 172.63.255.255)

172.64.0.0/10 (172.64.0.0 - 172.127.255.255)

172.128.0.0/9 (172.128.0.0 - 172.255.255.255)

173.0.0.0/8 (173.0.0.0 - 173.255.255.255)

174.0.0.0/7 (174.0.0.0 - 175.255.255.255)

176.0.0.0/4 (176.0.0.0 - 191.255.255.255)

193.0.0.0/8 (193.0.0.0 - 193.255.255.255)

194.0.0.0/7 (194.0.0.0 - 195.255.255.255)

196.0.0.0/6 (196.0.0.0 - 199.255.255.255)

200.0.0.0/5 (200.0.0.0 - 207.255.255.255)

208.0.0.0/4 (208.0.0.0 - 223.255.255.255)

Multicast and R&D:

224.0.0.0/3 (224.0.0.0 - 255.255.255.255)

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

Multicast:

224.0.0.0/4 (224.0.0.0 - 239.255.255.255)

R&D:

240.0.0.0/4 (240.0.0.0 - 255.255.255.255)