Zones - members not available as src or dest interface

[riaanb]

Hi I have configured a zone with two IPSec tunnels as its member. Both tunnels route traffic to the same remote FTG, one via an expensive link and the other via ADSL. I would like to apply different traffic prioritisation profiles to traffic in each tunnel for one type of traffic. But, it seems that since creating the zone I can not use either member of the zone as a destination interface in a firewall policy. Is there a way around this? I do not want to duplicate all my rules - Zones are a good solution for this. Thanks

[ede_pfau]

Maybe you' ve overlooked the priorisation you can achieve by using different weights (distance/priority) on the static routes to the VPNs. If one of the routes has a smaller distance or a lower priority then it will be preferred over the other. This is the classical failover scenario with 2 outbound interfaces (only normally you' d use it on WAN ports, not VPN ports). As Bob has pointed out, even if both VPN interfaces are members of a zone you can still set their priority independently in the Interface setup. Of course you should additionally configure both interfaces for Dead Gateway Detection at the interface level, i.e. set ping targets. This way, if an interface fails (the tunnel goes down) the static route to it will quickly be removed from the routing table so that traffic won' t be sent to Nirwana.

[riaanb]

The problem with using static routes is that my requirement is for inter-branch traffic. So, there are two static routes between CPT and JNB - one via the " BL" VPN and the other via the " DSL" VPN. The DSL VPN has a a higher weight than the BL VPN. Are you saying I could have a route for 192.168.10.0/24 via both VPN interfaces and specific routes for 192.168.10.100/24 with different weights - where 192.168.10.100 is a VOIP PBX which I want to handle differently depending on which VPN is my default route between the branches? How does this allow me to prioritise RDP traffic over SIP traffic when we are on the failover VPN between the branches? PS - BL is a MPLS network between the two branches the DSL link is highly contended and inexpensive.

[riaanb]

Just a quick note to say thanks for all the responses so far.

[ede_pfau]

Now, this is 2 pairs of shoes: preference of a (less costly) route over a backup route, and prioritisation of one service over others. The first goal can be achieved with routes which have different weights. Of course you can specify a host route (in your case 192.168.10.100/32). If placed before the general route for that subnet it will be followed if traffic to that destination is to be routed. The means to achieve traffic prioritisation is the traffic shaper option available in firewall policies. TS places services into 3 QoS categories (low/medium/high). You separate the services by defining specific policies. Then you are able to assign TS to them, with different QoS classes. The FortiOS implementation is not very sophisticated IMHO but it works. As this is a tricky subject I recommend the FortiOS Handbook (and maybe the Cookbook also) for further reading.

[nothingel]

riaanb, Have you considered setting an outbound bandwidth on each VPN' s respective interface? The " outbandwidth" parameter will define an absolute max rate for the Fortigate to use. Then, within your firewall policies, set the priority as either high, medium, or low and these priorities will be honored when congestion begins (thanks to the outbandwidth parameter). Without outbandwidth, Fortigate probably won' t experience congestion because its physical link speed to the DSL modem or MPLS is 100mbps or higher. As long as the Fortigate physical interfaces don' t experience congestion, they' ll pass the traffic immediately to the next device where it will either be transmitted or buffered. Your MPLS may have its own traffic prioritization capabilities and the DSL modem may offer something too but since the traffic has already been encrypted by the Fortigate, it may be hard to take advantage of those shaping options. Don' t forget to inspect the default priority that' s used unless explicitly defined. Some releases defaulted to HIGH whereas I think 4.3 defaults to MEDIUM. I tend to set the default traffic to LOW so that I can selectively enable other traffic to be medium or high.

 config system global
     set tos-based-priority low
 end
 

Using the above technique with specific " outbandwidth" parameters for each of your VPN interfaces, you might still be able to use zones as long you' re not concerned with an interface-specific bandwidth rate for each policy. High/Medium/Low should be honored as congestion occurs. Don' t forget to set " outbandwidth" somewhat below the true outbound speed so that traffic doesn' t build up in the DSL modem' s buffers, thus creating latency. Additionally, you may want to consider the " monitor-phase1" parameter for your DSL vpn phase1 interface. This tells the Fortigate to only activate the secondary tunnel if the primary tunnel has failed and -- this is the best part IMHO -- it automatically tears down the backup tunnel when the primary is restored. Otherwise, if both are active simultaneously, you may find that the slower DSL tunnel is used more than you think. Sessions don' t " fail back" to the primary unless the backup link dies. It' s quite possible that others may disagree with the use of " monitor-phase1" but it' s been very useful and reliable in my experience.

[ede_pfau]

A good explanation around the subject " traffic shaping" , where Traffic Shaper, ToS, " outbandwidth" all belong to. To really take advantage of it I still recommend reading up the relevant documentation to get a picture of how these details work together. The " monitor-phase1" parameter was introduced when interface-based VPNs came up (IMHO) and it' s the way to go for failover tunnels. Consider the case when streams of traffic go across a tunnel like a prolonged RDP session, or SNMP: the routing engine will only take a decision when the first packet of a session has to be routed. Once in the routing table, no more lookups are done (for efficiency). Say the FGT already uses a backup VPN tunnel. If in the meantime the primary tunnel comes up again a ' better' route is entered into the routing table, but existing sessions still will follow the old path across the backup tunnel. This will only change when either the session times out or the backup path goes down. With the " monitor-phase1" parameter set the state of the monitored tunnel is checked periodically and the tunnel is torn down if the primary is up again.

[riaanb]

Thanks for the great tips Ede and Nothingel. I have defined outbandwidth - but I suspect that this is something that is easy to miss, not much is made of it in the documentation, it is treated as an optional step. Nothingel, the devices on my LAN does not use TOS to set priority thus I have not changed anything from the default regarding that. Does this affect Fortigate' s High/Medium/Low prioritisation? I thought it was an either or situation - either use TOS or use H/M/L in firewall policies. Thanks for the tip re: monitor_phase1. I have implemented this now. -- riaan Fortigate 80c - 4.0 MR2 patch 7