Skip to main content
gilfalko
gilfalko
New Member
August 26, 2015
Solved

Identity Policy fall-through

  • August 26, 2015
  • 12 replies
  • 19491 views

Hey,

I've been playing around with the new User-Source based policies but unable to make them work.

I have the following policy which is placed at the very top of the list but it just doesnt work (see attached image).

Instead, it falls through to another policy I have that allows internet for the entire office.

What am I missing?

Thanks

Gil

 

    Best answer by gilfalko

    I just wanted to update that after speaking to a Fortigate representative I finally managed to solve this issue.

    This has nothing to do with Captive Portal just for the record.

     

    The reason that my non-auth NAT policy was always getting hit is because all non-auth policies take precedence over User Source based policies. Yes even if the non-auth policy is at the bottom of your policy list.

    Once I made sure that SW_INTERCONNECT (gil's PC, gilfalko user) was the ONLY policy using gil's PC as the source of the communication, the forti portal popped out immediately. Well, I also had to erase all sessions from my station first.

     

    I hope that helps someone out there.

    Peace

    12 replies

    emnoc
    emnoc
    New Member
    August 26, 2015

    The diag debug flow would be your best friend,  but I would 1st check the firewall address src for that gil laptop source.

     

    2nd, i would substitute a new policy ( & re-ordering ) using something under your control for testing.

     

    gilfalko
    gilfalkoAuthor
    New Member
    August 26, 2015

    emnoc wrote:

    The diag debug flow would be your best friend,  but I would 1st check the firewall address src for that gil laptop source.

     

    2nd, i would substitute a new policy ( & re-ordering ) using something under your control for testing.

     

    Thanks for the reply.

    I actually did run a "diag debug flow" and all it showed me is that the policy being "hit" is the one I have that enables Internet outbound traffic for the entire office. SW_Interconnect (ALL) --> WAN1 (ALL) + NAT to be exact.

    The source for gil's laptop (my laptop) is 100% correct as I use it for all sorts of other things.

     

    Substitute what with what? I can do whatever I want right now as no one's in the office :D

     

    emnoc
    emnoc
    New Member
    August 26, 2015

    So is the fw-policy order correct?

     

    If  the SRC is in that policy-id " gils laptop " is correct , than it should have been matched.

     

    gilfalko
    gilfalkoAuthor
    New Member
    August 26, 2015

    emnoc wrote:

    So is the fw-policy order correct?

     

    If  the SRC is in that policy-id " gils laptop " is correct , than it should have been matched.

     

    This policy is the **first** in the top-down line. gil's laptop is indeed correct.

    Yet I'm still getting no auth portal when attempting to surf the web.

     

    emnoc
    emnoc
    New Member
    August 26, 2015

    I believe  your fw-policy ids  ordering is not correct, or some thing else is not in wack with the src and/or user group defined. When you execute a show firewall policy ?  from cli, what policy-id is listed 1st  ? If you change this to a deny, does it block your host ( that would validate if  this is being match by order  & for that source )

     

    Here's a posting for authentication, but this is proabably not going to help but I still would run diag debug app authd -1

    http://socpuppet.blogspot...-policies-trouble.html

     

    edit to add ; a show firewall policy xxx  might shed some light also, where xxx is our fwpolicy-id that you think should be matched with identity enabled.

    gilfalko
    gilfalkoAuthor
    New Member
    August 26, 2015

    I uploaded the result of "show firewall policy" and the matching first policy I see in the GUI.

    Also here's the rule itself taken from the CLI:

     

    config firewall policy edit 58 set uuid 7dae3ef6-48d8-51e5-86b8-592fb2c673e7 set srcintf "SW_Interconnect" set dstintf "wan1" set srcaddr "Gils Laptop" set dstaddr "all" set action accept set schedule "always" set service "ALL" set logtraffic disable set fsso enable set users "artur" set nat enable next end

     

    Oh and I know for a fact that that policy is not being matched or else i'd be getting that portal :\

    emnoc
    emnoc
    New Member
    August 26, 2015

    I don't see set identity in your firewall policy. Take a look at that eg blog.

     

    set identity-based enable

     

    what version fortiOS version.

    gilfalko
    gilfalkoAuthor
    New Member
    August 26, 2015

    emnoc wrote:

    I don't see set identity in your firewall policy. Take a look at that eg blog.

     

    set identity-based enable

     

    what version fortiOS version.

    Your link was broken but I found it eventually.

    The option does not exist in 5.2.3.

    It was the first thing I tried when I read it.

    I only have "set identity-based-route"

     

    xsilver_FTNT
    Staff
    xsilver_FTNT
    Staff
    August 27, 2015

    gilfalko wrote:

    emnoc wrote:

    I don't see set identity in your firewall policy. Take a look at that eg blog.

     

    set identity-based enable

     

    what version fortiOS version.

    Your link was broken but I found it eventually.

    The option does not exist in 5.2.3.

    It was the first thing I tried when I read it.

    I only have "set identity-based-route"

     

    Because in 5.2 when you add user group (set groups ..) you'll make it identity-based.

    emnoc
    emnoc
    New Member
    August 26, 2015

    Okay so in  .5.2x it's not required. 

     

    Did you enable auth protocols?

     

    e.g

     

    config user settings  

       set auth-type http telnet

    end

     

    gilfalko
    gilfalkoAuthor
    New Member
    August 26, 2015

    Http was missing

    but it had both https and telnet.

    I added http but that still doesnt cut it i'm afraid.

    I also cleared all sessions on the firewall just in case.

     

    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    August 27, 2015

    Have you allowed DNS for unauthorized users?

    Cf. Handbook, pg. 483:

    Access to HTTP, HTTPS, FTP and Telnet sites may require access to a domain name service. DNS requests do not trigger authentication. You must configure a policy to permit unauthenticated access to the appropriate DNS server, and this policy must precede the policy for Internet access. Failure to do this will result in the lack of a DNS connection and a corresponding lack of access to the Internet.

     

    This behavior has changed starting in v5.2.

    Adding the user (group) field in the policy is sufficient to trigger a captive portal IF the user has not been authenticated before (e.g. by using FSSO or RSSO).

    gilfalko
    gilfalkoAuthor
    New Member
    August 27, 2015

    ede_pfau wrote:

    Have you allowed DNS for unauthorized users?

    Cf. Handbook, pg. 483:

    Access to HTTP, HTTPS, FTP and Telnet sites may require access to a domain name service. DNS requests do not trigger authentication. You must configure a policy to permit unauthenticated access to the appropriate DNS server, and this policy must precede the policy for Internet access. Failure to do this will result in the lack of a DNS connection and a corresponding lack of access to the Internet.

     

    This behavior has changed starting in v5.2.

    Adding the user (group) field in the policy is sufficient to trigger a captive portal IF the user has not been authenticated before (e.g. by using FSSO or RSSO).

    If the behavior has changed, I guess I dont really need to add it, right?

    One way or another DNS resolution is being done on the same subnet without restrictions so it doesnt matter.

    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    August 27, 2015

    If the behavior has changed, I guess I dont really need to add it, right?

    You would not need a policy allowing DNS for all users if your DNS was located in the same subnet, that is, if DNS traffic would not traverse the firewall. You can check that easily from on your host (did you?).

     

    Another thing to check: services=ALL or services=ANY? I don't have any v5.2 machine at hand right now to check this.

    xsilver_FTNT
    Staff
    xsilver_FTNT
    Staff
    August 27, 2015

    Hello,

    if you are playing on 5.2 then fall-through-unauthenticated is default behavior, in contrary to 5.0. So if your user based policy is first, but followed by any non-identity-based policy which would allow the traffic anyway, then fall through will allow that and user will sneak through.

    Make sure that there is not another non-identity-based policy allowing the traffic. Best is that if user is not matching the identity policy it will be rejected by implicit deny (policy ID=0).

    Then it should start to work as you expect.

    Kind regards, Tomas

    Show more replies
    Terms & ConditionsAccessibility statement