CoreLogic is a configuration framework for Citrix ADC/NetScaler, compatible with all editions (Standard, Advanced/Enterprise, Premium/Platinum), aimed at standardising the application flow through the packet engine. More specifically, controlling access applications from L3 to L7 by extensive use of content-switching virtual servers.
- Standarization:
- Multiple engineers working on one configuration are forced to configure policies in the same way
- You can quickly get your bearing at someone else's configuration without having to rely heavily on documentation
- Documentation:
- It is easier to document and graph how an application is configured
- Focus on application-specific documentation
- Simplification:
- All "moving parts" are defined in a set of tables (key-value pairs)
- Security:
- All application (modules) must be configured explicitly. If the application (or application module) is not defined, it will not be allowed to pass through.
- Block access to application (modules) at L4-L7 based on client IP address
CoreLogic has knowledge of two zones, LAN and ANY, allowing you to define how a request will be handled if you're accessing the service from an internal network (LAN) or from the outside (ANY). This decision is based on the entries in a table, defining which networks are to be considered an "internal network".
CoreLogic also implements a basic ACL by allowing you to define whether content-switching virtual servers and load-balancing virtual servers have an IP allowlist or blocklist, thus restricting access to specific services. This decision is based on the entries in a table, defining which networks belong the the allowlist/blocklist.
Using the IP allowlist/blocklist functionality in combination with the content-switching flow control enables you to define complex access scenarios based on IP address in combination with L4-L7 data.
Given a URI https://www.netscalerrocks.com/packetengine/internals/documentation.php?section=rewrite
, we can identify specific components:
- Protocol: https
- FQDN (hostname): www.netscalerrocks.com
- URL: /packetengine/internals/documentation.php?section=rewrite
- URL Path: /packetengine/internals/documentation.php
- URL Query: section=rewrite
CoreLogic can differentiate following scenarios:
Scenario | Elements | Example |
---|---|---|
FULL | FQDN + URL Path | www.netscalerrocks.com/packetengine/internals/documentation.php |
SCND | FQDN + URL Path (first two elements) | www.netscalerrocks.com/packetengine/internals |
FRST | FQDN + URL Path (first element only) | www.netscalerrocks.com/packetengine |
FQDN | FQDN | www.netscalerrocks.com |
WILD | Wildcarded domain | *.netscalerrocks.com |
For each of the scenario's above, you can target different load-balancing virtual servers to access, redirect requests or block access.
Target Scenario | Action |
---|---|
Load-balancing virtual server | Pass the request to a load-balancing virtual server |
VS_CL1009_REDIR_301 | 301 Redirect to a defined location |
VS_CL1009_REDIR_301_KEEPPATH | 301 Redirect to a defined location while appending the original path to the redirect destination |
VS_CL1009_REDIR_301_SWITCH | 301 Redirect from http to https (or vice versa) on the same URI |
VS_CL1009_REDIR_302 | 302 Redirect to a defined location |
VS_CL1009_REDIR_302_KEEPPATH | 301 Redirect to a defined location while appending the original path to the redirect destination |
VS_CL1009_REDIR_302_SWITCH | 302 Redirect from http to https (or vice versa) on the same URI |
VS_CL1009_REDIR_307 | 307 Redirect to a defined location |
VS_CL1009_REDIR_307_KEEPPATH | 307 Redirect to a defined location while appending the original path to the redirect destination |
VS_CL1009_REDIR_307_SWITCH | 307 Redirect from http to https (or vice versa) on the same URI |
VS_CL1009_REDIR_308 | 308 Redirect to a defined location |
VS_CL1009_REDIR_308_KEEPPATH | 308 Redirect to a defined location while appending the original path to the redirect destination |
VS_CL1009_REDIR_308_SWITCH | 308 Redirect from http to https (or vice versa) on the same URI |
VS_CL1009_NOTFOUND_HTTP | Show a message that the page cannot be found |
VS_CL1009_BLOCKED_HTTP | Show a message that the request is blocked |
VS_CL1009_DROP_HTTP | Drop the request silently on L4 |
VS_CL1009_DROP_TCP | Drop the request silently on L4 |
VS_CL1009_RESET_HTTP | Do a hard reset on L4 |
VS_CL1009_RESET_TCP | Do a hard reset on L4 |
VS_CL1009_ACME_HTTP | Respond to ACME-challenge |
Notes:
- In case of a FQDN like customer.api.netscalerrocks.com, the wildcarded domain becomes *.api.netscalerrocks.com
- CoreLogic does not process URL queries or HTTP headers such as User-Agent
Open up a SSH connection to your Citrix ADC/NetScaler appliance, and copy-paste the contents of install.conf.
Alternatively you might want to copy the contents of install.conf into a configuration job template on Citrix ADM, and execute it from there.
None so far, it's a manual action due to dependencies. If any policy is still in use, it will fail to uninstall.
To create a new set of content-switching virtual servers, use the script in create_cs.conf.
- Replace
$TENANT
with a name of your choice, e.g. PUB012. - Replace
$IPADDRESS
with the actual IP address for the virtual server.
Note: It is important that the key for SM_CL1009_IP_CONTROL is in LOWERCASE: cs_$tenant_http --> cs_pub012_http.
For example:
add cs vserver CS_PUB012_HTTP HTTP 192.168.0.12 80 -cltTimeout 180
bind cs vserver CS_PUB012_HTTP -policyName NOPOLICY-REWRITE -priority 100901 -gotoPriorityExpression END -type REQUEST -invoke policylabel RWPL_CL1009_CS_REQ_CORE
bind cs vserver CS_PUB012_HTTP -policyName NOPOLICY-REWRITE -priority 100901 -gotoPriorityExpression END -type RESPONSE -invoke policylabel RWPL_CL1009_CS_RES_CORE
bind cs vserver CS_PUB012_HTTP -policyName RSP_CL1009_IP_CSTCP_NOTLISTED -priority 100901 -gotoPriorityExpression END -type REQUEST
bind cs vserver CS_PUB012_HTTP -policyName RSP_CL1009_IP_VSTCP_NOTLISTED -priority 100902 -gotoPriorityExpression END -type REQUEST
bind cs vserver CS_PUB012_HTTP -policyName RSP_CL1009_IP_CSTCP_ALLOWLIST -priority 100903 -gotoPriorityExpression END -type REQUEST
bind cs vserver CS_PUB012_HTTP -policyName RSP_CL1009_IP_CSTCP_BLOCKLIST -priority 100904 -gotoPriorityExpression END -type REQUEST
bind cs vserver CS_PUB012_HTTP -policyName RSP_CL1009_IP_VSTCP_ALLOWLIST -priority 100905 -gotoPriorityExpression END -type REQUEST
bind cs vserver CS_PUB012_HTTP -policyName RSP_CL1009_IP_VSTCP_BLOCKLIST -priority 100906 -gotoPriorityExpression END -type REQUEST
bind cs vserver CS_PUB012_HTTP -policyName CSP_CL1009_HTTP_FULL_LAN -priority 100901
bind cs vserver CS_PUB012_HTTP -policyName CSP_CL1009_HTTP_SCND_LAN -priority 100902
bind cs vserver CS_PUB012_HTTP -policyName CSP_CL1009_HTTP_FRST_LAN -priority 100903
bind cs vserver CS_PUB012_HTTP -policyName CSP_CL1009_HTTP_FQDN_LAN -priority 100904
bind cs vserver CS_PUB012_HTTP -policyName CSP_CL1009_HTTP_WILD_LAN -priority 100905
bind cs vserver CS_PUB012_HTTP -policyName CSP_CL1009_HTTP_ACME_ANY -priority 100910
bind cs vserver CS_PUB012_HTTP -policyName CSP_CL1009_HTTP_FULL_ANY -priority 100911
bind cs vserver CS_PUB012_HTTP -policyName CSP_CL1009_HTTP_SCND_ANY -priority 100912
bind cs vserver CS_PUB012_HTTP -policyName CSP_CL1009_HTTP_FRST_ANY -priority 100913
bind cs vserver CS_PUB012_HTTP -policyName CSP_CL1009_HTTP_FQDN_ANY -priority 100914
bind cs vserver CS_PUB012_HTTP -policyName CSP_CL1009_HTTP_WILD_ANY -priority 100915
bind cs vserver CS_PUB012_HTTP -lbvserver VS_CL1009_NO_SERVICE_HTTP
bind policy stringmap SM_CL1009_IP_CONTROL cs_pub012_http "list=blocklist;"
By default, all content-switching virtual servers are set to have a blocklist of IP addresses.
This means that all source IP addresses are allowed to access the content-switching virtual server, unless there is an entry in SM_CL1009_IP_CONTROL
.
To change the behavior of the content-switching virtual to be a allowlist, all you need to do is change the entry.
If you change the behavior to be a allowlist
, it results in all client IP addresses on the list to be blocked!
For example:
bind policy stringmap SM_CL1009_IP_CONTROL cs_pub012_http "list=allowlist;"
Notes:
- As stated before, it is important that the key for SM_CL1009_IP_CONTROL is in lowercase: cs_pub012_http.
- It is equally important not to omit the semicolon at the end as policies are looking for the value between
=
and;
to determine their action.
To add IP addresses or complete networks to the list, we need to provide additional entries in SM_CL1009_IP_CONTROL
.
Example:
- Content-switching virtual server
CS_PUB012_HTTP
can only provide access to a specified list IP addresses. - All clients from the sales network
192.168.0.0/24
must be allowed. - All clients from the development network
172.16.0.0/16
must be allowed. - An administrator with IP address
10.0.0.1
must be allowed.
bind policy stringmap SM_CL1009_IP_CONTROL cs_pub012_http "list=allowlist;"
bind policy stringmap SM_CL1009_IP_CONTROL "cs_pub012_http;any;192.168.0.0/24" "Sales"
bind policy stringmap SM_CL1009_IP_CONTROL "cs_pub012_http;any;172.16.0.0/16" "Development"
bind policy stringmap SM_CL1009_IP_CONTROL "cs_pub012_http;any;10.0.0.1/32" "Administrator"
Example:
- Content-switching virtual server
CS_PUB012_HTTP
was defined to have a blocklist. - Public IP addresses from Google DNS must be blocked.
- All clients from the sales network
192.168.0.0/24
must be blocked.
bind policy stringmap SM_CL1009_IP_CONTROL cs_pub012_http "list=blocklist;"
bind policy stringmap SM_CL1009_IP_CONTROL "cs_pub012_http;any;8.8.8.8/32" "Google DNS"
bind policy stringmap SM_CL1009_IP_CONTROL "cs_pub012_http;any;8.8.4.4/32" "Google DNS"
bind policy stringmap SM_CL1009_IP_CONTROL "cs_pub012_http;any;192.168.0.0/24" "Sales"
Configuring LAN networks is a similar procedure, but there are some differences to allowlisting/blocklisting. Whilst allowlisting/blocklisting happens for each and every specific content-switching virtual server, LAN networks apply to a collection of content-switching virtual servers with the same name.
Assume we have executed the complete create_cs.conf script to create the following content-switching virtual servers:
- CS_PUB012_HTTP
- CS_PUB012_SSL
- CS_PUB012_TCP
- CS_PUB012_STCP
- CS_PUB012_UDP
If we want to define a LAN network for CS_PUB012_HTTP, it will be considered a LAN network for all content-switching virtual servers of PUB012.
Example:
- All clients from the sales network
192.168.0.0/24
are considered to be internal clients on the LAN. - All clients from the development network
172.16.0.0/16
are considered to be internal clients on the LAN. - An administrator with IP address
10.0.0.1
is considered to be an internal client on the LAN.
bind policy stringmap SM_CL1009_IP_CONTROL "cs_pub012;lan;192.168.0.0/24" "Sales"
bind policy stringmap SM_CL1009_IP_CONTROL "cs_pub012;lan;172.16.0.0/16" "Development"
bind policy stringmap SM_CL1009_IP_CONTROL "cs_pub012;lan;10.0.0.1/32" "Administrator"
As you can see from the example above, the protocol of the content-switching virtual servers is omitted in the key of the entry.
Module processing on the Request:
- Content-Switching policies to determine which load-balancing virtual server to use
- Policies for clients on LAN networks (LAN)
- Policies for clients not on LAN networks (ANY)
- Responder policies: based on the current content-switching virtual server and selected load-balancing virtual server, check the allowlist/blocklist.
- Rewrite policies: adds/removes some headers to be used by the backend server, such as
X-Forwarded-For
andX-Forwarded-Proto
. - Pass the request to the selected load-balancing virtual server.
Module processing on the Response:
- Rewrite policies: adds/remove some headers for improved security.
If the selected load-balacing virtual server is OUT OF SERVICE
or DOWN
, content-switching policy processing will stop and the default load-balancing virtual server will be selected immediately.
- For HTTP,
VS_CL1009_NO_SERVICE_HTTP
will be used - For SSL,
VS_CL1009_NO_SERVICE_SSL
will be used.
Both have the same functionality built-in:
- If an entry in
SM_CL1009_CS_CONTROL
should have been used for the current protocol (HTTP/SSL), we know that the target load-balancing virtual server is down and aNO SERVICE
message will be shown. The HTTP response code is 503. - If an entry in
SM_CL1009_CS_CONTROL
is not found for the current request on HTTP, we know that the request is not allowed. We will lookup if there is an entry for SSL, and redirect if and entry is found. - If an entry in
SM_CL1009_CS_CONTROL
is not found for the current request on HTTP, nor for SSL traffic, we will respond with aNOT FOUND
message. and HTTP response code 404.
- For general TCP/UDP content-switching virtual servers, the connection will time out.
Having a fancy framework is one thing, but what it's all about are the applications and their modules.
Although you are here to use CoreLogic (or at least get to know it), you still have to complete some necessary steps which are not related to using CoreLogic:
- Create server objects
- (Create a monitor)
- Create a service group
- Create a load-balancing virtual server
The only object which is addressed by CoreLogic, is the load-balancing virtual server.
To illustrate the process, we are going to deploy Wordpress through Citrix NetScaler with CoreLogic.
Wordpress will be running a server with IP address 192.168.1.10
.
add server SRV_WORDPRESS 192.168.1.10
Wordpress is deployed on the server without SSL, so we can use HTTP
as the Service Group Type and tcp/80
as the destination port.
add servicegroup SG_WORDPRESS HTTP
bind servicegroup SG_WORDPRESS SRV_WORDPRESS 80
Now things get interesting.
First of all, let's create the load-balancing virtual server. As the load-balancing virtual server will only be addressed through a content-switching virtual server, it doesn't need to have an IP address (non-addressable). Also, if you are running your site on SSL, the encryption will be taken off by the content-switching virtual server (SSL Offloading), so the load-balancing virtual server can be of type HTTP.
add lb vserver VS_WORDPRESS HTTP 0.0.0.0 0
bind lb vserver VS_WORDPRESS SG_WORDPRESS
Now that we have created the load-balancing virtual server for our application, we have to configure it for allowlisting/blocklisting. Remember, the execution flow on the content-switching virtual server checks whether the selected load-balancing virtual server has a allowlist or blocklist configured. If it is not configured, you will get a connection reset.
bind policy stringmap SM_CL1009_IP_CONTROL vs_wordpress "list=blocklist;"
Good, almost there!
The only thing left is configuring when the content-switching virtual server has to forward our request to the load-balancing virtual server.
For the purpose of this example, we will deploy our Wordpress application on the hostname www.netscalerrocks.com
.
We need to add entry to SM_CL1009_CS_CONTROL
to specify the content-switching scenarios.
Format for these entries is as follows:
Key (all in lowercase) | Value |
---|---|
"<cs_name>;<lan|any>;" | "vs=<lb_name>;dst=<redirect_location_if_applicable>;" |
bind policy stringmap SM_CL1009_CS_CONTROL "cs_pub012_ssl;any;www.netscalerrocks.com" "vs=VS_WORDPRESS;"
To illustrate a redirect, let's say we have another domain netscalerrocks.org
we'd like to redirect to www.netscalerrocks.com
.However netscalerrocks.org/nitro
needs to go to api.netscalerrocks.com/nitro
, which means we want to keep the full path of the original request if it starts with /nitro
.
bind policy stringmap SM_CL1009_CS_CONTROL "cs_pub012_ssl;any;netscalerrocks.org" "vs=VS_REDIR_301;dst=//www.netscalerrocks.com;"
bind policy stringmap SM_CL1009_CS_CONTROL "cs_pub012_ssl;any;netscalerrocks.org/nitro" "vs=VS_REDIR_302_KEEPPATH;dst=//api.netscalerrocks.com"
As a final step, we only want to allow the administration pages from the internal network. This would translate in the following commands:
bind policy stringmap SM_CL1009_CS_CONTROL "cs_pub012_ssl;lan;www.netscalerrocks.com" "vs=VS_WORDPRESS;"
bind policy stringmap SM_CL1009_CS_CONTROL "cs_pub012_ssl;any;www.netscalerrocks.com" "vs=VS_WORDPRESS;"
bind policy stringmap SM_CL1009_CS_CONTROL "cs_pub012_ssl;any;www.netscalerrocks.com/wp-admin" "vs=VS_CL1009_RESET;"