Clavister NetEye On-Premises Getting Started Guide

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

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

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:

Figure 3.12. Add a Route for Returning Client Traffic Back to NetEye

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

Figure 3.13. Routing Rule Dialog 2

Figure 3.14. Routing Rule Filter 2

4. Configure a NAT IP policy to allow traffic from NetEye to the Internet:

Figure 3.15. Add IP Policy Dialog 2

Set the source address translation on the policy to NAT:

Figure 3.16. Set IP Policy NAT Translation

5. Create a service group that combines the predefined services https and ssh:

Figure 3.17. Define an HTTPS/SSH Service Group

6. Configure a SAT IP policy to allow management traffic to reach NetEye:

Figure 3.18. Add SAT IP Policy

Set the destination address translation on the policy to SAT towards the management IP:

Figure 3.19. Specify SAT Translation

The changed cOS Core configuration can now be activated and committed.

The following CLI commands could be used instead of the WebUI for configuring cOS Core communication with NetEye.

A. Route traffic between clients and NetEye

Device:/> add RoutingTable my_neteye_rt

2. Add an all-nets Route:

Device:/> cc RoutingTable my_neteye_rt
Device:/rt> add Route Network=all-nets
			Interface=If4
			Gateway=neteye_input_gw_ip

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

Device:/> add RoutingRule
			ForwardRoutingTable=my_neteye_rt
			ReturnRoutingTable=main
			SourceInterface=If1
			SourceNetwork=If1_net
			DestinationInterface=any
			DestinationNetwork=all-nets
			Service=http-all

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

Device:/> add IPPolicy Name=my_neteye_policy
			SourceInterface=If1
			SourceNetwork=If1_net
			DestinationInterface=If4
			DestinationNetwork=all-nets
			Service=http-all
			Action=Allow

B. Route traffic between NetEye and the Internet

Device:/> add RoutingTable my_neteye_rt2

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

Device:/> cc RoutingTable my_neteye_rt2
Device:/rt> add Route Network=If1_net
			Interface=If3
			Gateway=neteye_out_gw_ip

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

Device:/> add RoutingRule
			ForwardRoutingTable=main
			ReturnRoutingTable=my_neteye_rt2
			SourceInterface=If3
			SourceNetwork=all-nets
			DestinationInterface=any
			DestinationNetwork=all-nets
			Service=http-all

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

Device:/> add IPPolicy Name=my_neteye_policy2
			SourceInterface=If3
			SourceNetwork=all-nets
			DestinationInterface=If2
			DestinationNetwork=all-nets
			Service=all_services
			Action=Allow
			SourceAddressTranslation=NAT
			NATSourceAddressAction=OutgoingInterfaceIP

5. Create a service group that combines the predefined services https and ssh:

Device:/> add Service ServiceGroup https-ssh Members=https,ssh

6. Configure a SAT IP policy to allow management traffic to reach NetEye:

Device:/> add IPPolicy Name=my_neteye_mgmt_policy
			SourceInterface=If2
			SourceNetwork=88.131.48.0/25
			DestinationInterface=core
			DestinationNetwork=If2_ip
			Service=https-ssh
			Action=Allow
			SourceAddressTranslation=None
			DestinationAddressTranslation=SAT
			DestinationAddressAction=SingleIP
			DestNeIP=neteye_mgmt_ip

The changed cOS Core configuration can now be activated and committed.

This section describes how to use the cOS Core WebUI to whitelist certain FQDNs from NetEye processing.

A. Configure FQDN Address Objects and FQDN Address Group

Figure 4.2. Add FQDN Address

Specify the FQDN of the whitelisted sites. Wildcarding can be used. In the example below, all the sites for the domain example.com will be whitelisted.

Figure 4.3. Add FQDN Address Dialog

If more than one domain is to be whitelisted, combine the FQDN address objects into an FQDN Group object. A group is created by selecting Objects > Address Book > Add > FQDN Group in the WebUI.

Figure 4.4. Add FQDN Address Group

Add the FQDN address objects that make up the group.

Figure 4.5. Add FQDN Address Group Dialog

	Note: FQDN wildcards require a DNS Profile
	For FQDN wildcards to function, a DNS Profile object must also be associated with the IP policy that allows DNS traffic to flow to the Internet. This is explained further in the FQDN Address Objects section of the separate cOS Core Administration Guide. If wildcards are not used, a profile does not need to be created.

B. Configure a Policy-based Routing Rule

Figure 4.6. Add a Policy-based Routing Rule

Enter a suitable name for the routing rule and set the forward and return routing table to the traffic's original routing table (this will usually be the main table).

Figure 4.7. Whitelisting Policy-based Routing Rule Dialog

For the routing rule filter, specify an FQDN address object or FQDN address group for the destination network that will be whitelisted. The value any can be used for the interfaces. The source network and interface should be the relevant values for the location of the clients. The service should be set to the targeted traffic, in this case http-all.

Figure 4.8. Whitelisting Policy-based Routing Rule Filter

After creating the routing rule, it must be moved to a position above the routing rule that sends client traffic to NetEye. This can be done by dragging and dropping the rule in the rule list using the mouse.

The changed configuration can now be committed and activated. It is assumed that a suitable IP policy exists in the configuration which will allow client traffic to flow to the Internet.

The following CLI commands could be used instead of the WebUI for whitelisting setup in cOS Core.

A. Configure FQDN Address Objects and FQDN Address Group

Device:/> add Address FQDNAddress my_whitelist_fqdn1
			Address=*.example.com

Device:/> add Address FQDNGroup my_whitelist_fqdn_group
			Members=my_whitelist_fqdn1,my_whitelist_fqdn2

	Note: FQDN wildcards require a DNSProfile
	For FQDN wildcards to function, a DNSProfile object must also be associated with the IP policy that allows DNS traffic to flow to the Internet. This is explained further in the FQDN Address Objects section of the separate cOS Core Administration Guide.

B. Configure a Policy-based Routing Rule

Device:/> add RoutingRule
			ForwardRoutingTable=main
			ReturnRoutingTable=main
			SourceInterface=If1
			SourceNetwork=If1_net
			DestinationInterface=any
			DestinationNetwork=my_whitelist_fqdn_group
			Service=http-all
			Index=1

A CLI activate/commit command sequence can now be applied to make the configuration changes permanent. It is assumed that a suitable IP policy exists in the configuration which will allow client traffic to flow to the Internet.