Route All Internet Traffic Out WAN2

[BWiebe]

We have a firewall currently configured with a number of VPN tunnels in interface mode, linked to WAN1 and we have policies allowing traffic out WAN1 and out WAN2 from internal networks.  WAN1 and WAN2 are set with equal distance in their route and different priorities.

We'd like to route ALL internet traffic out WAN2 and leave WAN1 for some future use.

We tried using policy route for the 0.0.0.0/0.0.0.0 destination sourced from the internal VLANs forcing out WAN2, but this causes some issues with VPN traffic.  Specifying only certain ports works better, but doesn't necessarily route all internet-facing traffic.  I've had some success with this in the past, but it seems to be causing havoc with traffic in firmware 5.2.1, to whit, some traffic that should only traverse the VPN tunnels, was failing.  I tightened up the policies (as I hadn't created them) and wherever 'all' was used for an internal VLAN, I changed it to an address object referencing said VLAN (this is my SOP, usually).  But that didn't help.

For now - I suggested/implemented a flip in priority and made WAN2 lower priority than WAN1 and confirmed this doesn't seem to impact the traffic overall - but I'm looking for alternatives.  Note - the site isn't currently live, so we do have some time to test/change things.

One possibility I thought of was, since we're effectively already configured as ECMP, setting spillover to 0 on WAN2 which effectively should move all internet traffic out WAN2 and leave the priorities, etc, alone.

Any other alternatives I haven't thought of?

Thanks!

[Camshaft007]

I'm sort of in the same boat as well. I have all of my internal users going through WAN_1 and our WiFi_guest users (specific vlans) are going out WAN_2 via Policy Route(s). This has worked for the most part, but am now getting notified the users with WiFi devices can no longer access their email. Policy 60 (Screenie attached): Internal (Zone) - External (Zone) Guest_WiFiNets==>Destination:ALL==>Schedule:Always==>Service:ALL Flow Report: id=13 trace_id=1 func=print_pkt_detail line=4307 msg="vd-root received a packet(proto=6, 10.1.142.6:53807->68.114.188.72:25) from 10G_Agg. flag , seq 4188815579, ack 0, win 65535" id=13 trace_id=1 func=init_ip_session_common line=4463 msg="allocate a new session-07627c64" id=13 trace_id=1 func=vf_ip4_route_input line=1595 msg="Match policy routing: to 1.1.1.1 via ifindex-54" id=13 trace_id=1 func=vf_ip4_route_input line=1605 msg="find a route: flags=00000000 gw-1.1.1.1 via WAN2_Agg" id=13 trace_id=1 func=__iprope_tree_check line=534 msg="use addr/intf hash, len=16" id=13 trace_id=1 func=fw_forward_handler line=537 msg="Denied by forward policy check (policy 60)"

[BWiebe]

Camshaft007 wrote:

I'm sort of in the same boat as well. I have all of my internal users going through WAN_1 and our WiFi_guest users (specific vlans) are going out WAN_2 via Policy Route(s). This has worked for the most part, but am now getting notified the users with WiFi devices can no longer access their email. Policy 60 (Screenie attached): Internal (Zone) - External (Zone) Guest_WiFiNets==>Destination:ALL==>Schedule:Always==>Service:ALL Flow Report: id=13 trace_id=1 func=print_pkt_detail line=4307 msg="vd-root received a packet(proto=6, 10.1.142.6:53807->68.114.188.72:25) from 10G_Agg. flag , seq 4188815579, ack 0, win 65535" id=13 trace_id=1 func=init_ip_session_common line=4463 msg="allocate a new session-07627c64" id=13 trace_id=1 func=vf_ip4_route_input line=1595 msg="Match policy routing: to 1.1.1.1 via ifindex-54" id=13 trace_id=1 func=vf_ip4_route_input line=1605 msg="find a route: flags=00000000 gw-1.1.1.1 via WAN2_Agg" id=13 trace_id=1 func=__iprope_tree_check line=534 msg="use addr/intf hash, len=16" id=13 trace_id=1 func=fw_forward_handler line=537 msg="Denied by forward policy check (policy 60)"

Actually ran into your scenario with another client and with TAC's help we resolved it.  Not sure if it's the same scenario, but if their e-mail is also going through the same Fortigate, it could be.  We have VIPs in place on this firewall for OWA and Outlook Anywhere.  We had to put in policy routes to move that specific traffic to the DMZ directly where the internal reference for the VIP is located and put it higher in priority on the policy route.

[Rewanta_FTNT]

Hi,

policy route over the wan2 should have also routed the vpn traffic. In this case, you need to create the policy routes for the source and vpn destinations to make sure that all vpn traffic is routed out of wan1/ipsec interfaces - this is valid in case of the policy based tunnels, when you have route based tunnels there should not be any problem as the prefix match for the destination with ipsec interface are preferred over the default route. 

Rewanta