Hello FortiNet Community, new Forigate 60E user here and looking for your experience.
I am doing all this remotely and I'm 1000s of kms away, so I need to be SURE of configuration before I make a change and bring the network down or lose my access.
As mentioned, I have a Fortigate 60E with Dual WAN configured WAN1 is the current primary connection (lower distance / priority) and WAN2 is a new ISP and what I eventually want to become the primary once I confirm everything is working appropriately.
I have confirmed WAN2 is functioning appropriately with a static route to a specific IP via WAN2 gateway.
WAN1 is configured to administer via HTTP/HTTPS and working. WAN2 is also configured to administer via HTTP/HTTPS and NOT working. Times out.
SSL VPN is also active, configured to listen on WAN1 and WAN2, but only working via WAN1.
Any insight to get either HTTPS admin / SSL VPN working (while WAN1 being primary route) is greatly appreciated.
Joe.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
You need a proper route(s) back to the source(s) toward wan2. Otherwise, ends with "reverse path check fail" because it tries going out via wan1. A way to do it is to set a static default route with higher priority value (lower priority). You can search on the internet "fortigate static route priority" to find a bunch of KBs and Cookbooks.
Thank you for pointing me in the right direction Toshi, I will do some more reading :)
If you're planning to keep both WAN links and just start favouring the new one, then consider combining your WAN links into SD-WAN. Then use the load balancing option to favour one WAN link if that's how you want to divide the traffic when both are up. This approach will leave default routes for both WAN links in the routing table and you can access either from outside - including SSL VPN.
If you're not keeping both WANs long term and don't want to end up with a single member sdwan (which works fine, BTW) then you could consider using two default routes (as per previous post) but use policy routing to send selected traffic to WAN2. Be careful though because policy routes get applied before locally connected routes, i.e., VLANs. Some VLANs/ports won't be able to talk to each other if you have an applicable policy route pointing to a WAN. You'll need to suppress policy routing between VLANs. Don't ask me how I learned that lesson!
Either of these approaches let you test WAN2 much more thoroughly before switching your traffic. You can use sdwan rules (or policy routes) to "assign" certain hosts/subnets to use WAN2 while everything else stays on WAN1.
Hope that helps.
...Fred
commutator wrote:If you're planning to keep both WAN links and just start favouring the new one, then consider combining your WAN links into SD-WAN. Then use the load balancing option to favour one WAN link if that's how you want to divide the traffic when both are up. This approach will leave default routes for both WAN links in the routing table and you can access either from outside - including SSL VPN.
If you're not keeping both WANs long term and don't want to end up with a single member sdwan (which works fine, BTW) then you could consider using two default routes (as per previous post) but use policy routing to send selected traffic to WAN2. Be careful though because policy routes get applied before locally connected routes, i.e., VLANs. Some VLANs/ports won't be able to talk to each other if you have an applicable policy route pointing to a WAN. You'll need to suppress policy routing between VLANs. Don't ask me how I learned that lesson!
Either of these approaches let you test WAN2 much more thoroughly before switching your traffic. You can use sdwan rules (or policy routes) to "assign" certain hosts/subnets to use WAN2 while everything else stays on WAN1.
Hope that helps.
...Fred
Thanks for the suggestion Fred, this would have made the most sense for testing, but we have no intentions of keeping the second ISP. I read the cookbook on SD-WAN and it seems like my 60E doesn't support it in the GUI, and I'm not really interested in messing with the CLI to see if I can enabled it for obvious reasons below.
Trial by fire, right?
In the end, everything worked out fine. I lowered the distance on WAN2 (read it in another thread for failover / load balancing) to be what I though was the same distance of WAN1 and unexpectedly WAN2 become active and everything was working on the new connection (thankfully!). I say unexpectedly because my "manual" configured WAN1 doesn't have a distance setting, while my PPPoE WAN2 does.
To summarize for any future person wondering:
- WAN2 was added with a higher Distance than WAN1 - This will allow you to continue admin over WAN1
- Added second 0.0.0.0 static route pointing at WAN2 with a higher distance than the WAN1 Route
- Added WAN2 to my IPV4 policies where WAN1 was mentioned
- Made sure VPN was also listening on WAN2
- Tested WAN2 functionality by adding a static route to a specific destination using WAN2.
- Lowered distance of WAN2 to become active.
Joe
I'm sure sdwan is supported. (Not arguing you should use it.) I used it at home on my 60D and now 40F. You probably have to enable it. Look under System > Feature visibility if on 6.4. I think it used to be System > Advanced in earlier firmware. You'll find an array of features available but not enabled by default. I only mention this because there may be other things you want to use in there that won't appear in the GUI otherwise.
...Fred
Thanks so much Fred! Ssure enough, SDWAN is there and lots of other things I will look into as well :)
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1710 | |
1093 | |
752 | |
447 | |
231 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.