Remote IPsec user can't access HTTP/HTTPS

[dabanjm]

Hi,

I have created a remote IPsec VPN for remote users. the users can connect to the VPN.

However, they can't access anything in the LAN behind the FortiGate through HTTP or HTTPS.

For example, I can SSH to the FortiGate to manage it; however, I can't access it through HTTP/HTTPS.

I don't have a route issue because I have ping/ssh to the FortiGate/LAN behind it. I don't have a Policy issue as I have allowed all the services.

Model: 401F

Version: v7.6.4.

[AEK]

Hi

Fist of all, try use "diag sniffer ..." to see if the HTTP(S) requests are reaching the FGT, and if they are forwarded by the FGT.

Also check your client's proxy configuration. It is probably sending the HTTP(S) requests to somewhere else.

[dabanjm]

Hi,

Thank you for your response.

I have captured the traffic before, and I can see that HTTP(S) requests are reaching the FGT, and FGT is replying (they are doing the TCP handshake); however, suddenly the FGT sends FIN.

I don't have any issues connecting to the FGT through SSL VPN from another FGT that is connected to it.

And the issue is not with the FGT's Management only, I have this issue with any LAN device behind the FGT I can ping, SSH, and RDP to, I just can't access them using HTTP(S).

[AEK]

Then try use the following command to check why FGT is blocking the traffic.

diag debug flow filter addr x.x.x.x
diag debug flow filter ...
diag debug console timestamp enable
diag debug flow show iprope enable
diag debug flow show function-name enable
diag debug flow trace start 100
diag debug enable

Once you run the above command, open a web page to an internal server and collect the logs.

[dabanjm]

I ran the provided commands and noticed that it's not hitting any policy rule that allows it.

However, I have a rule (before the implicit deny) allowing it, and I used the Policy Match function, which returns the policy that I have allowing the user to go from IPsec interface to the LAN.

I also made the rule to be the first rule in the table; I had the same issue.

Here is the result for the debug:

25-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-no-match, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2190 msg="checked gnum-10000f policy-4294967295, ret-matched, act-accept"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check_one_policy line=2443 msg="policy-4294967295 is matched, act-drop"
2025-11-10 12:20:38 id=65308 trace_id=672 func=__iprope_check line=2490 msg="gnum-10000f check result: ret-matched, act-drop, flag-00000800, flag2-00000000"
2025-11-10 12:20:38 id=65308 trace_id=672 func=iprope_policy_group_check line=5002 msg="after check: ret-matched, act-drop, flag-00000800, flag2-00000000"
2025-11-10 12:20:38 id=65308 trace_id=672 func=fw_local_in_handler line=630 msg="iprope_in_check() check failed on policy 0, drop"

[funkylicious]

if you are using trusted-hosts for the admin user, you need to put the IP or IPsec subnet in it, otherwise this might why you are hitting policy 0/deny even tho you have a firewall rules for access.

[dabanjm]

I haven't configured any trusted-hosts for the Admin user.

[funkylicious]

have a read of https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Debug-flow-messages-iprope-in-check-...  , if you didnt already.

[dabanjm]

I ran the provided commands, and it appears that it's not finding any matching firewall policy to allow it to connect, which is why, at the end, it hits the implicit deny.

However, I have a rule before the implicit deny that allows access.

I also used the Policy Match function, which returns the rule that I have allowing access from the IPsec interface to the LAN interface.

I set the rule as the first one in the firewall policy table, but I still had the same issue.

Please note that my public IP is on a loopback interface.

[ElwinBERRAR]

HTTP(S) failing while SSH/RDP work often means the flow hits an inspection profile that resets incomplete TLS sessions. Check the policy for deep inspection or web filtering and verify the local-in policy isn’t blocking HTTPS on that interface.