Moving from SSL VPN to FortiClient IPsec changes the protocol. It does not make password-based remote access invisible to attackers.
Check the IPsec login evidenceFortiGate dial-up IPsec can still receive username and password guesses. IKEv2 uses EAP and IKEv1 uses XAuth, normally through UDP 500 and 4500. Reduce the risk with FortiToken MFA or client certificates, restrict who can reach IKE with local-in policies, and block known hostile source addresses with a threat feed.
Testing a block list? Download the free 200-entry sample. No signup is required.
IPsec removes the SSL VPN tunnel listener, but a dial-up tunnel can still ask FortiGate to authenticate a person.
Fortinet uses XAuth for IKEv1 user authentication and EAP for IKEv2 user authentication. Those methods can validate local, LDAP, or RADIUS-backed users. FortiToken two-factor authentication can be combined with those user sources. A public dial-up gateway therefore still receives authentication requests when usernames and passwords are enabled.
For UDP transport, IKE begins on UDP 500 and uses UDP 4500 for NAT traversal. IKEv2 can also use TCP transport. On new FortiOS 7.6.1 configurations the default IKE TCP port is 443; upgraded configurations retain their existing value.
Open Log & Report > System Events and select VPN Events. A negotiation event alone is not proof that a password was tried.
| FortiGate value | What it means | What it does not prove | What to check next |
|---|---|---|---|
logid="0101037127"logdesc="Progress IPsec phase 1"action="negotiate" |
Fortinet uses this event for progress through IPsec phase 1. Read its status, result, stage, role and remote address together. |
It does not prove that user authentication occurred. Fortinet also shows this ID for successful phase 1 negotiation. | Group events by remip, tunnel, time and result. Then check whether an EAP or XAuth stage followed. |
Automation event log ID 37121 with result XAUTH authentication failed |
Fortinet documents this exact filter for failed XAuth authentication on an IPsec dial-up tunnel. | It applies to IKEv1 XAuth. It is not a generic identifier for every IKEv2 EAP failure. | Check the remote address, submitted XAuth user, tunnel and nearby authentication-server events before blocking the source. |
logid="0101037138"action="tunnel-up" |
The IPsec connection status changed and a tunnel came up. | It does not show that every earlier failure from the address was hostile. | Correlate remip, user fields, assigned address and tunnel name. Treat an unexpected success as higher priority than repeated failures alone. |
remip, xauthuser, eapuser, tunnel and result fields |
These fields help separate a repeated source, a targeted identity, the authentication method and the affected tunnel. | An unfamiliar address or username does not establish intent by itself. | Compare the event with approved users, identity-provider or RADIUS records, successful tunnels and configuration changes. |
login-attempt-limit and login-block-time settings belong to config vpn ssl settings. Fortinet’s current IPsec guidance does not document an equivalent built-in per-source IKE attempt counter. It instead documents access restrictions and an optional automation stitch for the exact IKEv1 XAuth failure event.
Apply identity and reachability controls before adding an outside block list.
| Fix | FortiOS configuration | What it stops | Limit |
|---|---|---|---|
| FortiToken MFA | For a local user, go to User & Authentication > User Definition, edit the user, enable Two-factor Authentication, and assign a FortiToken. Keep that user in the group used by the dial-up IPsec tunnel. | A guessed password alone is not enough to complete authentication. | The gateway still receives and processes the attempt. Confirm the chosen remote authentication path supports the intended challenge flow. |
| Client certificates | Create PKI users or peers from your trusted CA and configure the dial-up tunnel for signature authentication. Current FortiOS also supports IKEv2 certificate validation followed by EAP with eap-cert-auth enable. |
Rejects clients that cannot present a certificate trusted and matched by FortiGate. | Certificate issuance, storage and revocation must be managed. A certificate does not remove the need for monitoring. |
| IKEv2 EAP with the correct group | Bind the approved group with set authusrgrp "<group-name>" under the phase 1 interface. For LDAP-backed IKEv2, Fortinet requires EAP-TTLS; FortiClient and EMS 7.4.3 or later are required for that method. |
Limits authentication to the identities and backend intended for that tunnel. | It does not keep an untrusted address from reaching IKE. Fortinet warns not to bind the same group in both phase 1 and the firewall policy. |
| Peer certificate, peer ID or Network ID matching | Use the identity mechanism that matches the design. During migration, Fortinet uses Network ID to distinguish IKEv2 dial-up tunnels on the same WAN interface. | Prevents a connection from being assigned to a tunnel whose expected identity does not match. | It is tunnel selection and peer validation, not a rate limit for password failures. |
| Local-in restrictions | Restrict the IKE service on the public interface to approved sources or countries, or deny known hostile sources. Local-in policies control traffic addressed to FortiGate itself. | Keeps matching packets away from the IKE service. | Traveling users may have changing source addresses. Country rules can block legitimate travel and still allow attackers inside an allowed country. |
| XAuth failure automation | Fortinet documents an automation trigger for event log ID 37121 when result equals XAUTH authentication failed. |
Can add the source of an IKEv1 XAuth failure to a block group. | The published example reacts to an exact XAuth event; it is not an EAP-wide per-IP lockout. Automatic permanent objects also need review and cleanup. |
This pattern enables EAP, binds one approved group, and validates a client certificate as well. Replace every placeholder and test with your FortiClient and identity design.
config vpn ipsec phase1-interface
edit "<tunnel-name>"
set ike-version 2
set authmethod signature
set eap enable
set eap-identity send-request
set authusrgrp "<group-name>"
set eap-cert-auth enable
set certificate "<server-cert>"
set peer "<user-peer>"
next
endDo not enable certificate validation until the CA, peer object and client certificates are deployed and tested. If you want certificate-only authentication, follow Fortinet’s separate dial-up certificate guide rather than copying this EAP example.
A forward firewall policy handles traffic passing through FortiGate. A local-in policy handles traffic whose destination is the FortiGate interface, including its IPsec service.
Fortinet’s fixed-peer example allows the trusted address and denies other sources for the built-in IKE and ESP services. That model is useful for site-to-site peers. It is usually impractical for dial-up users whose home and mobile addresses change.
For geographic restrictions, follow the separate FortiGate country-blocking guide. For a single address, use the firewall IP-blocking guide. Preserve an approved management path and test a traveling-user plan before enforcement.
External threat-feed objects can be used in a local-in policy starting with FortiOS 7.2.4 and 7.4.0. FortiOS 7.0 does not support that use. Starting with FortiOS 7.6.0, administrators can create local-in policies in the GUI at Policy & Objects > Local-In Policy; earlier supported releases use the CLI.
The built-in IKE service covers UDP 500 and UDP 4500. Replace the interface, object name and unused policy ID:
config firewall local-in-policy
edit <unused-policy-id>
set intf "wan1"
set srcaddr "ThreatListPro"
set dstaddr "all"
set action deny
set service "IKE"
set schedule "always"
next
endPut any trusted-source allow rule above the deny rule. Local-in policies are order-sensitive. If the tunnel uses IKE over TCP, also include a custom TCP service for the configured ike-tcp-port. Do not assume it is 443 on an upgraded system.
detect-unknown-esp behavior and version differences for checking unknown ESP against local-in policies. Do not change that setting merely to stop password guesses. Review Fortinet’s IKE and ESP local-in guide and test existing tunnels first.
Use a list when the addresses you need to block are too numerous to maintain safely by hand, or when you want to reject sources already observed attacking other VPN portals.
A dynamic block list (Palo Alto calls it an External Dynamic List, or EDL; FortiGate calls it a threat feed) gives the firewall a URL it can refresh. Read what an external dynamic list is for the terminology.
In FortiOS, go to Security Fabric > External Connectors > Create New > IP Address. Use the customer feed URL https://api.threatlistpro.com/v1/YOUR_API_KEY/blocklist.txt and set the refresh rate to 60 minutes. The file is plain text with one IPv4 address or CIDR per line; single addresses are written as /32.
ThreatListPro covers 5.4M+ IPv4 addresses. Entries come from real attacks on live production Palo Alto GlobalProtect VPN portals in the US, and the list is checked for new attackers every 6 hours.
Use the FortiGate threat-feed setup guide for connector validation and the complete enforcement procedure. This reference does not repeat that setup.
A new IP’s first attempt still arrives. ThreatListPro is IPv4 only and does not stop every brute-force or password-spraying attempt. CIDR ranges include addresses that did not each attack, so check your users’ source IPs first and allow-list trusted networks where needed.
A block list does not replace MFA, certificate management, correct group binding, current FortiOS releases, monitoring or incident response.
Measure failed negotiations and successful tunnels separately. The successful event is usually the more urgent finding.
remip, xauthuser, eapuser, tunnel name, result and time.tunnel-up events before spending time on failed attempts.First confirm that the events reached EAP or XAuth user authentication instead of stopping at ordinary IKE negotiation. Require FortiToken MFA or client certificates, bind the intended user group, restrict IKE with a local-in policy where practical, and monitor successful tunnels. Add a threat feed after those controls.
Go to Log & Report > System Events and select VPN Events. Read the remote IP, tunnel, user fields, result and nearby events together. Log ID 0101037127 is a general phase 1 progress event and does not prove a password attempt by itself.
Use MFA or certificates to protect authentication, then restrict the IKE service with a local-in policy. The built-in IKE service covers UDP 500 and 4500. If the tunnel uses TCP transport, include the configured IKE TCP port. A threat-feed object can be used in a local-in policy on supported FortiOS releases.
Changing protocols does not remove the need for secure authentication and exposure controls. Fortinet replaced SSL VPN tunnel mode with IPsec in FortiOS 7.6.3, but dial-up IPsec can still use password-backed EAP or XAuth. Its safety depends on the complete design, including MFA, certificates, group binding, policy and monitoring.
Fortinet supports FortiToken two-factor authentication for IPsec users and supports it with local, LDAP, RADIUS or SAML authentication. Assign the token to the user, keep the user in the group bound to the IPsec tunnel, and test the complete FortiClient authentication flow before making it mandatory.
It controls packets addressed to the FortiGate interface itself, including packets sent to the IKE service. That differs from a forward policy, which controls traffic passing through the FortiGate. A matching local-in deny can keep a source from reaching IKE, but policy order and trusted-source exceptions must be tested carefully.
ThreatListPro covers 5.4M+ IPv4 addresses and is checked for new attackers every 6 hours. Monthly is $9.99 with a 14-day free trial and no card needed.
Start a 14-day free trial Or test 200 entries first: free, no signupThreatListPro uses a plain-text feed for firewalls that support external IPv4 address lists.
Continue with the feed setup, access restrictions and migration context.