Chapter 3: cOS Core Setup

Home Prev	Clavister NetEye On-Premises Getting Started Guide	Next

This section will provide detailed examples of cOS Core setup. It will be assumed that the NetWall firewall has the interface naming shown in the diagram below. It will also be assumed that the protected clients are on a network defined by the cOS Core address book object called If1_net.

Figure 3.1. On-Premises NetEye Example

A Summary of Setup Steps

Setting up cOS Core for On-Premises NetEye consists of the following steps:

A. Route traffic between clients and NetEye:

Create a new Routing Table and add a route to it that sends all-nets traffic out on the If4 interface (which is connected to NetEye). The Gateway property of this route must be set to the IPv4 address of the NetEye interface for incoming traffic from clients.
Create a Routing Rule that triggers on the HTTP/HTTPS traffic being generated by the clients. This rule uses the routing table created in the previous step as the Forward Routing Table. The Return Routing Table is set to the main table.
Create an IP Policy which allows the client traffic to flow from the clients to NetEye with no address translation.

B. Route traffic between NetEye and the Internet:

Create a new Routing Table and add a route to it that sends if1_net traffic out on the If3 interface (which is connected to NetEye). The Gateway property of this route must be set to the IPv4 address of the NetEye interface for outgoing traffic to the Internet.
Create a Routing Rule that triggers on the HTTP/HTTPS traffic going to the Internet from NetEye. This rule has the main routing table assigned for its Forward Routing Table property. The routing table created in the previous step is assigned to the Return Routing Table property.
Create an IP Policy which allows client traffic to flow from NetEye to the internet. This policy will implement NAT address translation over the public IPv4 address of the If2 interface.

D. Allow management traffic between NetEye and the Internet:

Create an IP Policy that allows outgoing management traffic from the NetEye management interface to the Internet. This is required for remote management of NetEye. This policy should have a value of all_services assigned to its Service property.
Create another IP Policy that uses SAT translation to allow inbound HTTPS and SSH management traffic from the Internet to flow to NetEye. This SAT policy will translate connections coming from the Clavister management IP address range ( 88.131.48.0/25) so the destination is changed from the public IP address to the address of the NetEye management interface.

It is recommended to create a new Service Group object for this policy that combines the predefined services https and ssh.

If, for some reason, the standard port numbers for the management HTTPS or SSH traffic (443 and 22) are not used on the public IP address, the SAT Port Action property of the IP Policy will need to be used to translate the port number to 443 or 22 on the NetEye Management IP. This may require having two IP policies if both port numbers need to be translated. Port number translation is not included in the later setup examples.

Note that is assumed that the NetEye management IP is already correctly routed on the relevant interface by the main routing table. Usually, default routes will do this.

Note that the diagram at the beginning of this section does not show a separate connection between the NetEye management interface and the firewall. This connection could be on a separate dedicated firewall interface if one was available.

The IP address of NetEye's management interface will be predefined by Clavister and cannot be changed. In addition, only Clavister will be able to connect to Neteye through this interface.

E. Allow Syslog traffic from NetEye to reach InCenter:

Syslog messages generated by NetEye are also sent out on the NetEye management interface. Make sure there is an IP policy that allows this traffic to reach the InCenter instance that will monitor NetEye activity. This InCenter instance might be in the cloud or could be installed locally on-premises. If InCenter is reached across the Internet then the IP Policy defined above for outgoing client traffic could also be used for this. Otherwise, a policy-based routing rule may be needed to apply special routing to Syslog messages.

The destination IPv4 address for the Syslog messages is set in the associated MyClavister account. Setting up the connection between a firewall and InCenter is covered by the separate InCenter Getting Started Guide.

3.1. cOS Core Setup Using the WebUI

This section describes how to use the cOS Core WebUI to set up communication between a NetWall firewall and On-Premises NetEye.

A. Route traffic between clients and NetEye

1. Create a new routing table:

Select Network > Routing > Routing Tables > Add > Routing Table in the WebUI.

Figure 3.2. Add Routing Table

Give the new table a suitable name and leave the Ordering property at the default value.

Figure 3.3. Add Routing Table Dialog

2. Add an all-nets Route:

Add a route to the new routing table by selecting the table in the WebUI and then selecting Add > Route IPv4.

Figure 3.4. Add a Route

The Network should be set to all-nets and the Interface should be set to If4 for this example. The address object neteye_input_gw_ip is assumed to contain the IP address of the interface on the NetEye installation for incoming client traffic.

Figure 3.5. Add a Route to NetEye

3. Configure a routing rule for HTTP/HTTPS traffic:

A Policy-based Routing Rule is required so that the target traffic will use the new routing table and the all-nets route it contains. To do this, select Network > Routing > Policy-based Routing Rules > Add > Routing Rule in the WebUI.

Figure 3.6. Add a Routing Rule

Enter a suitable name for the routing rule and set the forward routing table to the table created above. The return routing table should be set to the original routing table used to reach clients which is the main routing table in this example.

Figure 3.7. Routing Rule Dialog

For the routing rule filter, specify a destination of all-nets for the network and any for the interfaces. The source network and interface should be the relevant values for the location of the clients (in this example, If1_net and If1). The service should be set to the targeted traffic, in this case the predefined service object http-all which includes both HTTP and HTTPS using the standard port numbers.

Figure 3.8. Routing Rule Filter

Note that if non-standard HTTP/HTTPS port numbers are used then a custom service object would need to be first created and then used with the routing rule instead of http-all.

4. Configure an IP policy to allow traffic from clients to NetEye:

An IP Policy object must be added to allow traffic to flow through to NetEye from the clients. Select Policies > Firewalling > Main IP Rules > Add > IP Policy in the WebUI.

Figure 3.9. Add IP Policy

Enter values into the new IP policy dialog. The destination interface should be If4 for this example and the destination network should be set to all-nets. The source network and interface should be the relevant values for the clients which in this case is If1_net and If1. The service is set to http-all to allow only HTTP and HTTPS traffic.

Figure 3.10. Add IP Policy Dialog

B. Route traffic between NetEye and the Internet

1. Create another Routing Table

Create another routing table called my_neteye_rt2:

Figure 3.11. Add Second Routing Table Dialog

2. Add a route to NetEye for returning client traffic:

Add a route to the second routing table so traffic to the clients on the network If1_net are routed to NetEye. The address object neteye_output_gw_ip is assumed to contain the IP address of the interface on the NetEye installation for traffic going to the Internet: