|
The SSL VPN may not function as intended in some situations. Additionally, the debug logs would not provide an error indicating that the ssl.root interface is down when the FortiGate is in FIPS mode.
To know more, SSL VPN and FNBAMD debugs can be taken:
If the following error is found on the debugs:
[652:root:198]rmt_web_auth_info_parser_common:492 no session id in auth info
[652:root:198]rmt_web_get_access_cache:841 invalid cache, ret=4103
[652:root:198]User Agent: FortiSSLVPN (Windows NT; SV1 [SV{v=02.01; f=07;}])
[652:root:198]get_cust_page:128 saml_info 0
[652:root:198]req: /remote/logincheck
[652:root:198]rmt_web_auth_info_parser_common:492 no session id in auth info
[652:root:198]rmt_web_access_check:760 access failed, uri=[/remote/logincheck],ret=4103,
[652:root:198]sslConnGotoNextState:309 error (last state: 1, closeOp: 0)
[652:root:198]Destroy sconn 0x7f6cc6557a00, connSize=0. (root)
In the sniffer, it can be seen that the SYN packets are coming in but no syn-acks are going back:
diagnose sniffer packet any ' port 4443' 4 0 l
2024-11-27 12:25:51.496920 port3 in 192.168.10.2.61280 -> 10.9.11.17.4443: syn 1746941216
2024-11-27 12:25:51.497041 port3 in 192.168.10.2.61281 -> 10.9.11.17.4443: syn 1344227776
2024-11-27 12:25:51.746579 port3 in 192.168.10.2.61282 -> 10.9.11.17.4443: syn 3427715850
Similarly, on the flow debugs, it can be seen that syn packets are coming in and then getting dropped:
2024-11-27 12:27:03 id=65308 trace_id=1 func=print_pkt_detail line=5862 msg="vd-root:0 received a packet(proto=6, 192.168.10.2:6
1286->10.9.11.17:4443) tun_id=0.0.0.0 from port3. flag [S], seq 2505740766, ack 0, win 64240"
2024-11-27 12:27:03 id=65308 trace_id=1 func=init_ip_session_common line=6047 msg="allocate a new session-0000059a"
2024-11-27 12:27:03 id=65308 trace_id=1 func=__vf_ip_route_input_rcu line=1990 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
2024-11-27 12:27:03 id=65308 trace_id=1 func=__iprope_tree_check line=535 msg="gnum-100004, use addr/intf hash, len=4"
2024-11-27 12:27:03 id=65308 trace_id=1 func=get_new_addr line=1213 msg="find SNAT: IP-10.9.11.17(from IPPOOL), port-61286"
2024-11-27 12:27:03 id=65308 trace_id=1 func=fw_local_in_handler line=615 msg="iprope_in_check() check failed on policy 0, drop"
2024-11-27 12:27:03 id=65308 trace_id=2 func=print_pkt_detail line=5862 msg="vd-root:0 received a packet(proto=6, 192.168.10.2:61287->10.9.11.17:4443
) tun_id=0.0.0.0 from port3. flag [S], seq 214332243, ack 0, win 64240"
2024-11-27 12:27:03 id=65308 trace_id=2 func=init_ip_session_common line=6047 msg="allocate a new session-0000059b"
2024-11-27 12:27:03 id=65308 trace_id=2 func=__vf_ip_route_input_rcu line=1990 msg="find a route: flag=80000000 gw-0.0.0.0 via root"
2024-11-27 12:27:03 id=65308 trace_id=2 func=__iprope_tree_check line=535 msg="gnum-100004, use addr/intf hash, len=4"
2024-11-27 12:27:03 id=65308 trace_id=2 func=get_new_addr line=1213 msg="find SNAT: IP-10.9.11.17(from IPPOOL), port-61287"
2024-11-27 12:27:03 id=65308 trace_id=2 func=fw_local_in_handler line=615 msg="iprope_in_check() check failed on policy 0, drop"
If the above debug and sniffer outputs match, verify if the ssl.root interface is up or not as this would indicate that it is down. After, set the ssl.root interface up again using the following CLI commands:
config system interface
edit ssl.root
set status up <- Set the status to enable.
end
Once done then now the users can connect to SSL VPN.
|
