Tag Archives: Fortigate

Clearing sessions in FortiOS

Fortigate firewalls are stateful by design, this means that when a client behind the firewall talks to lets say Google a session is created – If all security policies are met.  Google’s return traffic can automatically come back into the client, following the same path (Session) without having to explicitly have an access rule that allows that traffic.  This is also very beneficial in security because the firewall keeps track of that session, makes sure all traffic is flowing on the session as it should, and will close the session if needed. When the session is closed Google cannot talk to our internal host anymore without following very specific rules that would allow communication from them.

With remote APs, Video streams, any many more (Specifically UDP streams) I see problems a lot with sessions getting created on the WAN (Default route) for RFC-1918 private subnets. When this happens internal clients – Maybe APs – cannot talk back to the controller or the UDP video encoder cannot find the decoder any more, but other clients can communicate with those devices just fine.

The reason this happens is that most of the time the IPSEC VPN tunnels or MPLS/E-LAN interfaces have static route assigned to them for getting to the other side subnets. If the physical interface or VPN interface drops then what routes exist in the routing table? Thats right – just the default which in turn sends all traffic even for private subnets out to the internet.  Lets take a UDP video Stream  between two locations for example -UDP never needs an acknowledgement of the traffic, so it keeps blasting traffic to the session – when the session gets created to the internet

When those interfaces or tunnels come back online all should work, and will unless traffic never stops flowing, which is where our problem lies.  When traffic tries to flow when all interface routes are down, then the only route left is the default – so the session gets created on the WAN interface.

To clear these sessions and fix the issues there are a few options.

1 – clear all sessions of the firewall

2 – create session filter and only clear the sessions you need to .

There are many other reasons to clear sessions than the reason I mentioned above.  So lets get to commands!

First you can show sessions on the firewall by using:

options1.JPG

Status will show you how many active sessions you have on the firewall and List will print out the individual sessions.

When you select list you get the following information

list1

So for this example lets check out the session created from my internal host 10.3.0.1 going to 104.197.225.108 (www.mirazon.com).

list 2

So we see that just by going to http://www.mirazon.com it opened 6 session, these are all going to the same destination IP/Port but coming from different source ports. Option 1 was we could clear all sessions from the firewall – the command to do that is:

diag system session clear

In this example, lets say I want to clear only sessions going to IP 104.197.225.108. We need to create a session filter and then clear only those. Here are the following options on creating filters

filter-1

Lots of options – one of the coolest in my opinion is matching on Protocol! But in this case lets match by destination IP.

filter-clear

Thats it! now we have cleared all sessions going to that IP.

NOTES

A few things to note – The firewall will clear out a session  if it does not see a keepalive. It will do that every 3600 seconds by default – this means if a voice call is going on through the firewall then it might close the session after 3600 seconds – this can be a big problem. The “dia system session list” is a great way to find a session and see when it will expire. Great way to troubleshoot – you can also use the GREP keyword to help find exactly what you want.

 

 

 

Advertisements

Fortigate VXLAN Encapsulation over IPSEC

VXLAN is a Layer2 overlay scheme over a Layer 3 network. VXLAN uses MAC Address-in-User Datagram Protocol (MAC-in-UDP) encapsulation to provide a means to extend Layer 2 segments across a layer3 segment. This basically means the layer2 packet gets a VXLAN header applied, then that frame gets encapsulated into a UDP IP packet and sent over to the layer3 network.

In later FortiOS 5.4 firmwares VXLAN (Virtual Extensible LAN) encapsulation was added. This is a great technology that can help connect to sites at layer2 over layer3. Something to take note of – as of FortiOS 5.6.2 – lots of improvements and enhancements to VXLAN encapsulation have been made. For example, vlan trunking works well now. Mutlicast also will traverse the VXLAN!

So far I have set this up for two different clients. Both were situations where we had to have layer 2 stretched for a certain purpose. in the last case it was to two different data centers. Below is the scenario and config of the Fortigates as well as show ARP/MAC from the Cisco switch. Fortinet has some great documentation as well on this feature (Links below).

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

http://kb.fortinet.com/kb/documentLink.do?popup=true&externalID=FD40170&languageId=

