OVERVIEW

On Fortigate firewalls  SIP  Application Layer Gateway (SIP ALG) is enabled by default. This will cause problems with SIP VoIP phones registration and call processing.

We observed following problems when SIP ALG is active on Fortigate firewalls:

1. SIP phones are unable to register on a remote phone system
2. Calls are dropped after 5-15 min
3. Incoming phone calls are not reaching the SIP phone(s)

RESOLUTION

Backup configuration of your firewall before making any changes

Run following commands from Fortigate firewall CLI

config system settings
set sip-helper disable
set sip-nat-trace disable
set default-voip-alg-mode kernel-helper-based
end

IMPORTANT Note: Since version 6.2.2. the CLI command is different:

config system settings 
set default-voip-alg-mode kernel-helper-based
set sip-expectation disable
set sip-nat-trace disable
end 

If you see an error while entering “set default-voip-alg-mode kernel-helper-based” , just ignore it.

Next we need to locate SIP entry in session helper list and delete it

config system session-helper
show

Scroll down until you see an entry for SIP, in our example it was number 13 but this may be different depending on model and software release. Now execute  following commands:

delete 13
end

The last set of commands disables processing of RTP protocol on the firewall

config voip profile
edit default
config sip
set rtp disable
end
end

Normally Fortigate firewalls do not require a reboot when you change configuration, but , it seems, in this case we need reboot it to activate session helper changes.

Last step – restart or power cycle all your SIP phones and devices.

There are two modes available to you when configuring HA for a FortiGate Cluster, Active-Active or Active-Passive. The section below outlines the main differences between the two modes.

Active-Active

• Load balances UTM (Antivirus, IPS, Web Filtering, etc.) packets between all cluster units. This can lead to overall improvement in UTM performance by sharing the processing load among the cluster units.
• The following sessions are processed by the primary unit & not load balanced: UDP, ICMP, Multicast, Broadcast, VoIP, IM, P2P, IPSEC VPN, HTTPS, SSL VPN, HTTP Multiplexing, SSL Offloading, WAN Optimization, Explicit Web Proxy & WCCP sessions.
• TCP traffic is not load balanced by default. It is recommended to test this setting in your environment as it may degrade performance rather than increase. The overhead required to load balance TCP traffic is as much as just processing it.
• If the primary unit fails, the other unit negotiates and becomes the primary unit. The remaining unit continues to function as the primary unit, maintaining the HA virtual MAC address for all of its interfaces.
• Session failover is provided for all TCP sessions except UTM, UDP, ICMP, Multicast & Broadcast sessions. This requires Session Pickup to be turned on.

Active-Passive

• All traffic is processed by the primary FortiGate unit.
• Provides Hot Standby failover protection
• Does not process communication sessions, the configuration is synchronized with the primary unit.
• Can be a more robust session failover solution than Active-Active by handling the failover of UDP, ICMP, Multicast & Broadcast sessions better. This is very condition specific. The cluster does not specifically support failover of these packets.

Recommendations

• Utilize Active-Active mode if you are utilizing UTM features.
• Utilize Active-Passive mode if you are not utilizing UTM features.
• Utilize Session Failover to maintain TCP, SIP & IPsec VPN sessions after a failure

I recently clustered a pair of Fortigate 240Ds in an Active/Active configuration and wanted to uplink the Fortigate firewalls to my Cisco 3750-Xs using a pair of 4 port LACP/Port Trunks. Now given that this would be cross vendor LAG I thought I’d document the settings required in order for the Fortigate to bring up the link successfully.

Ok, lets start with the Fortigate:

Configuration is very simple, and Fortinet have kindly made this easier in the later versions of FortiOS giving you a drop down which allows you to select ‘802.3AD Aggregate’ as your chosen interface type. After setting that, you can simply add in the ports you’d like to bond.

Now on to the Cisco 3750-Xs:

I’ll be carrying multple VLANs across my LAG so my config may be slightly different to yours, but here goes.

First, create your Port-Channels on the switch:

interface Port-channel2
description FW1-FGT-Top
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 200,201,202,203
switchport mode trunk
storm-control broadcast level 20.00
storm-control multicast level 20.00
storm-control action shutdown
storm-control action trap
!

interface Port-channel3
description FW1-FGT-Bottom
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 200,201,202,203
switchport mode trunk
storm-control broadcast level 20.00
storm-control multicast level 20.00
storm-control action shutdown
storm-control action trap
!

Now configure your ports, and add them to the channels:

