SSL VPN and dual WAN / default routes

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.

" 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.

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' .