Captive portal bypass

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Captive portal bypass

L2 Linker

Anyone familiar with a way to bypass captive portal for non-browser-based applications? Doing some testing with an eval unit from Palo alto and have configured agentless DC monitoring and using captive portal auth for a fallback. If a user hasn't already authenticated to captive portal it is blocking apps that go over port 80/443 such as ms-update, yum, etc. Anyway to workaround this other than exemption by ip address or url category?


L7 Applicator

The examples you mention here are recognized as applications in the Palo Alto world.  So you would just identify the list of approved applications and place that allow rule based on application before your captive portal.

You don't need to know ip addresses or ports, PanOS will recognize them from the app-id selected.

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center

L6 Presenter

You can write a rule for unknown users (inside policy source user - unknown)

so they can use the applications you want when they are not authenticated yet.

I've done just that but am still having issues.

Seems the issue I'm having with ms-update is related to the fact that part of the sessions are not identified as ms-update but instead ssl (seems to be just one of them)

  Out of the box yum works pretty well it seems but when extra repo's are configured on the linux machine it is not identified as yum.

I can verified that this traffic is being affected by captive portal because as soon as I disable the captive portal policy it works correctly.

Seems like windows doens't like the self-signed cert or redirect it sees when it hits cp.


   Is this traffic coming from specific workstations/servers/devices?  Also, are these 'sources' being "ignored" for the purpose of Captive Portal?

   Also, can these applications be run under "Service Accounts" that could then be handled using specific rules fo these specific service accounts?

I have no problem creating a no captive portal policy for certain servers and workstations. But we have quite a few macs that are not on the windows domain and the ones that are are not logging their ip/username combination for the firewall to learn from AD. Most windows users should be doing this through wsus server anyway. But the main issue is that the application identification is not working well enough for these apps to permit them through unless ssl/other application is also enabled for any user through basically a permit any any policy at the bottom of the rule base. This kind of goes against the postive enforcement approach that Palo Alto encourages. In fact it is much easier to block an app as you basically have to only break one part of it whereas you mush be able to identify and enable all flows/traffic with the postive enforcement approach.

I'm very impressed with PA firewalls in general. We use then in a few spots in our network already and are moving to them for our main enterprise firewall (I'm testing all of this on a test PA=5050 unit by the way). I have an SE working with me on this and if I were on a supported unit would just submit a ticket with support.

L1 Bithead

It's kind of an extra step but we set up a couple of User-ID agents to connect to our exchange servers. Even though our MAC users don't authenticate with AD they do pull email form exchange. They get mapped that way so they don't get captured by Captive Portal.

I would also recommend using Global Protect agent in internal mode to identify users immediatly.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!