Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
UNAP
New Contributor

Traffic won't match a desire policy with user security enabled

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.

 

 

 

2 Solutions
kurtli_FTNT

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. 

View solution in original post

kurtli_FTNT

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.

View solution in original post

10 REPLIES 10
ericli_FTNT
Staff
Staff

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.

 

Then can you collect the output of this command, while keep traffic running thru:

 

diag firewall iprope list | grep "policy index=82" -A11

 

diag firewall iprope list | grep "policy index=29" -A11

 

Also, if you could, please try to sniffer packet to verify if the authentication granted correctly.

UNAP

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.

 

kurtli_FTNT

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. 

UNAP

kurtli_FTNT wrote:

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:

 

Thanks for the explanation, I thought that fortigate would evaluate traffice top-down and firts match should stop processing.

 

kurtli_FTNT wrote:

To make it work, try adding "set service-negate enable" on #1(second policy).

 

How could negating the service would make it works?

 

Thanks!

 

 

UNAP
New Contributor

Did you mean "set srcaddr-negate enable" as stated here http://kb.fortinet.com/kb/documentLink.do?externalID=FD36095 ?

kurtli_FTNT

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.

UNAP

Thanks, playing with srcaddr-negate works grate for my case.

 

UNAP

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.

 

UNAP

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.

 

Labels
Top Kudoed Authors