Below shows our simple layout. The red line indicates the VXLAN encapsulation path. Encapsulation only happens at Fortigate firewalls.

layout

Here is a check lists of things that are needed:

  • Create VXLAN VPN
    • Local encap-local-gw4 is the public address on the local FW
    • encap-remote-gw4 is the peer address of the other side
    • remote-gw is the peer address of the other side
  • Then create a new Switch interface
    • Add both the local network, and VXLAN-VPN interface to this switch
  • Create firewall policies allow traffic

Thoughts and observations:

  • Lowering the MTU of the VXLAN/internal interface might be a good idea. The VXLAN encapsulation adds around 50-bytes. Most Cisco documentation will mention increasing the MTU, but since we are going over the net with this, increasing MTU means lots of fragmentation.
  • No IP address on the Switch interface is needed. Actually I have seen small issues when putting an IP address on the interface.
  • In CLI use the commands below to help get broadcasts (be careful) and ARP to go across.
    • config sys int
      • edit VXLAN
        • set l2forward enable
        • set broadcast-foward enable
        • end
      • end
  • In 5.6.2 VLANs tags will pass through the tunnel

CONFIG

SIDE 1 (60D)

config vpn ipsec phase1-interface
edit “VXLAN”
set interface “wan2”
set peertype any
set proposal aes256-sha1
set encapsulation vxlan
set encapsulation-address ipv4
set encap-local-gw4 1.1.1.1
set encap-remote-gw4 1.1.1.2
set remote-gw 1.1.1.2
set psksecret password
next
end
config vpn ipsec phase2-interface
edit “VXLAN_ph2”
set phase1name “VXLAN”
set proposal aes256-sha1
next
end

config system switch-interface
edit “VXLAN-SWITCH”
set vdom “root”
set member “internal1” “internal2” “VXLAN”
next
end

Lets look at the Switch in the gui

60d-switch

Then lets check out the Firewall Policies

firewall policies

SIDE 2 (60E)

config vpn ipsec phase1-interface
edit “VXLAN”
set interface “wan1”
set peertype any
set proposal aes256-sha1
set encapsulation vxlan
set encapsulation-address ipv4
set encap-local-gw4 1.1.1.2
set encap-remote-gw4 1.1.1.1
set remote-gw 1.1.1.1
set psksecret password
next
end
config vpn ipsec phase2-interface
edit “VXLAN_ph2”
set phase1name “VXLAN”
set proposal aes256-sha1
next
end

Lets look at the Switch in the Gui

60-e interface

Next lets check out the Firewall Policies

fw-60e

 

Testing

First make sure the VPN is up and working. Then a simple ping test between two devices on the same subnet will be enough to make sure things are working. TCP is always the best way to test . You can also check and make sure that the ARP/MAC address tables on each side show something on the remote side. For example the below shows the ARP/MAC of the Cisco 3650 switch at the Datacenter side (60D).

Datacenter-Stack#show arp

Protocol  Address          Age (min)  Hardware Addr   Type   Interface

Internet  192.168.19.21           0   000c.291c.b2a5  ARPA   Vlan1

 

Internet  192.168.19.51           0   000c.2918.b8be  ARPA   Vlan1  – 19.51 lives behind the 60E

Datacenter-Stack#show mac address-table
Mac Address Table
——————————————-

Vlan Mac Address Type Ports
—- ———– ——– —–
1 000c.2918.b8be DYNAMIC Gi1/0/1  — Fortinet 60D is connected to gig 1/0/1

 

Conclusion

Thats it! VXLAN is an open source protocol that is a great datacenter technology. Fortinet makes it very easy to get this up and going within a few minutes. EB

FGT traffic shaping in 5.4 – Per Policy/shared options

The best docs are always at docs.fortinet.com

Fortigate traffic shaping is awesome, lots of options and it all works really well. Going from 5.2 to 5.4/5.6 is quite different due to the creation of policies changing from within the firewall policy, to their own section. Either way, they all work great.

