Skip to content

Crystal Eye XDR on AWS


The Crystal Eye XDR offers world-class security features that can be integrated with Amazon Web Service (AWS) public cloud service.

AWS public cloud provides the leverage to run applications on a shared infrastructure managed by Amazon. These applications which are meant to run on AWS are deployed on Amazon EC2 designed to further provide computing capacity in AWS cloud.

Amazon’s EC2 can be managed with ease for network consistency with the help of Virtual Private Cloud (VPC). One of the most important functionalities of the VPC is to facilitate the process to assign public/private subnets which can be further used to deploy applications in the EC2 instances in those subnets.

The Crystal Eye XDR can then be deployed in EC2 instances and configured to secure the traffic moving to and from the instances in the VPC (where the applications are deployed).

CE XDR Deployments Supported on AWS:

  1. Crystal Eye XDR integration with GWLB as a Security Appliance
  2. Crystal Eye XDR for IPsec VPN Access
  3. Crystal Eye XDR Deployment to Secure EC2 Instances

CE XDR on AWS – Licenses

The Crystal Eye XDR can be deployed on an AWS cloud platform with a BYOL (Bring Your Own License) subscription model. BYOL subscription can either be purchased from Red Piranha or a reseller.

Crystal Eye XDR Integration with AWS GWLB

Crystal Eye can be configured as a security appliance with Gateway Load Balancer to process the traffic flowing through the network for security, compliance, management, and analytics purposes.

How does the traffic flow in a setup where CE XDR is integrated with AWS GWLB to act as a security appliance?

The traffic is received by the Gateway Load Balancer and then forwarded to GWLB Target group which has the CE EC2 instance. This applies to traffic both to and from the public internet.


Once traffic arrives at the Gateway Load Balancer, it behaves very much like any other Layer 4 load balancer, forwarding all received traffic to its configured target group that contains the CE EC2 instance.

However, before forwarding traffic to the target group (where the CE EC2 instance exists), the data within the IP layer of the original traffic will be encapsulated using the GENEVE protocol.

The gateway load balancer does not have a Fully Qualified Domain Name (FQDN) henceforth the traffic can only be accessed through a gateway load balancer endpoint (GWLBe). This means that the only way to get traffic to a Gateway Load Balancer is to route that traffic to GWLBe’s created in the consumer's VPC; where your application(s) reside.

Once that endpoint has been created by the service consumer, a static route must be added to any applicable route table directing interesting traffic to the gateway load balancer endpoint (GWLBe) and in turn to the Gateway Load Balancer.

Once traffic arrives at the Gateway Load Balancer, it behaves very much like any other Layer 4 load balancer, forwarding all receive traffic to its configured target group. However, before forwarding traffic to a target, all the data contained within the IP layer of the original traffic will be encapsulated using the GENEVE protocol (Port 6081).


The screenshot from the AWS configuration dashboard below shows the assigned targeted group and the settings for encapsulation of the flow of traffic between the gateway load balancer and the Crystal Eye XDR EC2 instance.crystal-eye-xdr-aws-config-geneve-protocol

Route Table Configurations (refer to the diagram above to corelate the configs below):

[A] Application Subnet Route Table: All Internet-bound traffic is routed to GWLB endpoint by application subnet route table.


[B] GWLBe Subnet Route Table: Traffic is forwarded from the Gateway load balancer’s gateway that has Crystal Eye EC2 instance to original destination by using route table in the gateway load balancer endpoint subnet.


[C] Internet Gateway Route Table: All inbound traffic from the internet is routed to the Gateway Load Balancer endpoint by the internet gateway route table and forwarded to the GWLB and then to the crystal Eye target group.


IPsec VPN—Connecting CE XDR to AWS VPC

An encrypted IPsec VPN tunnel can be established between the Crystal Eye XDR on-premise and AWS VPC. Once the IPsec VPN tunnel is created, resources secured behind the Crystal Eye XDR EC2 instance can be accessed from the on-premise CE XDR network.

Crystal Eye’s IPSec Site-to-Site VPN encapsulates the private data within the ethernet frame and encrypts the data as well. Because of this additional encapsulation and encryption, private data can be sent over any other network infrastructure while securing the private content.


In the diagram above, we have IPsec VPN tunnel established between an AWS VPC and a remote on-premise network secured by a Crystal Eye XDR appliance. Please note that, IP traffic sessions may be initiated from either side of the IPsec VPN tunnel.

How to establish an encrypted IPsec Site-to-Site VPN tunnel between an AWS VPC and a remote on-premise network secured by a CE XDR?

Step 1: Crystal Eye LAN network Interface is preconfigured to be assigned private IP, in this example we will Create a VPC in which we will have our AWS LAN and define a CIDR range as following crystal-eye-xdr-to-aws-vpc-ipsec-vpn1

Step 2: Create a subnet within the VPC created previously, in this example we will use (Crystal Eye second Network Interface has preconfigured, so the LAN subnet needs to be in this range). crystal-eye-xdr-to-aws-vpc-ipsec-vpn2

Step 3: Create a Route Table and associate it to the VPC created previously.  crystal-eye-xdr-to-aws-vpc-ipsec-vpn3

Step 4: Ensure that your VPC security Group allows traffic from the subnet in use in the LAN network interface in Crystal Eye XDR, which is the same subnet CIDR range we used for the AWS LAN-Subnet example created previously. crystal-eye-xdr-to-aws-vpc-ipsec-vpn4


Crystal Eye LAN IP by default is, so we need to reflect this configuration on the AWS LAN subnet.

Step 5: Create a Customer Gateway, defining the IP Address as the Public IP Address of the Crystal Eye XDR. crystal-eye-xdr-to-aws-vpc-ipsec-vpn5

Step 6: Create a Virtual Private Gateway. crystal-eye-xdr-to-aws-vpc-ipsec-vpn6

Step 7: Attach the Virtual Private Gateway to the already created VPC. crystal-eye-xdr-to-aws-vpc-ipsec-vpn7

Step 8: Create a new VPN Connection, selecting the Virtual Private Gateway created previously. crystal-eye-xdr-to-aws-vpc-ipsec-vpn8

For Customer Gateway ID select the previously created Customer Gateway.


Next, For the For Routing Options, select Static. Enter IP Prefixes including CIDR notation for the remote network you expect to traverse the VPN. (Network that exist in your Crystal Eye on-perm device)


Click **Create VPN Connection **


Step 9: Associate the Subnet created previously to the Created Route Table.


Select the LAN subnet created previously and click on Save Association.


Step 10: From the Route Propagation tab, make sure it is referring to the previously created Virtual Private gateway. crystal-eye-xdr-to-aws-vpc-ipsec-vpn14

Step 11: Select the VPN Connection that you have created previously and choose Download Configuration. The file contains configuration details you will need in next step to configure your Crystal Eye XDR appliance.



To ensure that your local Crystal Eye VPN on-perm device is configured appropriately. (Configuration manual).

Deploying CE XDR in AWS Cloud to Secure EC2 Instances

Applications hosted in the in the EC2 instances can be secured by deploying CE XDR in a separate subnet in the consumer VPC.

The following diagram shows the Crystal Eye deployment in a subnet to which an internet gateway is attached. The application server is located in the private subnet, which does not have direct access to the internet and the Crystal Eye XDR is used as a bastian host.