Restrict Access to WAN Network PANOS9.0.x

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Restrict Access to WAN Network PANOS9.0.x

L1 Bithead

Hi,

 

We're looking to restrict access to our network in AWS on the other side of an S2S VPN. From the research i've done it looks like i can set up restrictions on the tunnel using User-ID and Captive Portal. https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/user-id/enable-user-id.html and  https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/user-id/map-ip-addresses-to-users/map-ip-a....

 

I can roughly understand what i need to do in order to set up User-ID using AD security groups, but i'm concerned that it will only affect HTTP Traffic or will end up being set for all traffic over that interface regardless of whether it's for that particular Tunnel or not.

 

Is it possible to set up User-ID/Captive Portal to only restrict access to a specified tunnel? The access required for Authorised users is HTTP, HTTPS, SSH and MySQL and is a mixture of On-Premise and Global Protect Users (around 14 Users will access).

 

Any advice on how i should go about doing this would be much Appreciated.

2 REPLIES 2

Hi @MP2021 ,

If I understand you correctly you need to restrict access based on user identification, correct?


When it comes to user id you may want to think it as two separate components:

- User-to-IP mapping - from where firewall can gather information which ip to which user it is corresponding

- User group mapping - if you plan to use user groups (preferable), how the firewall will known which user in which user group it belongs.

 

I would say the most critical component is the user-to-ip mapping, and great think about PAN FW is that support multiple ways to gather this information.

- GlobalProtect - this is the simplest way, because when connecting to GP user is authenticating and FW is allocating IP for that user from the IP pool. So FW already have the information user-to-ip. In this case you only need Group Mapping, so instead of putting usernames in the rules you can put user group

- User-ID agent and agentless: in nutshell both ways is to read your DC security logs and parse the login and logout events. When user is connected inside your network and try to login to his PC. PC will authenticate the user agains the domain controller, which will create log containing username and ip address of the machine which is requesting the authentication. Once these logs are parsed your FW will have user-to-ip mapping

- Caprive Portal - if you don't want to have full user-id agent deployment and you don't have any other source, you can use the captive portal to aks the user to authenticate. That way FW again will be able to mapp the ip address with the authenticated username.

- There are other ways as well, but I wouldn't focus on them for this discussion.

 


@MP2021 wrote:

I can roughly understand what i need to do in order to set up User-ID using AD security groups, but i'm concerned that it will only affect HTTP Traffic or will end up being set for all traffic over that interface regardless of whether it's for that particular Tunnel or not.

 

Is it possible to set up User-ID/Captive Portal to only restrict access to a specified tunnel? The access required for Authorised users is HTTP, HTTPS, SSH and MySQL and is a mixture of On-Premise and Global Protect Users (around 14 Users will access).


Two clarifications here:

- Yes you can have captive portal/authentication policy only for specific IPsec tunnel. To enforce captive portal you are configuring authentication poliy rule. Similar to security rule you are configuring source, destination address and zone. My recommendetions is to use separate zones for each IPsec tunnel. This gives you flexability when defining your rule, because you can simply filter by destination zone.

- Authentiction policy rule does not eliminate the need of security rule. You still need to have security rule that will allow that traffic. The purpose of the auth rule is to enfoce captive portal and collect user-to-ip mapping. So what protocols/traffic will be allowed is up to you, what will be added to the security policy.

 

What you probably confuses you is that authentication rule can enfoce captive portal only for HTTP/S traffic. This means that if user tries to access your vpn tunnel with SSH or SQL and there is no user-to-ip mapping for his source ip, FW will simply block him = because he does not match the security rule and the authentication policy is not able to enforce captive portal. This simply means that when users wants to connect to AWS they need first to open HTTP, in order for the FW to enforce the captive portal and collect user-ip mapping, after that they can use any other protocol, because they are already authenticated.


@aleksandar.astardzhiev wrote:

If I understand you correctly you need to restrict access based on user identification, correct?


Yes, I'm trying to restrict access to our AWS Network from on-premise using the PAN Firewall.

 


@aleksandar.astardzhiev wrote:

 

Two clarifications here:

- Yes you can have captive portal/authentication policy only for specific IPsec tunnel. To enforce captive portal you are configuring authentication poliy rule. Similar to security rule you are configuring source, destination address and zone. My recommendetions is to use separate zones for each IPsec tunnel. This gives you flexability when defining your rule, because you can simply filter by destination zone.

 

- Authentiction policy rule does not eliminate the need of security rule. You still need to have security rule that will allow that traffic. The purpose of the auth rule is to enfoce captive portal and collect user-to-ip mapping. So what protocols/traffic will be allowed is up to you, what will be added to the security policy.

 

What you probably confuses you is that authentication rule can enfoce captive portal only for HTTP/S traffic. This means that if user tries to access your vpn tunnel with SSH or SQL and there is no user-to-ip mapping for his source ip, FW will simply block him = because he does not match the security rule and the authentication policy is not able to enforce captive portal. This simply means that when users wants to connect to AWS they need first to open HTTP, in order for the FW to enforce the captive portal and collect user-ip mapping, after that they can use any other protocol, because they are already authenticated.


So if i have this correct i will need to do the following:

  1. Set up a separate Zone for the IPSec Tunnel/s
  2. Set up User Group Mapping
  3. Configure Authentication Policy Rule with Captive Portal - Set Destination as the new Zone

And for users to authenticate their access, all they'll need to do is navigate first to HTTP/S to be caught by the captive portal  - is there a way we can set a static address/URL for the captive portal? Something i could push out to the relevant users such as a desktop shortcut or favourites link.

 

If I were to use the User-ID Agent you mentioned before, am i right in saying that it would need to be turned on for everything that connects through the firewall?

 

Also if we have some devices that use service accounts to send data through the tunnel, i'm assuming that they would be blocked as well?

 

Lastly would the user id restrictions be done bi-directionally in the tunnel or only affect traffic initiated on the side of the PAN Firewall?

  • 1765 Views
  • 2 replies
  • 0 Likes
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!