Identity Policy fall-through

[gilfalko]

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

[emnoc]

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]

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]

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]

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]

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]

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

[ede_pfau]

The problem is (IIUC) that the captive portal doesn't show up. It's not that the user fails to authenticate and then falls through.

[gilfalko]

ede_pfau wrote:

The problem is (IIUC) that the captive portal doesn't show up. It's not that the user fails to authenticate and then falls through.

precisely!

[xsilver_FTNT]

ede_pfau wrote:

The problem is (IIUC) that the captive portal doesn't show up. It's not that the user fails to authenticate and then falls through.

turn on captive portal on interface + as local + define user group

optionally set exempt list so for those destinations captive portal will not pop up

then make fw policy specific as you need + set there same group as in captive portal

done

works in my lab on 5.2.3 B0670 FG-VM64

[gilfalko · Accepted solution]

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