interface GigabitEthernet1/0/1
description FW1-P1-Top
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 200,201,202,203
switchport mode trunk
storm-control broadcast level 20.00
storm-control multicast level 20.00
storm-control action shutdown
storm-control action trap
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
channel-group 2 mode active
!
interface GigabitEthernet1/0/2
description FW1-P1-Top
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 200,201,202,203
switchport mode trunk
storm-control broadcast level 20.00
storm-control multicast level 20.00
storm-control action shutdown
storm-control action trap
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
channel-group 2 mode active
!
interface GigabitEthernet1/0/3
description FW1-P1-Top
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 200,201,202,203
switchport mode trunk
storm-control broadcast level 20.00
storm-control multicast level 20.00
storm-control action shutdown
storm-control action trap
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
channel-group 3 mode active
!
interface GigabitEthernet1/0/4
description FW1-P1-Top
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 200,201,202,203
switchport mode trunk
storm-control broadcast level 20.00
storm-control multicast level 20.00
storm-control action shutdown
storm-control action trap
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
channel-group 3 mode active
!
interface GigabitEthernet2/0/1
description FW1-P1-Top
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 200,201,202,203
switchport mode trunk
storm-control broadcast level 20.00
storm-control multicast level 20.00
storm-control action shutdown
storm-control action trap
spanning-tree portfast
spanning-tree bpduguard enable
channel-group 2 mode active
!
interface GigabitEthernet2/0/2
switchport trunk allowed vlan 200,201,202,203
switchport mode trunk
storm-control broadcast level 20.00
storm-control multicast level 20.00
storm-control action shutdown
storm-control action trap
spanning-tree portfast
spanning-tree bpduguard enable
channel-group 2 mode active
!
interface GigabitEthernet2/0/3
description FW1-P1-Bottom
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 200,201,202,203
switchport mode trunk
storm-control broadcast level 20.00
storm-control multicast level 20.00
storm-control action shutdown
storm-control action trap
spanning-tree portfast
spanning-tree bpduguard enable
channel-group 3 mode active
!
interface GigabitEthernet2/0/4
description FW1-P1-Bottom
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 200,201,202,203
switchport mode trunk
storm-control broadcast level 20.00
storm-control multicast level 20.00
storm-control action shutdown
storm-control action trap
spanning-tree portfast
spanning-tree bpduguard enable
channel-group 3 mode active
!

The key config for the port channel / LAG to come up is ensure that the ‘channel-group’ mode is ‘active’, this ensures that the channel is using LACP, aka 802.3AD.

Check your link has come up on the Fortigate

and then Cisco end via, ‘show interfaces port-channel x’.

I recently set up 2x Fortigate 200B units to run in HA Active/Active mode, this posed a number of challenges:

1. HA doesn’t work if any interfaces use PPPoE or have an address assigned via DHCP
2. How do I effectively split our network communications between both units?

Challenge 1

The main problem was that both the internet connections used PPPoE for address assignment and auth – I had taken care of one of these previously as it was a simple ADSL link our Fortigate units didn’t allow for so we had a Cisco 837 box to terminate the PPPoE on a virtual interface and unnumber the static external IP to an internal interface. (Read: I used it as a proxy of sorts to get round hardware limitations).

We had done it before for an ADSL link so I follow the same methodology for our fiber link, except, with a faster Cisco box – in the form of a very simple, cheap Cisco 1841. Loaded the latest broadband firmware onto it (c1841-broadband-mz.151-4.M7.bin) and did the following:

• Assigned f0/0 to be our internal “gateway” address (assigned router address from BT/Zen in the static IP block)
• Assigned f0/1 to be our external WAN facing address and act as PPPoE client (no ip address)
• Created a virtual Dialer interface Dialer1 to act as PPPoE terminator
• Unnumbered Dialer1‘s IP against f0/0
• Set mtu to 1492 on Dialer1
• Enable ip cef
• Set adjust-mss to 1452 on f0/0 Extremely important to match frame size to ISP

Download full (nulled) config here.

With that out of the way I then set up our 200B to use this IP as its gateway (via static route 0.0.0.0/0.0.0.0 to go out [router address assigned to f0/0]).

A static route was used as I can set priorities on these and give our fiber link a higher priority than the ADSL meaning we will always use the fiber link unless it breaks, when it fails over to ADSL.

The previously configured PPPoE WAN link was changed to be “manual mode” and assigned it the desired public IP:

This then left me in a position where I could configure our 200B’s to use HA as now no interfaced relied on DHCP or PPPoE for addressing.

Challenge 2

“How do we effectively split our network communications between both units?”

This was considerably simpler than the first problem I came across – the answer is get a Gb switch – I had a Cisco 3560-X 24P-L to work with.