I did notice at least in 5.4 that the option to change how a policy is used do not seem to be in the GUI. Previously there were two options – “Per Policy”, and “all policies using this shaper”. Selecting “all policies using this shaper” would have all policies using that shaper object to share the guaranteed or Max bandwidth settings between all policies using that shaper. Selecting “Per Policy” allows you to dedicate those same settings to each policy referencing the shaper object.

Which gets to my point, in 5.2 you had the options below. Notice the options about how to apply the shaper.

5-2

In 5.4.5 at least notice that they are gone. Of course, if you upgraded from 5.2 the options are there.

5-4

So as with everything that does not show up in the GUI – you know it is in CLI. So I dropped down to CLI to check if the settings are still there. By editing the shaper, and using the “get” command I could see all settings and their values the policy had to offer. As I thought the option “Per-Policy” is there with the default settings of disabled. So by default, all Shaper policies have  settings shared between different traffic policies referencing that shaper.

edit-shaper

So in this case, I want to give the same percentage of bandwidth to each of the traffic shaper policies referencing my shaper object. So I will modify that option.

set-options

Now, in the GUI lets check that policy again –

after-changes

Awesome, now we have the actual options to change.

Fortigate 5.4 – Named policies

Fortigate has done a great job with the 5.4 firmware. Its a big change from 5.2 but once you get going with it, you will find things are structured very well. For example the “Monitor” category is a great way to get everything you need, instead of going through each individual category.

One feature of 5.4 that really “Grinds my gears” is the named policy feature. The feature itself is awesome, great way to put in a name on a policy such as “Students to internet”.. etc.  But, they make it mandatory to put in a name by default. What’s so aggregating about this is that if you upgrade to 5.4 from 5.2 all of your policies are unnamed, so when you modify one of those existing policies you HAVE to put in a name. The following will show how to turn that feature off, so it is not mandatory you put in a name. You still can, just don’t have to.

Below you will see what happens when you try to create that policy , and the the feature has not been disabled. You get the “This field is required.” error. It will not let you create or modify the policy until that is filled in.

rule-creation-error

To disable this feature, go to system-Feature select- then check “Allow unnamed policies”. Once you press Apply this will let you bypass the mandatory name feature.

services

Fortigate: GRE tunnel creation

A GRE (Genereic Routing Encapsulation) is a tunneling protocol that allows data to be encapsulated and sent over a simulated point-to-point link. The beauty of it is that it will encapsulate many different types of traffic and De-encapsulate it on the other. This basically means any traffic sent to the tunnel interface will be stuffed it in a envelope and sent to the remote gateway, removed from the envelope,  and forwarded normally. The network which the traffic is being routed across  only sees GRE and not the individual IP header. A GRE tunnel can be used with or without IPSEC for encryption. This blog entry creates a tunnel WITHOUT IPSEC.

This is not only a one of the only ways to get Routing updates/traffic such as OSPF across a IPSEC VPN, but also is a wonderful troubleshooting option.I have seen this be a great troubleshooting tool when an MPLS might be blocking traffic.

Recently I have utilized a GRE tunnel  to tunnel all multicast traffic across a MPLS network that does not support multicast. By tunneling all the Mulicast data, the MPLS only saw GRE packets and the multicast streams worked great.

In this post I will demonstrate how to create a GRE tunnel between two Fortigate firewalls. Traffic will then be encapsulated from the source and de-encapsulated and forwarded normally on the remote end point. Most of the GRE configuration within the Fortigate is CLI only and not something that can be configured in the GUI.

Steps needed

  • Create System GRE tunnel, Assign local and remote gateways (WAN IPs)
  • Modify system interface GRE settings and assign local/remote tunnel IPs (Tunnel IPs)
  • Create Firewall policies to allow traffic
  • Create routes to remote side of the tunnel , and select GRE tunnel as destination interface
  • Test

The process is relatively straight forward and simple. First we need to create our GRE tunnel. The two sites we will be creating the tunnel on are Site-A, and Site-B.

Here is an overview of the network

GRE-overview

Site A

CLI commandsconfig system gre-tunnel
edit “GRE-to-SITEB”
set interface “WAN1”
set remote-gw 2.2.2.1    — Remote firewall WAN IP
set local-gw 1.1.1.1          — Local FW WAN1 IP
next
end

