on - edited on by
JimmyPackets
Problem this snippet solves:
Goal
This snippet allows you to use "identity based" rules on a CheckPoint firewall to manage the permissions for users connected by SSL VPN with F5 APM.
Context
Usually, when deploying SSL VPN with F5 APM, you need to use F5 ACL to manage the permissions for the VPN users defining which user or group is allowed to reach which servers or networks. These rules may be duplicates of existing rules implemented in the core firewall of the company. Since the mappings (username, assigned VPN IP) is known only by F5, it is impossible for the core firewall to apply the proper filtering based on users identity.
The idea with this snippet is to be able to manage all the rules centrally on the CheckPoint firewall such as the following :
- User "Paul Anderson" is allowed to reach the network 10.10.1.0/24
- User "Robert Schmitt" is allowed to go everywhere except 10.10.2.0/24
- Active Directory group "Admins" is allowed to go everywhere on TCP ports 443 and 22
This snippet allows this kind of rules defined in a CheckPoint gateway to work also when the users are connected with F5 APM SSL VPN.
How it works
We are using the new CheckPoint R80 Web API to spread the association (username, assigned VPN IP) to the CheckPoint gateway. Indeed, the VPN connection follows the following steps :
- The user "Paul Robert" connects the F5 SSL VPN (through the Edge Client or the browser helper)
- The user "Paul Robert" is given an IP by F5 within the "lease pool" : let's say 192.168.1.13
-
F5 sends an HTTP request to the CheckPoint Identity Awareness Web API containing the association :
- 192.168.1.13 --> "Paul Robert"
- When Paul generates traffic through the VPN, this traffic is seen as coming from the source IP 192.168.1.13 from the CheckPoint firewall point of view. The firewall is able to apply the proper "identity based rules" because it knows that 192.168.1.13 is actually "Paul Robert"
How to use this snippet:
Requirements
- APM module provisioned on F5
- SSL VPN service already configured with APM
-
Import the iRule "HTTP Super Sideband Requestor" on your F5
- Download here
- This iRule must be named "HSSR" and must be in the partition "Common"
- CheckPoint Gateway R80 with the blade Identity Awareness enabled
- Existing firewall rules based on identity
CheckPoint Identity Awareness Web API
By default, the WebAPI is not enabled in a CheckPoint gateway, you need to first configure it. The configuration is simply setting up which source IP are allowed to use the API and defining a secret for each client. It is done in the gateway object from the Smart Console :
Here I configured my F5 as a WebAPI client with the secret "Fr38N....." Once the configuration is done, you need to install the policy on the gateway to apply the configuration.
To validate the WebAPI is working, you can use the following bash command on F5 :
curl -k -v --data '{ "shared-secret":"<api_secret>", "ip-address":"1.2.3.4", "user":"testuser1" }' https://<checkpoint_gw_ip/_IA_API/v1.0/add-identityThis command sends the association (IP : "1.2.3.4" --> User: "testuser1"). If successful, you should get the following message from the gateway :
{
"ipv4-address" : "1.2.3.4",
"message" : "Association sent to PDP."
}F5 configuration
Once you've validated the CheckPoint WebAPI is working and the F5 SSL VPN is ready, the needed configuration to integrate F5 with CheckPoint is composed of the 4 following steps :
-
Create a new pool
- Pool member: CheckPoint gateway IP / port 443
- Monitoring TCP
-
Create a new local virtual server
- Type: standard
- Destination : A fake, non existing IP address (such as 1.1.1.1 for example)* Port : 443
- Server SSL profile : serverssl-insecure-compatible
- Pool : previously created pool
- Source address translation: Automap (if needed)
-
Import the iRule in this snippet with the following adaptations :
- Change
with your WebAPI secret<secret_api> - Change
with the name of the previously created virtual server<vs_name>
- Change
- Add this iRule to your existing SSL VPN virtual server
Testing
After having applied the iRule, every new VPN connection should append the following line in the log file /var/log/ltm on F5 :
VPN : Publishing VPN IP in CheckPoint identity - SUCCESSMoreover, all your existing "identity based rules" in CheckPoint must now work with clients connected through the F5 VPN.
Notes
For this configuration we made two assumptions :
- The "network access" object for the VPN is not doing any SNAT (SNAT Pool: none). Indeed, if we are using "Automap" for the network access, all the connected clients are hidden behind the same IP, so there is no way to identify the users outside of F5.
- In the iRule, we suppose the username to send to CheckPoint is present in the APM variable "session.logon.last.username". If it's not your case, you need to adapt the iRule by changing this variable name.
Code :
when RULE_INIT {
## Secret configured on CheckPoint to authenticate the F5 to the Web API
set static::checkpoint_api_secret ""
}
when CLIENT_ACCEPTED {
ACCESS::restrict_irule_events disable
}
when HTTP_REQUEST {
# Thx to John Alam for this way to get assigned VPN IP
# https://devcentral.f5.com/s/questions/how-do-i-record-the-ip-assigned-to-a-client-after-login
if { [HTTP::uri] starts_with "/myvpn?sess=" } {
after 5000 {
set api_username [ACCESS::session data get session.logon.last.username]
set vpn_ip [ACCESS::session data get session.assigned.clientip]
set jsonBody "{ \"shared-secret\":\"$static::checkpoint_api_secret\", \"ip-address\":\"$vpn_ip\", \"user\":\"$api_username\" }"
set sts [call /Common/HSSR::http_req -virt /Common/ -uri "http://checkpoint.webapi.local/_IA_API/v1.0/add-identity" -method POST -body $jsonBody -rbody apiResp]
if { $apiResp contains "Association sent to PDP" } {
log local0. "VPN : Publishing VPN IP in CheckPoint identity - SUCCESS"
} else {
log local0. "VPN ERROR : Failed to publish the VPN IP in CheckPoint Identity : $apiResp"
}
}
}
} Tested this on version:
13.0
