Build a Better Firewall-Linux HA Firewall Tutorial
Now that the firewall objects have been created, the next step is to create a new cluster object with the lj-fw-1 and lj-fw-2 firewalls as members of the cluster. Right-click on the Cluster system folder in the object tree and select the New Cluster menu item. This launches the new cluster wizard, which walks you through the steps required to create a new firewall cluster.
On the first dialog window, enter the cluster name (lj-fw-cluster), and select lj-fw-1 and lj-fw-2 as cluster members (make sure lj-fw-1 is the master). Click the Next button.
Leave the default settings in the next dialog window and click the Next button.
The third dialog window (Figure 4) is where the failover protocol and virtual IP addresses are defined. For each interface tab at the top of the dialog window, enter the values according to the information in Table 1.
Table 1. Cluster Interface Configuration Parameters
|Interface||Label||Failover Protocol||Virtual IP||Netmask|
After all interfaces have been configured, click Next. On the next dialog window, leave the default setting of “Do not use any, I will create new Policy and NAT rules”, and click Next. The final dialog window will show a summary of the cluster configuration. Review it, and if everything is correct, click Finish to create the cluster object.
After the cluster is created, it is displayed in the object tree. Double-click on the “State Synch Group” object located under the newly created lj-fw-cluster object. The State Synch Group defines the interfaces that are being used for the conntrackd FTFW synchronization traffic. Click on the Manage Members button at the bottom of the editor panel. In the dialog window that appears, click the eth2 interface below the lj-fw-1 firewall and click the right arrow to add the interface as a cluster member. Repeat the process for the eth2 interface of the lj-fw-2 firewall. Click OK to accept the changes.
Double-click the Policy object under the lj-fw-cluster object in the object tree. The Policy is where the firewall rules are configured. Click the green + sign at the top of the window to add a new rule. By default, new firewall rules are set to deny everything. Edit rules by dragging and dropping objects from the object tree into the fields of the rule.
For this example, let's create three simple firewall rules and a single NAT rule. The first firewall rule should be a rule that allows the firewall to communicate with itself using the loopback interface. This is needed because many applications rely on unfiltered access to the loopback for interprocess communication.
Drag and drop the interface object named “lo” from the lj-fw-cluster in the object tree to the Interface field of the rule on the right. Right-click in the Action field of the rule and select Accept. Finally, right-click in the Options field of the rule and select Logging Off. After this is done, the rule should look like Figure 5.
Note that the lo interface object used in the rule was from the cluster object, not an individual firewall's loopback interface object. When Firewall Builder generates the firewall configuration script for each individual firewall, it automatically replaces the cluster interface object with the local interface values for that firewall.
The next two rules use a Network object called Internal LAN that has been created with a value of 10.1.1.0/24. To create a new Network object, double-click the Objects folder in the object tree, right-click on the Networks system folder and select New Network. Fill in the object name and network value in the editor panel at the bottom of the screen.
Right-click on the first rule, and select Add New Rule Below to add another rule to the firewall. The second firewall rule will allow traffic from the Internal LAN object to access the firewall on the internal eth1 interface using SSH. Drag and drop the Internal LAN object from the object tree to the Source field of the newly created rule. Drag and drop the eth1 interface from the lj-fw-cluster cluster to the Destination field.
Firewall Builder comes with hundreds of predefined objects, including most well-known protocols like SSH. Switch to the Standard object library to access the predefined objects. Figure 6 shows the location of the library selection menu at the top of the object tree.
To find the SSH object in the Standard library quickly, type ssh into the filter box at the top of the object tree. Drag and drop the ssh object to the Service field of the firewall rule. Remember to clear the filter by clicking the X next to the filter box.
Switch back to the User library, and drag and drop the eth1 object from the lj-fw-cluster object to the Interface field of the rule. Right-click on Direction field and select Inbound. Finally, right-click on the Action field and set it to Accept. If you want to log SSH connections to the firewall, leave the Options field set to Logging On; otherwise, set it to Logging Off.
Follow the same process to create the third rule, which should allow the Internal LAN to access Internet Web servers using HTTP and HTTPS going out the eth0 “outside” interface. Figure 7 shows the Policy configuration for all three firewall rules.
Notice that we didn't enter any rules to allow the VRRP or conntrackd traffic between the firewalls. Firewall Builder automatically generates these rules based on the configuration of the cluster.
The last step is to configure the NAT rule that will translate the source IP address of all traffic originating from the internal LAN going to the Internet to the outside virtual IP address of the firewall. Using the virtual IP address as the translated source ensures that traffic going through the firewall will continue to flow in the event of a failover from the master firewall to the backup firewall.
Double-click the NAT child object under the hq-fw-cluster object to open the NAT table for editing. Just like in the Policy rules, click the green + icon to add a new rule to the NAT configuration.
Drag and drop the Internal LAN object from the object tree to the Original Src field of the NAT rule, and then drag and drop the eth0 “cluster-outside” interface from the lj-fw-cluster object to the Translated Src field. The final NAT rule should look like Figure 8.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Tech Tip: Really Simple HTTP Server with Python
- Parsing an RSS News Feed with a Bash Script