Using alternative Gateway

Apparently, the default route on the 60C isn' t correct. Could you post the ' live' routing table from here: in the Console applet, type ' get router info routing-table all' and paste the text to a posting.

Hi ede, Here' s the routing table info (public IPs changed). On the PPPoE interface I can select retrieve default gateway from server. I ran continuous pings to a target site on the internet and to the school' s WAN network proxy. Unchecked the proxy responds and checked the internet target site responds. I can' t get both to respond simultaneously. I had hoped for all traffic to redirect through the school network as the unchecked routing suggests. Note 10.56.15.100 is the schools gateway out. I only want the 120 and 210 ranges to go out via the fortigate. With " Retrieve default gateway from server" unchecked. S* 0.0.0.0/0 [10/0] via 10.56.15.100, internal C 10.56.0.0/20 is directly connected, internal C 120.150.210.165/32 is directly connected, ppp1 C 210.45.210.1/32 is directly connected, ppp1 With " Retrieve default gateway from server" checked. S* 0.0.0.0/0 [5/0] via 210.45.210.1, ppp1 C 10.56.0.0/20 is directly connected, internal C 120.150.210.165/32 is directly connected, ppp1 C 210.45.210.1/32 is directly connected, ppp1 From the fortigate I can ping both targets (school' s proxy and specified internet sites). Thanks for your help. Seb.

That' s much clearer now. 1. Leave the ' retrieve def. gw from server' on the 60C unchecked - you don' t want ALL of the traffic to go to it' s gateway (210.45.210.1), just some specific. 2. I don' t see any static routes to the desired target subnets/hosts, like S 120.150.210.99/32 via wan1 (for a single host) S 120.150.210.99/24 via wan1 (for a subnet) So the 60C cannot route and traffic to e.g. 120.150.210.99 follows the default route to the school' s gateway. When you specify these, just use the interface as target - you don' t have to enter a gateway address then. And finally, set the default gateway on (some of) your hosts to the 60C' s internal address.

Thanks ede_pfau, It' s true that the static routes that I' ve put in are not showing in the routing monitor. I can' t see why not. Here' s what I' ve got; Static Routes IP/Mask Gateway Device Comment 0.0.0.0 0.0.0.0 10.56.15.100 internal All Traffic 50.18.152.159 255.255.255.255 120.150.210.1 wan2 Meraki Client iOS 64.156.192.128 255.255.255.255 120.150.210.1 wan2 Meraki Client 1 74.50.59.133 255.255.255.255 120.150.210.1 wan2 Meraki Client 2 175.107.0.0 255.255.0.0 120.150.210.1 wan2 www.goodshepherd.nt.edu.au 176.32.98.166 255.255.255.255 120.150.210.1 wan2 www.amazon.com 210.0.0.0 255.255.0.0 120.150.210.1 wan2 kc.goodshepherd.nt.edu.au Routing Monitor Type Network Gateway Interface Up Time Static 0.0.0.0/0 10.56.15.100 internal Connected 10.56.0.0/20 0.0.0.0 internal Connected 120.150.210.165/32 0.0.0.0 ppp1 Connected 210.45.210.1/32 0.0.0.0 ppp1 The aim is for all traffic arriving to the fortigate on the internal interface is sent back out the internal interface to the the school' s gateway at 10.56.15.100 except the specific IPs and IP ranges that should go out WAN2. I have a similar but reverse arrangement at another campus where all traffic is set to go out the Fortigate' s WAN link except traffic that targets the resources on the school WAN network. That works fine and static routes show in the routing monitor. Still working through it. :-) Thanks, Seb. PS: I see the preview is jumbled, hope you can make out where the columns should be.

I would suspect that the specific routes have a higher distance and/or a higher priority than the default route (to internal). In this case, the default route is " cheaper" and the static routes don' t make it into the Routing Table. To clarify, could you please post the routing table from the CLI: " get router info rout all" , and paste it here. I think if you use the " code" button text will be in monospaced font.

Thanks for hanging in here Ede. Distance and priority were left at the default for all routes (10/0). But I' ve just tried setting the WAN2 static routes to distance 9 and leaving their priority at 0. I' ve left the internal static rout distance at 10 and set its priority to 2. But with no change. Only the static rout to internal shows in the routing monitor;

  FGT60C3G12031800 # get router info rout all     Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP            O - OSPF, IA - OSPF inter area            N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2            E1 - OSPF external type 1, E2 - OSPF external type 2            i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area            * - candidate default           S*      0.0.0.0/0 [10/0] via 10.56.15.100, internal, [2/0]     C       10.56.0.0/20 is directly connected, internal     C       120.150.210.165/32 is directly connected, ppp1     C       210.45.210.1/32 is directly connected, ppp1  

Thanks again, Seb.

Hi Ede, Just to let you know I have it working now. Your hint about distances was the key. In my WAN interface I checked Retrieve default gateway from server, that gave me a static route out the WAN interface (it would appear in Routing monitor). I also set the distance to 1. I then set the distance of the static route out the school' s gateway to 1. So for the first time I had 0.0.0.0/0 showing twice, once each for the routes out the WAN and the internal interfaces. To get this both distances had to be 1. It didn' t work if they were the same but any other value. I then set policy routes in order to direct what I wanted to go out the WAN interface and the rest out the internal interface (and back through the school' s gateway). Thanks very much for your help Ede and I hope this may be of some use to others. For the record the firmware version is 5.0,build0228 (GA Patch 4)

OK, first, I' m glad you got your setup working now. On second thought, what happened here? To achieve your goal, you don' t have to have both default routes showing up at the same time in the Routing Table. If you configure two def. routes with exactly the same distance and priorities then the FGT enables ECMP (Equal Cost, Multiple Paths routing) which gives you 2 active default routes for load balancing and/or redundancy. Just to achieve routing you only need one default route (to the other local gateway). If you configure 2, you get redundancy for free: if the main gateway fails (downtime etc.), traffic will be re-routed to WAN2, keeping your internet access alive. When the first default route is determined down, it will be dropped from the Routing Table, and the (hidden) second default route will be added and used. But with ECMP active, having traffic sent out wan1 for even source IP addresses and out wan2 for the odd ones is NOT what you would like to have. But that' s what the FGT will do to load-balance the traffic onto two equal routes. So, in order to " correct" this (you will have noticed the alternating behavior), you introduced Policy Routes. Policy Routing bypasses all of the Routing Table and thus the faulty setup is " corrected" i.e. overridden. Just to clarify: regular routes determine the egress interface by the destination address (and only the destination address!). Policy Routes can look at the source address, source port or destination port as well to determine the gateway. So, Best Practice demands to use the least complicated mechanism to achieve the goal, and in your case, you only need to separate traffic by it' s destination address. That' s why your setup should work with regular routes right from the start. Now back from theory to real life: apparently, in your case the configuration doesn' t work. The dependence on " distance=1" is awkward and leads me to believe that this is due to a bug in FOS 5.x. (If someone has a little time on his hands it would be great to test this on a 5.x FGT). So, actually, the way you have it set up now might be the only way it will work, and you can well leave it at that.

Hi Ede, Ouch! I will study the issue more but the configuration I outlined above was the only way I could get it to work. I had come across another post mentioning setting the distances and suggesting the Fortigate' s behaviour was unexpected. Anyway for the moment it works and I' ve got more homework to do. Thanks again, Seb.