Captive portal bypass

[ccscott]

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?

[pulukas]

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.

[panos]

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.

[ccscott]

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.

[Art]

Howdy,

   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?

[ccscott]

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.

[DJGilm]

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.

[cpainchaud]

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