We have many customers who have an IPsec VPN from customer's each location with an FGT/FWF
routed all internet traffic over the VPN toward the customers centralized FW VDOM in our core network.
We manage some of larger customer's CPE FGTs/FWFs by our FMG-VM so that firmware upgrade for those CPE's can be done through the FMG relatively easily.
A problem with this arrangement is all firmware download for the upgrades have to come through the centralized FW VDOM so it gets congested and takes longer time due to the distance to travel when we run upgrades for many locations at the same time even if we specify FMG to let the device directly download from FortiGuard services.
An obvious solution is to split the tunnel to let the CPE devices get to FortiGuard servers outside the tunnel. So I opened a TAC case to ask what FQDNs I need to set static routes to go outside the tunnel while the default route (BGP) comes over the tunnel.
I initially got three FQDNs euupdate.fortinet.net/usupdate.fortinet.net/globalupdate.fortinet.net from the TAC person so I configured them in an address group and used it with a static route. Those seem to be resolved to 173.243.[140/141/142].6 in the US based on the routing-table.
However, when I tested it with a LAB device connected to the FMG while sniffing traffic toward 'net 173.243.0.0/16', I never saw any packet exchange with those three IPs but all communication seem to happen with 173.243.138.67 and .66. When I reported this to the TAC person, he insisted those three IPs are only for netotiation prior to the download from the real servers behind them, although I never saw the "negotiation" part in the sniffing. And, he also insisted I should use ISDB-based static route with "Fortinet-FortiGuard" for the split tunneling.
But it wouldn't work because it requires a static default route to the outisde of the tunnel due to the fact the ISDB static route works as a policy route according to KB below:
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Creating-a-static-route-for-Predefined-Int...
We currently have only a /32 static route toward the wan interface to bring/keep the tunnel up for the peer IP and BGP default route over the tunnel.
Based on WHOIS database 173.243.128.0/20 is Fortinet owned subnet, which include all IPs above. So it likely would work if I use this subnet to split the tunnel. But there is no guarantee it won't change.
I gave up the TAC person and just told him to close the case since I don't seem to be able to get any further infomation.
Does anyone have any further infomation about the FortiOS image download server IPs especially for their FQDNs?
Thanks,
Toshi
Solved! Go to Solution.
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.
Thanks Mohit_S. But I'll close this case now. Because even if the FQDNs existed and I configured them to split tunnel, I realized they wouldn't resolve to IPs until the reachability to DNS server was recovered. It would cause some unstable state when it's rebooted or firmware upgrade happens.
Thanks,
Toshi
Created on 07-29-2022 06:12 AM
Hello @Toshi_Esumi ,
Thank you for using the Community Forum.
I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.
Regards,
Thanks Mohit_S. But I'll close this case now. Because even if the FQDNs existed and I configured them to split tunnel, I realized they wouldn't resolve to IPs until the reachability to DNS server was recovered. It would cause some unstable state when it's rebooted or firmware upgrade happens.
Thanks,
Toshi
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 |
---|---|
1720 | |
1093 | |
752 | |
447 | |
234 |
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.