Troubleshooting Tip: Enabling FortiToken Mobile on the FortiGate interface can allow Web GUI access when both services use the same port number

[pjang]

Description	This article describes a known behavior that can occur when FortiToken Mobile Push (also known as 'FTM-Push' and 'FTM' in the GUI/CLI) is enabled on a network interface and is also using the same listening port as the Administrative Web GUI.
Scope	FortiGate v7.x.
Solution	For context, FortiToken Mobile Push (FTM-Push) is a feature associated with FortiToken Mobile (FTM) two-factor authentication. The FTM-Push feature allows the FortiGate to send push notifications to Android/iOS smartphone users with the FortiToken Mobile app, and from there the users can send their token codes directly to an accessible FortiGate interface (i.e. a WAN interface with FTM enabled in the Administrative Access section). Refer to Technical Tip: FortiToken mobile push notification for more information. The following conditions must be met for this corner case to occur: FortiToken Mobile Push must be enabled on a network interface (it is not enabled by default). In the GUI, it would be enabled by editing the Administrative Access settings for an interface under Network -> Interfaces and enabling the 'FTM' toggle: In the CLI, it would be enabled on a per-interface basis under config system interface using set administrative-access ftm. Note that in this scenario, FortiToken-Mobile Push (config system ftm-push) does not need to be configured/enabled explicitly. The 'FTM' option just needs to be enabled on the network interface. The HTTPS port used for the Admin Web GUI must be set to the same listening port as FortiToken Mobile Push. The default listening port for FortiToken Mobile Push is TCP/4433 (see further below for more information). HTTPS Administrative Access must be disabled on the same interface that has the 'FTM access' option enabled. The following is an example of what the config could look like in a problem state: show full system global | grep admin-sport set admin-sport 4433 show system ftm-push | grep server-port set server-port 4433 show system interface port1 [...] set ip 100.0.0.1 255.255.255.0 set allowaccess ping ftm [...] In the above example, the FTM-Push listening port is set to TCP/4433 and overlaps with the port used for HTTPS Web GUI access. In this scenario, it is possible to access the Web GUI using port1's address of 100.0.0.1, even though HTTPS access is not enabled on port1. Recommendation: To address this issue, it is recommended to disable/toggle-off 'FTM' in the Administrative Access (aka set allowaccess) section for all interfaces that are not explicitly being used for FortiToken Mobile Push configurations. Alternatively, ensure that the ports used for HTTP/HTTPS admin access to the FortiGate do not overlap with the port used for FTM Push (default: TCP/4433). Why this behavior occurs: When FTM is enabled on an interface via Administrative Access, the FortiGate will add an internal policy that allows incoming traffic for the FTM listening port (in this case TCP/4433) on that interface. This internal policy is called an 'iprope' rule (see also: Technical Tip: Iprope policies group). The iprope rules are used to govern if traffic is allowed to be received and processed by the FortiGate. In a normal situation (i.e. where the HTTPS GUI port and the FTM port are non-overlapping), the rule will look like the following example: policy index=4294967295 uuid_idx=7 action=accept flag (1): log schedule() cos_fwd=0 cos_rev=0 group=0010000f av=00000000 au=00000000 split=00000000 host=0 chk_client_info=0x0 app_list=0 ips_view=0 misc=0 zone(1): 5 -> zone(1): 0 source(1): 0.0.0.0-255.255.255.255, uuid_idx=0, dest(1): 100.0.0.1-100.0.0.1, uuid_idx=0, service(1): [6:0x0:0/(0,65535)->(443,443)] flags:0 helper:auto [6:0x0:0/(0,65535)->(4433,4433)] flags:0 helper:auto In the above example, HTTPS and FortiToken Mobile Push are enabled on the interface's Administrative Access settings, and so the iprope policy has lines to accept each service. If one is disabled, then its corresponding entry near the bottom service section is removed. The problem is that the FortiGate currently allows administrators to modify the Admin HTTPS port to overlap with the FortiToken Mobile Push port (last tested: FortiOS 7.4.5). This makes the HTTPSD daemon listen to the GUI access on port 4433 so when the HTTPS traffic hits port 4433, the HTTPSD daemon will be functioning and the GUI will load. Interestingly, the reverse is not possible: the FortiToken Mobile Push server-port cannot be set to overlap with an existing Admin HTTPS port or SSL-VPN port, as a check exists to stop this action. Once this overlap exists, the iprope list will have at least one valid service entry allowing access to the overlapping port, even when one of the two services (HTTPS or FTM) is disabled on the interface. This iprope allow policy is why it is possible to access the Web GUI when the correct circumstances are met. Note that this scenario has a low likelihood of occurrence given the conditions required. The most likely situation will be for administrators who configure TCP/4433 for their HTTPS Web GUI access, who are not using FortiToken Mobile Push, and who also accidentally enable FortiToken Mobile Push on one of their interfaces. Related articles: Technical Note: GUI access on port 4433 not working in version 5.6.0 Technical Tip: FortiToken mobile push notification Troubleshooting Tip: FTM-Push notification configured but not working