Troubleshooting Tip: FortiToken Mobile-Push notification configured but not working

[Renante_Era]

Description	This article describes the process of initial 'ftm-push' troubleshooting.
Scope	FortiGate, FortiToken.
Solution	This article is relevant for use cases where FortiToken is assigned to FortiGate users or administrators. For initial troubleshooting when FortiToken is assigned on FortiAuthenticator, see the article Technical Tip: FortiToken Push on FortiAuthenticator: operation flow and details. The following are troubleshooting tips that need to be performed after configuring the FortiToken mobile push notification, but users are unable to log in after tapping 'Approve' on the FortiToken Mobile Apps. Check if FortiToken Mobile and PING are enabled in the Administrative Access of the WAN interface under Network -> Interfaces. Verify the server address set in ftm-push and ensure that the status is enabled. In general, use 0.0.0.0 or an FQDN unless one has a specific reason to specify the public IP address. Keep in mind that specifying a public IP address on the server might impact ftm-push failover when the device encounters an ISP issue. show full system ftm-push Note the server-port from the output of the above command and ensure that there is no overlapping port issue under Policy & Objects -> Virtual IPs. Update that port if necessary. For instance, if port forwarding is configured under Virtual IPs for port 4433, and there are no conflicts for 20443, then use the following commands: config system ftm-push     set server-port 20443 end Verify that the FortiGate feature in question supports ftm-push. For example, IKEv1 does not support ftm-push, and IKEv2 only supports it in specific firmware versions. See the article Technical Tip: Required firmware/software versions for using FortiToken Mobile or OTP MFA with Forti.... Verify that the server-port is not blocked in the local-in-policy. show full firewall local-in-policy If the FortiGate is using internal DNS and the DNS server replies to a different IP than the Public IP, change the ftm-push config to the Public IP instead of the domain name. Testing the name resolution: execute ping <Domain Name> If the resolution is different from the Public IP, then adapt the config: config system ftm-push     set server <Public IP> end Run debug flow and ensure that the message 'iprope_in_check() check failed, drop' is not seen, which might indicate that the inbound ftm-push traffic is blocked due to Trusted Hosts configured under System -> Administrators. diagnose debug reset diagnose debug flow filter clear diagnose debug console timestamp enable diagnose debug flow show iprope enable diagnose debug flow filter addr  x.x.x.x <- Where x.x.x.x is the corresponding public IP address for ftm-push. diagnose debug flow filter port yyy <- Where yyy is the port number assigned to server-port in ftm-push. diagnose debug flow trace start 99 diagnose debug enable Next, test ftm-push, and disable debug flow after completion with the following commands: diagnose debug reset diagnose debug disable If the issue persists after following the above steps, then gather the following debug logs and create a ticket. diagnose debug reset diagnose debug application ftm-push -1 diagnose debug enable Finally, test ftm-push, and disable debug flow once done using the following commands: diagnose debug reset diagnose debug disable Note: For Push Notifications to work seamlessly, there should be an Admin account on a FortiGate without the Trusted Host feature (Restrict login to trusted hosts) enabled. Either edit one of the existing Admin accounts or add a new Admin account without a Trusted Host. Related articles:  Technical Tip: FortiToken Mobile push notification Technical Tip: How to provision FortiToken Cloud