medium

SSL VPN fails after changing the listening interface

Q: SSL VPN fails after changing the listening interface

1. Review the generic SSL VPN configuration and confirm the intended listening interface. The following example listens on WAN2 and TCP port 11443: 2. Enter the SSL VPN authentication-rule configuration and inspect each rule. These interface settings are not exposed in the GUI: An affected rule can show output similar to: 3. If multiple authentication rules are configured, check all of them. In this example, rule 1 is incorrectly bound to WAN1 while rule 2 correctly uses WAN2: Expected example output for the incorrect rule: Check the second rule: Expected example output for the correct rule: 4. Correct an explicitly configured authentication-rule interface so that it matches an SSL VPN listening interface: 5. Because the authentication-rule value is not visible in the GUI, the recommended approach is to unset it and manage the listening interfaces in the generic SSL VPN settings. Within the affected authentication rule, use: When unset, the authentication rule uses the generic SSL VPN setting.

Confirmed 9/21/2026

Problem

An SSL VPN connection can fail after its listening interface is changed under the GUI SSL VPN settings. For example, the generic SSL VPN configuration may be changed from WAN1 to WAN2 while a CLI-only authentication rule remains bound to WAN1.

Symptoms

FortiClient may stop at 10%. This can occur when the TCP three-way handshake does not complete or when the client resets the connection after the handshake completes, causing FortiGate to terminate the connection.

Environment

FortiGate SSL VPN. Example configuration uses TCP port 11443, WAN2 as the generic SSL VPN source interface, the tunnel-access portal, and authentication rules containing source-interface values. GUI path: SSL VPN settings.

Root Cause

The `source-interface` configured in one or more SSL VPN authentication rules does not match an interface present in the generic SSL VPN settings. Authentication-rule interface values are configurable only through the CLI and may retain the previous interface after the GUI listening interface is changed. If an authentication-rule `source-interface` is unset, the rule inherits the source interface from the generic SSL VPN configuration. If it is explicitly set, that interface must be correct and must also be present in the generic SSL VPN settings. When multiple rules exist, connectivity can still succeed if at least one rule uses the correct interface; failure occurs when the only rule, or all applicable rules, use an incorrect interface.

Solution

Review the generic SSL VPN configuration and confirm the intended listening interface. The following example listens on WAN2 and TCP port 11443:

config vpn ssl settings
    set banned-cipher SHA1 SHA256 SHA384
    set servercert ''
    set tunnel-ip-pools "HUB_local_subnet_1" "Test_Dial"
    set tunnel-ipv6-pools "SSLVPN_TUNNEL_IPv6_ADDR1"
    set port 11443
    set source-interface "WAN2"
    set source-address "all"
    set source-address6 "all"
    set default-portal "tunnel-access"
    config authentication-rule
        edit 1
            set source-interface "WAN1"
            set source-address "HUB_local_subnet_1"
            set users "test1"
            set portal "tunnel-access"
        next
        edit 2
            set source-interface "WAN2"
            set source-address "HUB_local_subnet_1"
            set users "test1"
            set portal "tunnel-access"
        next
    end
end

Enter the SSL VPN authentication-rule configuration and inspect each rule. These interface settings are not exposed in the GUI:

config vpn ssl settings
config authentication-rule
edit 1
get

An affected rule can show output similar to:

id : 1
source-interface : "WAN1"
source-address : "HUB_local_subnet_1"
source-address-negate: disable
source-address6 :
source-address6-negate: disable
users : "test1"
groups :
portal : tunnel-access
realm :
client-cert : disable
cipher : high
auth : any

If multiple authentication rules are configured, check all of them. In this example, rule 1 is incorrectly bound to WAN1 while rule 2 correctly uses WAN2:

config vpn ssl settings
config authentication-rule
get 1

Expected example output for the incorrect rule:

id : 1
source-interface : "WAN1"
source-address : "HUB_local_subnet_1"
source-address-negate: disable
source-address6 :
source-address6-negate: disable
users : "test1"
groups :
portal : tunnel-access
realm :
client-cert : disable
cipher : high
auth : any

Check the second rule:

get 2

Expected example output for the correct rule:

id : 2
source-interface : "WAN2"
source-address : "HUB_local_subnet_1"
source-address-negate: disable
source-address6 :
source-address6-negate: disable
users : "test1"
groups :
portal : tunnel-access
realm :
client-cert : disable
cipher : high
auth : any

Correct an explicitly configured authentication-rule interface so that it matches an SSL VPN listening interface:

config vpn ssl settings
config authentication-rule
edit 1
set source-interface <SSLVPN-LISTENING-INTERFACE>
next
end
end

Because the authentication-rule value is not visible in the GUI, the recommended approach is to unset it and manage the listening interfaces in the generic SSL VPN settings. Within the affected authentication rule, use:

unset source-interface

When unset, the authentication rule uses the generic SSL VPN source-interface setting.

Verification

Run the following commands again for every authentication rule and confirm that source-interface is either unset or matches an interface configured in the generic SSL VPN settings:

config vpn ssl settings
config authentication-rule
edit 1
get

Then retry the FortiClient SSL VPN connection. It should no longer stop at 10% because of the stale authentication-rule interface binding.

Community rating

— / 5 (0)

Discussion (0)

No comments yet.