NxFilter Tutorial

Clustering with NxFilter
NxFilter supports clustering for load balancing and fail-safe. Once you have a master node you can add up to 4 slave nodes to your cluster. All the slave nodes in your cluster share the settings from their master node. So, you can control everything on your master node.

Globlist doesn't support clustering.


Creating a cluster
To create a cluster, the first thing you need to do is to set up a master node. On 'System > Clustering', you can make one of your NxFilter installations to be your master node. And then you can add the other NxFilter installations as the slave nodes to your mater node. You need to restart NxFilter after change the cluster setup.

Clustering requires TCP/19002, TCP/19003, TCP/19004, UDP/19004 ports opened on the master node.


Starting NxFilter cluster
When you start NxFilter cluster, start your master node first and then your slave nodes. This is because your slave nodes need to download the initial setup from their master node when they start.


Load balancing and fail-safe
One good thing about a DNS filter is that there is already a way of load balancing and fail-safe existing. Make your master node to be the primary DNS server and your slave node to be the secondary DNS server in your network. Then you have load balancing and fail-safe.


Anycast for block redireciton
You can have multiple block redirection IP addresses on 'System > Setup' for redundancy. However, this is not ideal when you put 4 or more nodes behind 2 IP addresses using Anycast. If you set those 2 IP addresses on GUI, you may forward your clients to somewhere not close to them. With Anycast, you want to redirect your blocked clients to the closest server that is the server who blocked them. For this purpose, You can set 'block_node_ip' on each node's /nxcloud/conf/cfg.properties file with its Anycast IP.

For example, if you want to forward your blocked clients to 192.168.0.100 from a node, add the following line into its /nxcloud/conf/cfg.properties file.

    block_node_ip = 192.168.0.100


When a cluster node down
When a slave node down, the other nodes will not be affected. When your master node down, you still don't lose your filtering unless you restart your slave node before you restore the master node. However, there are several things you need to be aware of.

If you have an alert email setup on 'System > Alert', you will receive an email when a cluster node down.

1. Login redirection will not be working

When your master node down, we can't share the login session between cluster nodes. This means your login page will not be working correctly. So, we don't redirect users to the login page.

2. Unauthenticated users will be bypassed

If we don't redirect 'Password Users' to the login page they can't login. However, we don't want to let them lose the internet. So, we bypass filtering for these unauthenticated users when your master node down. If you don't want to bypass filtering for any users even if your master node down try to have a default user covering the entire IP range of your network.

NxCloud's case is a bit different. It drops the requests from unauthenticated users because the login redirection is not a default option for NxCloud and the users on NxCloud mostly use other authentication methods.

3. Multiple server IP addresses with an agent

If you use our agent programs with multiple server IP addresses for fail-safe, they will still be working.


Access control for a slave node
If you add all your slave node IP addresses into 'System > Clustering', any attempt to join a slave node from an unknown source IP address will be blocked.


Monitoring connection state
You can view the connection state of your slave nodes on 'System > Clustering'. Once you set up your cluster then your slave nodes will be shown with the last contact time on the page. It is also showing each node's request, block, user, client-ip  counting data. These counters will be set to 0 on midnight or when you restart NxFilter.


Master node connection checking
On a slave node, there's a connection checking process running in backgroud. It will check the connection to its master node based on TCP/19003 and TCP/19004. When there's a connection problem or if your master node gets crashed, you get notified with an alert email to the admin email address on 'System > Alert'.

However, we found this way of connection checking is not working properly on some conditions. Your slave node needs to get notified with socket closing event from its OS. It works when your master node stops or when there's a network problem while it's running on Windows. But if it's on Linux systems, it doesn't work well. Your slave node will be just waiting for responses from its master node for long time even if there's a network failure.

To solve this problem, we made one more checking process on slave node. It will be checking TCP/80 of your master node. If TCP/80 of your master node gets closed, it will bypass communication to its master node and will notify you with an alert email for the problem. Since this is not for everybody, you have to enable it on your slave side. You can add the following line into /nxfilter/conf/cfg.properties file.

    cluster_double_check = 1

'cluster_double_check' option has been introduced by v4.5.2.4 of NxFilter and NxCloud.


Troubleshooting
When you don't have an entry for your master node on /etc/hosts file of your slave node, your slave node might get stuck with the following message during its startup process,

	INFO [07-31 06:10:53] - MM, MasterCheck started.

This problem is from our DB library. It requires a hostname in /etc/hosts file to connect.