Hi Everyone.
Considering the next network layout
Internet MPLS
|| ||
||=====[port19]--|FG 1500D|--[port "Hacia_MPLS] =====||
|
[port "InterRed-NoSegura]
||
||
|Router|
||
============================================
| | |
10.39.204.0/24 10.39.201.0/24 ........... 10.X.X.X/24
My Fortigate is therectly conected to 3 routers (Internet, MPLS and internar networks). Under internar network router there are several class A privet networks. I need to ask user from 10.39.204.0/24 network to authenticate with captive portal, so I create a policy like this with user restriction.
show firewall policy 82
config firewall policy
edit 82
set uuid 76b565ca-2b84-51e8-6883-360bdd8c3289
set srcintf "IntRed-NoSegura"
set dstintf "any"
set srcaddr "Red_10.39.204.0"
set dstaddr "all"
set action accept
set status enable
set schedule "always"
set service "ALL"
set groups "WiFI2"
set comments "CP TEST"
set global-label "Internet - DMZ - MPLS"
set auth-cert "*.unap.cl"
set auth-redirect-addr "fap-cp-test.unap.cl"
next
end
The idea is to, when a user connects, redirect its web browser to https://fap-cp-test.unap.cl. Only users from WIFI2 group (correspond to a AD group) can authenticate.
There is a rule (policy-29) to permit any other network to be permited without user authentication with destination MPLS. This policy apply for any network under "InterRed-NoSegura" fw interface, so 10.39.204.0/24 is included. This rule is after policy-82.
show firewall policy 29
config firewall policy
edit 29
set uuid b6c8c4f4-0b46-51e7-5172-06fe5d2580b0
set srcintf "IntRed-NoSegura"
set dstintf "Hacia_MPLS"
set srcaddr "all"
set dstaddr "Red_172.19.88.0"
set action accept
set schedule "always"
set service "ALL_TCP" "ALL_UDP" "ALL_ICMP"
set utm-status enable
set comments "Acceso alumnos e invitados a servicios en Datacenter CDLV"
set global-label "Internet - DMZ - MPLS"
set av-profile "default"
set webfilter-profile "monitor-all"
set application-list "default"
set profile-protocol-options "default"
next
end
The problem is that policy-82 never match and traffic apply for policy-29 instead, so users don't need to authenticate to navigate.
This is an example. Host 10.39.204.254 is pinging to 172.19.88.86 which is reachable through MPLS.
Aplying an snifer shows
diag sniffer packet any 'host 10.39.204.254 and icmp' 4
interfaces=[any]
filters=[host 10.39.204.254 and icmp]
15.376403 IntRed-NoSegura in 10.39.204.254 -> 172.19.88.86: icmp: echo request
15.376513 Hacia_MPLS out 10.39.204.254 -> 172.19.88.86: icmp: echo request
15.376516 port19 out 10.39.204.254 -> 172.19.88.86: icmp: echo request
15.403327 Hacia_MPLS in 172.19.88.86 -> 10.39.204.254: icmp: echo reply
15.403364 IntRed-NoSegura out 172.19.88.86 -> 10.39.204.254: icmp: echo reply
15.403366 PChannel2_Wi_Fi out 172.19.88.86 -> 10.39.204.254: icmp: echo reply
15.403370 port23 out 172.19.88.86 -> 10.39.204.254: icmp: echo reply
Flow trace ...
id=20085 trace_id=115 func=print_pkt_detail line=4471 msg="vd-root received a packet(proto=1, 10.39.204.254:31234->172.19.88.86:8) from IntRed-NoSegura. code=8, type=0, id=31234, seq=1."
id=20085 trace_id=115 func=init_ip_session_common line=4624 msg="allocate a new session-01568e20"
id=20085 trace_id=115 func=vf_ip4_route_input line=1596 msg="find a route: flags=00000000 gw-10.39.227.250 via Hacia_MPLS"
id=20085 trace_id=115 func=fw_forward_handler line=686 msg="Allowed by Policy-29:"
id=20085 trace_id=115 func=ids_receive line=239 msg="send to ips"
If I unset group "WiFI2" from policy-82, traffic match it.
id=20085 trace_id=135 func=print_pkt_detail line=4471 msg="vd-root received a packet(proto=1, 10.39.204.254:31329->172.19.88.86:8) from IntRed-NoSegura. code=8, type=0, id=31329, seq=1."
id=20085 trace_id=135 func=init_ip_session_common line=4624 msg="allocate a new session-01582fa5"
id=20085 trace_id=135 func=vf_ip4_route_input line=1596 msg="find a route: flags=00000000 gw-10.39.227.250 via Hacia_MPLS"
id=20085 trace_id=135 func=fw_forward_handler line=686 msg="Allowed by Policy-82:"
So, the problem is that user are never asked to authenticate so rule will never match (vicious circle).
By the way, I did susessfully set up policy base user authentication with a network directly connected to the Fortigate (didn't set up captive portal security at interface level). Policy for this case was quite similar and it works asking user to authenticate with a browser login page.
config firewall policy
edit 61
set uuid 2fb5c0da-d90d-51e7-2e5c-f9d7b4cd1de7
set srcintf "WiFi-TEST"
set dstintf "any"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set groups "WiFI2"
set comments "Pruebas Captive Portal y WiFi Fortinet"
set auth-cert "*.unap.cl"
set auth-redirect-addr "fap-cp-test.unap.cl"
set nat enable
next
end
Can you help me to understand what am I doing wrong?
Thanks in advance.
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Hi there,
If a policy is set with user-auth while the other policy under it without user-auth enabled, and all the other conditions are same, then it will match the second policy. Here is an example:
===
edit 2 set uuid 8996b36c-2ba1-51e7-9b38-776f1bcac321 set srcintf "any" set dstintf "any" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "myhttps" set groups "kgp" set users "kurt" set nat enable next edit 1 set uuid ca4b18b4-2a19-51e7-6f66-be5f38e11d54 set srcintf "any" set dstintf "any" set srcaddr "all" set dstaddr "all" set action accept set schedule "always" set service "myhttps" set nat enable next
===
So above two policies are almost same except #2(the first) has groups and users auth. In this case, the traffic will never match #2 but #1. It prefers to pick up the one without auth first. To make it work, try adding "set service-negate enable" on #1(second policy).
Thanks.
Yes, the idea is similar. The combination "myhttps"+"service-negate enable" means any traffics are allowed by #1 but HTTPS. Therefore, the HTTPs auth traffic will select #2,the first policy.
ericli wrote:Hi UNAP,
Before configuring the FortiGate unit, the AD server must be configured and have the msNPAllowDialin attribute set to “TRUE” for the users in question. If not, those users will not be able to properly authenticate.
I did add a domain controller as source of authentication, and it works for other cases (didn't set the msNAPAllowDialin property, taught). As I said, if I apply the same kind of rules but for traffic coming from an interface directly connected, it works.
For example, I defined this test interface.
config system interface
edit "WiFi-TEST"
set vdom "root"
set ip 10.39.201.1 255.255.255.0
set allowaccess ping
set description "Prueba portal cautivo Fortigate"
set device-identification enable
set snmp-index 59
set interface "PChannel1_Core"
set vlanid 1201
next
end
Whit this rule.
config firewall policy
edit 76
set uuid 2d176ad0-18b0-51e8-4598-bc7bc0015c5c
set srcintf "WiFi-TEST"
set dstintf "PChannel4"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set groups "WiFI2"
set comments "Salida a Internet desde WiFi Test"
set auth-cert "*.unap.cl"
set auth-redirect-addr "fap-cp-test.unap.cl"
set nat enable
set ippool enable
set poolname "REUNA_NATpool"
next
end
Then when I try open a web browser from a test client, it show the captive portal login page, asking for credentials. Using active directory domain credentials works an navigation is allowed.
The problem is that when I try to match a source network which is not directly connected to the fortigate (comes from a neighbor router) it won't work if I add the group policy property.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1705 | |
1093 | |
752 | |
446 | |
230 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.