SSL VPN and dual WAN / default routes

[#1]

I' ve got a problem with my SSL VPN connections... I' m running a Fortigate 500A, with two WAN links (T1, DSL) and one internal network link. SSL VPN worked fine until I added the 2nd WAN link, and added a 2nd default route to allow web load sharing between it and the pre-existing T1. Both static routes are: 0.0.0.0/0.0.0.0 > T1 router IP 0.0.0.0/0.0.0.0 > DSL router IP After tweaking route order and priority, I was able to get web traffic to prefer the DSL route as I wanted, without having to use any policy routes. But why is this breaking the return traffic to my SSL VPN tunnel clients? They can connect via the browser interface, but then are dropped within 30 secs, with no traffic ever received back from the firewall. Obviously, it' s being routed out the wrong gateway (DSL). Any ideas?

[abelio]

After tweaking route order and priority, I was able to get web traffic to prefer the DSL route as I wanted, without having to use any policy routes. But why is this breaking the return traffic to my SSL VPN tunnel clients? They can connect via the browser interface, but then are dropped within 30 secs, with no traffic ever received back from the firewall. Obviously, it' s being routed out the wrong gateway (DSL). Any ideas?

" Re-tweak" again to ensure that: . T1 priority static route parameter is greater (lower value) than dsl, to ensure SSLVPN going to and back through T1 . use policy routes to route webtraffic throughout DSL Protocol = 6 (TCP) Incoming IF = internal Source = as required Destination= as required Destination Ports = 80 Force traffic to ->DSL iface You' ll need policies routes to manage traffic in a dual-wan scenario.

[#3]

" Re-tweak" again to ensure that: . T1 priority static route parameter is greater (lower value) than dsl, to ensure SSLVPN going to and back through T1

There is my problem...I HAVE given route priority to the DSL gateway, which is what is re-routing return VPN traffic. Can I assume then ALL return traffic (ie FTP server or web server traffic) will return down the highest priority (lower value) gateway as well?

. use policy routes to route webtraffic throughout DSL Protocol = 6 (TCP) Incoming IF = internal Source = as required Destination= as required Destination Ports = 80 Force traffic to ->DSL iface

I was leaving the ' Protocol' field blank, but was using dest port ' 80' to try and redirect web traffic to the DSL gateway, but for some reason it interferes with my users (10.1.1.0) routing correctly to my VOIP server / subnet (10.2.1.0) , which is defined as static route on the Fortigate.

[abelio]

There is my problem...I HAVE given route priority to the DSL gateway, which is what is re-routing return VPN traffic.

The important thing here is distinguish between the two wans with the priority parameter and establish the VPNSSL choosing the one with higher priority (lower value), dsl or T1 ( you choose).

Can I assume then ALL return traffic (ie FTP server or web server traffic) will return down the highest priority (lower value) gateway as well?

only if you don' t set route policies to manage that traffic

I was leaving the ' Protocol' field blank,

Don' t; work with 6 for TCP traffic, 17 for UDP traffic ans so on.

but for some reason it interferes with my users (10.1.1.0) routing correctly to my VOIP server / subnet (10.2.1.0) , which is defined as static route on the Fortigate.

In my experience, policies routes supersedes static routes settings. Define a specific new policy route for that VOIP device and re-try Hope it helps.

[#5]

The important thing here is distinguish between the two wans with the priority parameter and establish the VPNSSL choosing the one with higher priority (lower value), dsl or T1 ( you choose).

I cleared out all static routes, and recreated them in the CLI. The T1 was the default route (" edit1" ), and the DSL was secondary (" edit2" ). I did not apply ' priority' because the edit order seems to accomplish the same thing---therefore I am now doubly confused about the function of the ' priority' parameter. Then, I created two policy routes: Protocol 6 internal interface internal subnet dest IP anywhere dest port 80 to 80 force to DSL gateway Protocol 6 internal interface internal subnet dest IP anywhere dest port 443 to 443 force to DSL gateway ...to route all http and https traffic to the DSL gateway. It works. Somehow, my 10.2.1.0 VOIP subnet routing issues seem to have vanished. Perhaps it was leaving the protocol field blank on my initial web traffic policy routes which was rerouting EVERYTHING out the DSL gateway? Thanks very much for your help Abel---your insight gave me the confidence boost I needed to know I was going about this the more-or-less correct way. Still, I' d like a better understanding of the use of setting static route ' priority' .

[abelio]

I cleared out all static routes, and recreated them in the CLI. The T1 was the default route (" edit1" ), and the DSL was secondary (" edit2" ). I did not apply ' priority' because the edit order seems to accomplish the same thing---therefore I am now doubly confused about the function of the ' priority' parameter.

extracted from Release Notes pdf fortios 3.0 version: " Prior to FortiOS v3.00 MR1, if two equal cost static routes to a destination were configured, the FortiGate made a routing decision based on the sequence number - the order in which they were entered in the CLI or Web UI. FortiOS v3.00 MR1 removes this restriction by adding a priority argument to static routes. The priority argument now is responsible for breaking a tie between two equal cost routes - the lower the priority the higher the preference"

Still, I' d like a better understanding of the use of setting static route ' priority' .

check also this forum thread, there' s a good paragraph from TAC' s guy named Stephane: http://support.fortinet.com/forum/tm.asp?m=31599&appid=&p=&mpage=1&key=&language=single&tmode=&smode=&s=#31670