I split the ports into groups of 4 ports on VLANs (a separate untagged VLAN for each usable interface on the Fortigate) this gave me:

• 1x input port
• 1x output port to fw-a
• 1x output port to fw-b
• 1x extra port for maintenance access

Download full (nulled) config here.

Hence the groups of 4, if you had 3x or even 4x Firewalls in A/A HA then you would need 5 and 6 ports per VLAN respectively.

My show vlan output looked like this (note I am using jumbo frames):

Cisco-3560X-200B-HA#sh vlan

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    
2    lan                              active    Gi0/1, Gi0/2, Gi0/3, Gi0/4
3    mgmt                             active    
4    iscsi                            active    
5    phones                           active    Gi0/5, Gi0/6, Gi0/7, Gi0/8
6    wifi                             active    Gi0/9, Gi0/10, Gi0/11, Gi0/12
7    microwave-wan                    active    Gi0/13, Gi0/14, Gi0/15, Gi0/16
100  adsl                             active    Gi0/17, Gi0/18, Gi0/19, Gi0/20
101  fiber                            active    Gi0/21, Gi0/22, Gi0/23, Gi0/24
1002 fddi-default                     act/unsup 
1003 token-ring-default               act/unsup 
1004 fddinet-default                  act/unsup 
1005 trnet-default                    act/unsup 

VLAN Type  SAID       MTU   Parent RingNo BridgeNo Stp  BrdgMode Trans1 Trans2
---- ----- ---------- ----- ------ ------ -------- ---- -------- ------ ------
1    enet  100001     1500  -      -      -        -    -        0      0   
2    enet  100002     9000  -      -      -        -    -        0      0   
3    enet  100003     9000  -      -      -        -    -        0      0   
4    enet  100004     9000  -      -      -        -    -        0      0   
5    enet  100005     9000  -      -      -        -    -        0      0   
6    enet  100006     9000  -      -      -        -    -        0      0   
7    enet  100007     9000  -      -      -        -    -        0      0   
100  enet  100100     9000  -      -      -        -    -        0      0   
101  enet  100101     9000  -      -      -        -    -        0      0   
1002 fddi  101002     1500  -      -      -        -    -        0      0   
1003 tr    101003     1500  -      -      -        -    -        0      0   
1004 fdnet 101004     1500  -      -      -        ieee -        0      0   
1005 trnet 101005     1500  -      -      -        ibm  -        0      0

All that needed to be done was plug the input ports into its respective VLAN and then take a cable to each 200B from each VLAN, effectively meaning each 200B could communicate with each input, easy.

In part 2 we will talk about setting up the Fortigate units themselves for HA and the proper procedure to employ for this.

Fortigate units (the big ones at least) come configured in what is called “switch mode” meaning it groups a number of interfaces together and makes them act as a switch, serves DHCP over these interfaces, etc.

Most companies don’t like to use this – instead if we want to up our throughput for a given zone we’d create an 802.3ad aggregate link out of 2 or more of the interfaces.

Disabling switch mode isn’t as straight forward as putting the one command in, there are two factors you need to consider:

1. Are you serving DHCP over this switch interface?
2. Have you got any policies relating to this interface?

If the answer is “yes” to either of these you need to do the following or you will see one of “Interface switch is in use” or “Interface internal is in use” or “Entry is used” later on:

Delete the DHCP server relating to it (either in the GUI as below):

Or you can do it in the CLI:

fw-a # config sys dhcp server
fw-a (server) # show <look at list and find the entry number relating to your interface>
fw-a (server) # delete [entry number here]
fw-a (server) # end

Next you need to delete all policies relating to the interface again, this can be done in the GUI via Policy -> Policy -> Policy and delete all policies associated with that interface. Again, it can be done with the CLI:

fw-a # config firewall policy
fw-a (policy) # show <look at list and find the entry number(s) relating to your interface>
fw-a (policy) # delete [entry number here]
fw-a (policy) # end

Once all the switch mode interface’s related objects are deleted then we can change the global mode from switch to interface via CLI:

fw-a # config sys global
fw-a (global) # set internal-switch-mode interface
fw-a (global) # end
Changing switch mode will reboot the system!
Do you want to continue? (y/n) y

The box will reboot and you’ll have a host of new interfaces to use as you like.

N.B: Some boxes are awkward and will require you to deleted the virtual hardware/software switch that is created it you still can’t see the individual IFs run the following commands:

configure system virtual-switch
delete {interface name e.g. lan, internal}

If you are still having difficulty you can run the following to find any remaining related entries to the interface:

diagnose sys checkused sys.interface.name {interface name e.g. lan, internal}