Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 38 subscribers
  • Views 20763 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Issues With Captive Portal Authentication

EthanMecham

A few weeks ago there was a question asked about how to make the captive portal authentication appear. The problem was resolved by making sure that after your policy that requires user based authentication, you had a network rule to drop all traffic. This worked for me and I have successfully been using the captive portal. However, I would like to know if a rule like this is required after every option. In my case, I would like a policy that applies to me individually, then to my wife and so on. I do this by making the source network the mac address list of our respective devices. However, it seems redundant and odd to need a network rule directly after each individual policy to force the captive portal. This seems like more of a work around instead of a feature. 

Are there any obvious reasons why we should need this? Comparing it to the UTM (I know they're two very different firewalls) you simply needed to say that you wanted browser authentication on that specific profile and you were done. 



This thread was automatically locked due to age.
  • 0
    I can try to answer this from what i think i understood from your question, you do not need a drop policy for every user based policy, there can be one implicit drop policy from lan to wan and on top of it you can have any number of identity based rules which will serve the captive portal. You need just one drop rule in the bottom most policy for the captive portal to be displayed.
  • 0 in reply to Kranthi

    From what I've been able to test tonight, this is partially true. This is my scenario: The first policies I apply are watching for my MAC Address and then when it sees requests from my MAC address it will challenge me to sign in. The next policy will be for guest users (basically anything that I don't check for with MAC addresses). Originally, I had this guest policy applying to the whole network (even the part of the network that my Macbook Pro is a part of). When I had these two rules and then a rule to drop all from LAN --> WAN, it wouldn't challenge me. For some reason it would automatically put me on the Guest profile. To fix it, I made it so the Guest policy only watched for addresses in the DHCP range. e.g. 10.5.10.128/25. All of my personal addresses would be in the 10.5.10.0/25 (where my Macbook is at) portion of the network and statically assigned. It then began to challenge me since "Ethan" was the only policy that matched the source criteria. Hopefully that made some sense...this is pretty much what I'm doing on my UTM...but all of this on the XG seems pretty difficult. 

    The other solution I found was leaving the guest network policy watching the whole 10.5.10.0/24 source network and putting a drop policy specifically for "Ethan" right after Ethan and before guest. 

    So, I think this statement:

    there can be one implicit drop policy from lan to wan and on top of it you can have any number of identity based rules which will serve the captive portal.
      is conditionally true as long as each policy only applies to one unique source with no overlap. (This is not typical considering every firewall I've ever know will apply the first policy that it matches and then forget the rest)

    Is this just the new way of policies that they are trying to implement with XG? Thanks!

Unfiltered HTML