- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Fortigate local authentication for external users not working
Hello,
I am facing a difficulty where the firewall is not showing the login page so that users can insert their login credentials.
<Internet Users(40.126.25.65)>--------<(12.12.12.12)Fortigate(10.10.10.10)>------------<(192.168.100.2)server>
On the FortiGate, there are users, placed in a user group, and the group is assigned to a VIP server policy.
The idea is that the external users enter the following link https://publicIP:8443, and then get to authenticate, but the login page does not appear.
RULE test:
zone src untrust
zone dst trust
source all + user group
destination VIP
server certificate
service all
config user setting
set auth-type http https ftp telnet
set auth-cert ''
set auth-ca-cert ''
set auth-secure-http disable
set auth-http-basic disable
set auth-ssl-allow-renegotiation disable
set auth-src-mac disable
set auth-on-demand implicitly
set auth-timeout 5
set auth-timeout-type idle-timeout
set auth-portal-timeout 3
set radius-ses-timeout-act hard-timeout
set auth-blackout-time 0
set auth-invalid-max 5
set auth-lockout-threshold 3
set auth-lockout-duration 0
set per-policy-disclaimer disable
set auth-ssl-min-proto-version default
unset auth-ssl-max-proto-version
set auth-ssl-sigalgs all
end
config authentication scheme
edit "Rev_Proxy"
set method basic
set user-database "local-user-db"
next
end
config authentication rule
edit "Rev_Proxy"
set status enable
set protocol http
set srcintf "z-untrust"
set srcaddr "all"
set ip-based disable --------- changed for testing but no luck
set active-auth-method "Rev_Proxy"
set web-auth-cookie disable
set transaction-based disable
set web-portal enable
set comments ''
next
end
Even with a user group in the rule:
func=__iprope_user_identity_check line=1825 msg="ret-no-match" then it matches the deny policy. No much idea why the firewall won't show the login page when external users are trying the link https://publicIP:8443...?
- Labels:
-
FortiGate
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
if you configure the auth system and policy ok and you want to manually enter login page
please using this : https://publicIP:8443/login?
pls notice that the login page only available when at least 1 firewall policy allow the usergroup to access int/out resource ...
Created on ‎12-15-2023 07:33 AM Edited on ‎12-15-2023 09:28 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
config firewall policy
edit 2
set name "vs-https-half"
set srcintf "z-untrust"
set dstintf "z-trust"
set action accept
set srcaddr "all"
set dstaddr "vs-https-half" -----VIP
set schedule "always"
set service "s-tcp-8080" "s-tcp-8443"
set utm-status enable
set inspection-mode proxy
set ssl-ssh-profile "Deep-Forti-LB"
set logtraffic all
set nat enable
set groups "Groupe_Reverse_Proxy"
next
end
authentication part is as I mentioned above.
Also to add to the scenario, is for that specific rule the user needs to authenticate to be able to reach the server. still not working with https://publicIP:8443/login?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Nitish,
do make sure that the users can correctly trigger the captive portal the FortiGate is supposed to show. How it works from client perspective:
- DNS for some external FQDN, ideally HTTP unencrypted captive portal detection site (to get the IP for the external resource)
- HTTP connect to that IP
- FortiGate blocks it and redirects with HTTP response 302 or 303, or in later versions with HTTP 200. The response contains the redirect URL (FQDN:1000 for HTTP, FQDN:1003 for HTTPS).
- optional: DNS for the redirect URL
- HTTP connect to that IP (the FortiGate)
The best start is then a plain packet capture on the client to see if DNS works so the client can contact something outside the firewall and the FortiGate can block and redirect.
Best regards,
Markus
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
yes I was making the test myself from outside(on internet), i reached the firewall, and I also tried the captive portal with the same configuration I shared regarding the authentication with the captive portal activated on the interface level, but no luck, very strange maybe will open a ticket with Fortinet, but working to include LDAP auth for the time being till the issue with local user authentication is resolved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I do not use portal , but i try to configure on my router. it works
pls check the config section
config user setting
set auth-type http https ftp telnet
set auth-cert ''
set auth-ca-cert ''
set auth-secure-http disable
set auth-http-basic disable
==>change to
config user setting
set auth-type https
set auth-cert "YourCert"
set auth-ca-cert ''
set auth-secure-http enable
set auth-http-basic disable
default port 1000 and 1003 for auth portal ,but you may change to 8443 and it's ok
config system global
set auth-cert "YourCert"
set auth-http-port 1000
set auth-https-port 8443
end
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
still same behavior func=__iprope_user_identity_check line=1825 msg="ret-no-match" then it matches policy 0 and the traffic is dropped.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hey Nitish,
a maybe stupid question, but can you please double-check:
- in your configuration, you have an authentication rule snippet
-> these are used for explicit proxy and ZTNA, not regular firewalll policies
-> for authentication in regular firewall policies, FortiGate can trigger a captive portal implicitly if none is defined on the ingress interface
- I don't see a firewall policy snippet?
Can you please try the following?
-> disable captive portal on interface
-> disable or delete the authentication rule
-> create a firewall policy from WAN->LAN with destination VIP address object
-> add the intended user group to this policy
-> ensure there is no other policy with the same WAN->LAN and VIP object
-> the 'config user setting' bits would still apply to captive portal triggered this way
Have the users try to access the external IP of the VIP; they should match the intended policy, and as a user group is set in the policy, this should trigger captive portal without needing to access it directly
