Skip to main content
js2
Staff
Staff
April 25, 2020

Technical Tip: SSL-VPN connectivity issues Due to error 'iprope_in_check() failed'

  • April 25, 2020
  • 0 replies
  • 6885 views

Description

 

This article provides troubleshooting steps and potential causes for SSL-VPN connectivity failures when the debug output displays the error 'iprope_in_check() failed'.

 

Scope

 

FortiGate.

Solution

 

When facing this error, check the following factors that may be contributing:

 

  1. Check for VIP or IP pool conflicts: Ensure there is no Virtual IP (VIP) or IP pool configured that conflicts with the SSL VPN listening interface or port.

  2. Verify Firewall Policy Configuration:

 

Confirm that:

  • A firewall policy exists with the SSL-VPN tunnel interface (ssl.root) configured as the incoming interface.
  • The appropriate user group is mapped for authentication.
  • No policy route is matching and redirecting the SSL-VPN traffic.

If there is no firewall policy configured with ssl.root as the incoming interface, the sslvpnd daemon will not start. This can be verified using the command 'diagnose sys tcpsock | grep sslvpn'. For more details, refer to the configuration guide for SSL VPN: SSL VPN tunnel mode.

  1. Perform packet capture: Run a packet capture on the FortiGate and verify whether the traffic is being received.
    In some cases, the SYN packet is received from the client, but the firewall does not respond with SYN-ACK:

    2020-04-23 07:32:35.980933 wan in 1.1.1.1.55031 -> 4.5.9.2.10443: syn 2487955987
    2020-04-23 07:32:36.980701 wan in 1.1.1.1.55031 -> 4.5.9.2.10443: syn 2487955987
    2020-04-23 07:32:38.981467 wan in 1.1.1.1.55031 -> 4.5.9.2.10443: syn 2487955987

  2. Check for a process crash: Verify whether any crash occurred involving the sslvpnd process by running the command 'diagnose debug crashlog read'.

  3. Review debug flow logsCapture debug flow(Debugging the packet flow) logs to determine whether traffic is being dropped:

id=20085 trace_id=1 func=print_pkt_detail line=5501 msg="vd-root:0 received a packet(proto=6, 1.1.1.1:10568->4.5.9.2:10443) from lan4. flag [S], seq 1191361412, ack 0, win 8192"
id=20085 trace_id=1 func=init_ip_session_common line=5666 msg="allocate a new session-000133ab"
id=20085 trace_id=1 func=vf_ip_route_input_common line=2596 msg="find a route: flag=80000000 gw-4.5.9.2 via root"
id=20085 trace_id=1 func=fw_local_in_handler line=420 msg="iprope_in_check() check failed on policy 0, drop"

 

  1. Verify the source-address-negate setting.


Check whether the source-address-negate option is enabled in the SSL VPN configuration.

 


config vpn ssl settings
set source-address-negate {enable | disable}

If source-address-negate is enabled, any address listed under source-address will be blocked.
Ensure that incorrect or overly broad address objects are not configured.

Note: Do not configure 'all' as a source address while using negate, as this will cause the firewall to drop all VPN connections.

  1. Verify the kernel iprope entry:

 

Ensure the kernel iprope entry for the SSL VPN destination port is correctly installed.

Run the following diagnostic commands:

 

diagnose netlink interface list <SSL-VPN listening port>
diagnose firewall iprope list 10000e

 

  1. Check for local-in policies:

 

A configured local-in policy may explicitly deny SSL VPN traffic.

 

To verify this, run the following command:

 

show firewall local-in-policy

If a local-in policy is present, ensure it allows traffic to the SSL VPN listening interface and port.

 

By systematically validating the output of the checks above, administrators can identify and resolve the root cause of the 'iprope_in_check() failed' error impacting SSL VPN connectivity.

Related documents:

Thought Leadership Security Summit. Outpace New Threats with AI - enhanced defense. Tuesday, Septmeber 15, 8:30 AM - 2:30 PM PT. The Golf Club at Newcastle, WA.
Virtual event | September 2026. SASE summit. The age of autonomous trust. Register here!