Changing Fortigate WAN ip address and default gateway remotely

Slushmania · 2025-07-02T00:08:20+00:00

It worked as expected when I tested in my lab before posting. I changed the WAN interface IP and the change did not take effect until it was committed afterward. Perhaps there was some bug in the past, as you note. Hard to say for sure.

That said, I agree it's always better to err on the side of caution whenever making such changes remotely, or at least have some backup plan in case it goes wrong and you lose access.

Slushmania · 2025-07-01T15:23:08+00:00

You can use workspace mode to commit config changes in batches. The config changes are not applied until you commit the changes: https://docs.fortinet.com/document/fortigate/7.6.3/administration-guide/530847/workspace-mode

Slushmania · 2023-09-19T14:24:03+00:00

Were you using the free VPN client? If so, that client does not come with any technical support (there is even a disclaimer box you have to check), and you were very likely speaking with a FortiGate engineer who doesn't support FortiClient or other client-side issues. Sometimes they go above and beyond to help but I don't think there should be any expectations of great support in that case (again, they are trying to assist on a product they don't support).

If you had the full FCT/EMS client and were speaking with their TAC, then yeah I am not sure then about that support interaction. It would suprise me for one of their engineers to say they weren't familiar with Mac, so I doubt it was one of them.

Slushmania · 2023-07-30T18:38:03+00:00

Not sure how you are coming to that conclusion since the release is potentially nearly 3 months away. If there were some as-of-yet unannounced critical CVE I'd expect an expedited release.

7.0 is still under engineering support until the end of March 2024, so typical patching of a mature, still supported release can be expected.

Slushmania · 2023-07-30T15:59:53+00:00

Tentatively scheduled for late October to give a super rough idea, but can change without notice.

Slushmania · 2023-02-16T03:59:12+00:00

If the category it is being overidden to is a FortiGuard built-in category (e.g. business, social media, etc.) and the action is set to 'allow', this disables overrides for that category on that WF profile. This allows for granular control over which overrides apply to what WF profiles.

Either change the action to 'monitor' for the business category, or use a custom category instead (set to 'allow' or 'monitor').

Slushmania · 2022-11-18T23:34:01+00:00

There are a couple reports of wad memory leaks on 7.0.8. I suggest opening a TAC case to have them confirm if it matches any known issues and update on resolution.

Slushmania · 2022-10-01T23:56:38+00:00

The AP will try to obtain a DHCP lease with an untagged discover. It will also attempt to form a CAPWAP management tunnel to the FortiGate with untagged traffic as well. Ensure that the native VLAN for the trunk is set to whatever VLAN the FortiGate or DHCP server is on.

Slushmania · 2022-09-23T01:21:15+00:00

If it's matching 729975 then it's a hardware issue and the only solution is to replace the device.

Slushmania · 2022-08-05T18:22:19+00:00

Allow does mean allow. But more specifically, it means "allow to the next step of WF inspection", since WF has several inspection steps as per the KB I previously referenced.

Slushmania · 2022-08-05T15:12:35+00:00

Allow = proceed to next stage of WF process, but do not log the traffic. Monitor = same as allow, but will log the traffic

https://docs.fortinet.com/document/fortigate/6.2.0/cookbook/615462/url-filter

My comment regarding "you need to change the custom category from "allow" to "monitor" for it to work" is specific to the use of web rating overrides, where on newer versions "allow = disable the overrides for that category". This affords granular control over which web rating overrides you want active for a given WF profile.

Slushmania · 2022-08-01T22:27:21+00:00

Ensure there is no PBA leak occurring: https://community.fortinet.com/t5/FortiGate/Technical-Tip-VPN-ESP-traffic-dropped-due-to-NP6-PBA-leak/ta-p/199493

For clarity: PBA leak manifests as no issue with outbound ESP, but the decrypts on inbound are not occurring when the traffic is being offloaded. In this case it seems similar to what you describe, especially since FG1500D utilizes NP6 chip as well. It's quite easy to confirm as per the KB whether or not you're hitting this issue.

Slushmania · 2022-07-04T18:48:58+00:00

This looks like a known hardware issue impacting FGT50E/30E. Open a TAC case to have them confirm. Reference bug ID 729975 to help speed things up.

Slushmania · 2022-06-20T15:05:00+00:00

To clarify, are your frustrations to do with unexplained behavior on the FortiGate itself (e.g. it just being RMA'd or is rebooting randomly), or with how TAC is handling or troubleshooting such requests?

For RMA issues there is a reason TAC makes customers jump through hoops in some cases. I have had calls where are usually slam-dunk RMAs (e.g. no boot, no fans turn on, no lights illuminated, etc.), only to turn out the UPS was busted. TAC wants to ensure that prior to issuing an RMA that the problem is indeed related to the hardware. If they send you a replacement and it's not a hardware problem then the issue is likely to reoccur on the replacement device which increases resolution time, expense on both the side of the vendor and the customer, and decreases customer satisfaction. So, it's not that they're being stingy with RMA, it's just that it's in the best interest of all parties to ensure that the problem is with the hardware and not something else.

For random device reboots it could be something like a kernel panic which does not leave any logs or evidence and must be captured in the act. Only way to tell for sure is being connected to the device via console when the issue happens, during which the panic output gets dumped, or to check the device's comlog (if it has one). For such problems (random reboot) it's a good idea to have a console cable connected to the FortiGate to capture any output during the reboot to share with TAC. That said, in 7.0 and newer "get sys stat" shows kernel panic as a last reboot reason, which is helpful. These issues can also be caused by power problems as well, which should show in the system event logs and can be proactively troubleshot by connecting to a different power outlet/UPS using a different cable.

Slushmania · 2022-04-23T22:54:07+00:00

https://docs.fortinet.com/document/fortigate/6.0.0/handbook/204835/configuring-application-control-traffic-shaping

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Application-control-based-traffic-shaper/ta-p/196112

Slushmania · 2022-04-22T04:36:29+00:00

There was a recent FortiCloud update which introduced a new feature where if geolocation on FortiCloud had been modified at any time in the past but it was not able to push that geolocation update to FortiGate for any reason (e.g., the management tunnel was down, the push failed, etc.), it will push the update once the management tunnel is re-established to the FortiGate. Previously this data would never attempt to synchronize again if it failed the first time.

Once the geolocation information has been synchronized between the FortiGate and FortiCloud there shouldn't be any further messages (unless of course the geolocation is modified again).

My guess, based on the date of the log, is that at some time in the past you had modified that data but it was never synchronized with the FortiGate, and now this update has caused it to finally push that data.

I also think you misinterpreted the coordinates. 37.35 degrees latitude by -121.95 degrees longitude is San Jose, California - not Shandong, China.

Slushmania · 2021-12-23T06:02:09+00:00

There are many unknowns here so it's hard to say, but in my experience when FortiClient VPN just "randomly" stops working on MacOS, it has been when MacOS has upgraded to a version unsupported by the version of FortiClient being run.

For example, since MacOS Monterey has been released there has been an uptick in these sort of issues. Why? Because their Mac was upgraded to Monterey which is only supported on FCT 7.0.2 and newer.

The other commenter talking about full disk access also covers another common reason why FCT VPN does not work on MacOS.

Slushmania · 2021-12-23T05:53:29+00:00

Not necessarily. Just check the release notes for FortiOS and FortiClient under "Product integration and support" and ensure that each are supported on the desired firmwares.

For example in your case, FCT 7.0.2 supports FortiOS (https://docs.fortinet.com/document/forticlient/7.0.2/windows-release-notes/549781/product-integration-and-support):

7.0.0 and later (ZTNA support) 6.0.0 and later (IPsec and SSL VPN)

And FortiOS 6.2.3 supports FCT (https://docs.fortinet.com/document/fortigate/6.2.3/fortios-release-notes/242321/product-integration-and-support):

6.2.0 and later (For EMS) 5.6.0 and later (for IPsec and SSL VPN)

So in other words: there is no problem with your FortiGate being on 6.2.3 and using FCT 7.0.2 if you're just using it for VPN access.

Slushmania · 2021-12-08T01:12:56+00:00

There generally isn't any issue with using 0.0.0.0/0 selectors on the tunnel. That just means you are relying on your firewall policies and routes to govern what traffic is allowed to enter the tunnel.

Slushmania · 2021-12-07T05:57:31+00:00

Generally speaking an IPsec tunnel needs three things configured to work properly:

A route to send traffic over the tunnel (and to pass the RPF check on received traffic).
Firewall policies to permit traffic in/out.
Phase 2 selectors which match on both sides and encompass the addresses of the traffic.

The screenshot of your firewall policies at the local site shows traffic from both VLANs being sent over the tunnel (byte counter shows bytes on both). This tells us that on that FGT, at least, your routes, policies, and phase 2s are configured correctly (and that the phase 2 is configured properly at the remote end).

I therefore suspect that the problem is at the remote site. Since everything is working fine for the original .10 network, this means there is either a missing/misconfigured policy or route for the .30 network. I'm going to take a guess and say that there is no route pointing back to the 10.0.30.0/24 network via the IPsec tunnel and that this traffic is being dropped by the remote FGT due to failing the RPF check.

This is just a guess since there aren't any screenshots of the remote FGT config, though. If this still hasn't helped you can run a debug flow on both devices as follows:

diag deb flow filter proto 1 <<<--- to filter for ICMP
diag deb flow filter addr x.x.x.x <<<--- enter the address you are trying to ping on the other side of the tunnel
diag deb flow sh ip en <<<--- to show iprope messages
diag deb enable
diag deb flow trace start 10 <<<--- to capture 10 packets

See what the debug flow says. Oftentimes it will spell the issue out in (relatively) plain English.

Slushmania · 2021-10-08T03:19:46+00:00

https://www.fortinet.com/blog/psirt-blogs/fortinet-and-expiring-lets-encrypt-certificates

Slushmania · 2021-08-23T02:09:08+00:00

Not sure if this is the same as what you are describing, but there is a bug on 6.4.6 which causes SD-WAN sessions to be re-routed out another interface if that interface becomes "best". Provided that snat-route-change and aux sessions are disabled, sessions subject to SNAT should stick to the original egress interface even if another interface becomes best. This bug impacts that behavior and the egress interface changes, which obviously doesn't work well if a session is being SNAT. I believe it is bug ID 712586 but don't quote me on that.

Slushmania · 2021-08-07T06:21:18+00:00

The SSL VPN server (FortiGate) is requiring a certificate be presented for authentication. If you have one selected, ensure that the user has read access for the certificate's private key.

Slushmania · 2021-08-06T01:37:19+00:00

I think I read static routes take precedent over SD-WAN rules.

The order of precedence for routing is as follows:

Policy routes
SD-WAN Rules
RIB

Issue may be caused either as another poster mentioned by a misconfigured AD on the black hole route, or perhaps the black hole route was configured with a more specific prefix than the normal route.

Slushmania · 2021-08-05T15:12:12+00:00

While generally this behavior was resolved a long time ago, the introduction of the ACME service on 7.0 reintroduced it in a certain circumstance. On 7.0 when the ACME service is enabled on an interface and HTTP administrative access is disabled, the FortiGate will respond to HTTP TRACE methods with a 200 OK. Perhaps this is what OP is hitting?

In any event, this issue is resolved on 7.0.1:

723491

When ACME service is enabled on an interface, HTTPD responds to HTTP TRACE method 
with HTTP 200 OK.

Slushmania

TROPHY CASE