config system interface
edit “GRE-to-SiteB”
set vdom “root”
set ip 192.168.254.1 255.255.255.255    — Local Tunnel IP
set allowaccess ping
set type tunnel
set remote-ip 192.168.254.2                  — Remote Tunnel Endpoint IP
set snmp-index 65
set interface “WAN1”
next
end

Route CreationGRE-overview.JPG

Now we can create the static route pointing my remote traffic (10.2.2.0/24) through the GRE-to-SiteB GRE tunnel.

Route-SiteA

Firewall Policy creation

Next we need to create the Firewall policies allowing traffic from the GRE-Tunnel and to the GRE-Tunnel from the LAN interface or whichever interface your traffic originates on.

Policy-SiteA

 

SITE B

GRE Tunnel creation

config system gre-tunnel
edit “GRE-to-SITEA”
set interface “wan1”
set remote-gw 2.2.2.1
set local-gw 1.1.1.1
next
end

config system interface
edit “GRE-to-SITEA”
set vdom “root”
set ip 192.168.254.2 255.255.255.255
set allowaccess ping
set type tunnel
set remote-ip 192.168.254.1
set snmp-index 8
set interface “wan1”
next
end

Route Creation

Now we can create the static route pointing my remote traffic (10.1.1.0/24) through the GRE-to-SiteA GRE tunnel.

Route-SITEB

Firewall Policy creation

Next we need to create the Firewall policies allowing traffic from the GRE-Tunnel and to the GRE-Tunnel from the LAN interface or whichever interface your traffic originates on.

Policy-SiteB

That should be it.

Now lets see if we can ping across our tunnel. As shown below pings work great! Pinging both the tunnel interface and across the tunnel are great ways to check if this tunnel is actually working. Odds are if you have enabled ping on the tunnel interface, and cannot ping it from the other side then the tunnel is not working. Also, check the Firewall policy count to make sure it is increasing with traffic – if so everything is working .

site-a-pings

site-a-count

 

Thanks!

Fortigate – Changing outbound nat IP with IP Pools

Sometimes it is necessary to change IP address used to talk with the internet that the internal client is using. For instance it is always important to make sure your SMTP server is using the same outbound IP used for inbound traffic. I have seen this cause a good many mail servers to be blacklisted by ISPs. In the following entry we will change the IP the client is using for outbound nat.

This technique has many awesome benefits, you can nat into this IP (IP pool) only when going to a certain destination.. etc. For example, if you had to change your source IP when accessing a destination across a VPN tunnel. That example might be very important in a medical field where I have found you almost always have to nat your private traffic to a public address when accessing the VPN hosts.

The internal client address is 10.64.16.10, external IP is 1.1.1.1. In this example I only want this one internal client to be natted out of 1.1.1.1

So we have to create a Virtual IP pool . We create the Virtual IP pool by going to Policy and objects – objects – IP Pools

IP pool-create

We then can setup the pool. Notice the options

– Overload allows PAT, so many ip addresses, to one public.
– One-to-One allows one IP to that public IP
– We also have the option to nat into a Public Range of addresses

We also want this device to answer VIA Arp for 1.1.1.1

Now lets create our IPv4 Policy to allow our private IP address to be allowed to the internet (WAN1) and to be natted VIA this IP pool. I created the address object for my private host already.

policy-creation

So after creating our IPV4 policy, we have one thing left to do – make sure this is one of our first policies hit when 10.16.64.10 tries to access the internet. So lets make sure its at the top of our list, or at least above our default nat rule.

above

That’s it! if you now go to a site such as ipchicken.com or whatismyip.com you will see 1.1.1.1 if you are coming from 10.16.64.10.

Fortinet – Creating vlans for devices directly connected to device

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

create-interface

Now lets put in the needed info.

Interface

The below shows the status of the interface:

show-int

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.

Ruckus.JPG

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.

 

Blocking geographic regions in Fortigate 5.4

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.

Monitor-Countries

 

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.

create address

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

China

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

Country-Group

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

block-policy

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.

 

 

Foritgate 5.4- Changing the interface theme

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:

color-1

Changing the theme to Melongene

color-2