firewall+configuration+example

5/21/2018 Firewall+Configuration+Example

1/9

Barracuda NG Firewall

Firewall Configuration Example

In order to provide a comprehensive description of the possibilities of creating rules for the Barracuda NG Firewall, thefollowing article shows an example setup configuration with a LAN, the internet, and two demilitarized zones. Note that the

rules described in this section are for principle informational purposes only. They are not at all recommended as an example

of secure setup.

In this article:

Example Setup

IP / Mask Description

10.0.8.0/24 LAN, considered secure.

10.0.8.34; 10.0.8.110 Machines of the internal support team.

10.0.8.128 - 10.0.8.134; 10.0.8.201 Client PCs with access to news content provider (for example Reuters).

172.16.0.50 Public FTP server with automatic routing.

172.16.0.143 Mail server for uncritical accounts, accessible via webmail.

172.16.0.2; 172.16.0.21;172.16.0.25; 172.16.0.32

Internal IP addresses of the web servers.

172.17.0.100 Terminal server and gateway to my-news provider (for example Reuters).

172.17.0.8 - 172.17.0.15 Addresses with access rights to the terminal server.

105.8.23.64/29 External address space provided by my ISP.

105.8.23.65 External addresses of www.myexample.com, at the same time mail xchanger formyexample.com.

105.8.23.66 External address of ftp.myexample.com.

105.8.23.67 External address of the firewall to be used as proxy address^.

https://techlib.barracuda.com/pIBq 1 / 9


2/9

10.0.8.100 External address of the firewall (default gateway of my LAN).

172.16.0.100 DMZ 1 address of the firewall (default gateway of DMZ 1).

172.17.0.99 DMZ 2 address of the firewall (default gateway of DMZ 2).

Let us consider the following security policies to be implemented:

All computers in the LAN should have full access to the internet.

All news-service client PCs should have access to the news service.

The FTP server should act as if it has an official IP and should communicate with others via FTP (as a server and a client).

The mailserver should be accessible for everyone via secure webmail and should also be used as SMTP server for the

webmail users.

The web servers run server-side java and are usually under heavy load. Traffic should be distributed to them.

The external support for the web servers has only ssh access to one web server. From there it has to hop to the next one.

The internal support team should have access to the DMZ.

We therefore must handle six different situations that are to be translated into Barracuda NG Firewall rule language. In the

next section we want to extend them with some sophisticated additional properties. Since the rule set is sensitive to the

succession of the rules, we want to give a general hint for starting to build up such a set.

In most situations, start with the redirections followed by maps and end with the pass rules. This is almost always true.

We start by figuring out, what the security policies mean in networking language:

Destination address is identical to the connection address, whereas the source address is translated to a different bind

address. All LAN machines get the same bind address: "proxying, masquerading". The connection from the sysadmin's

machine to the DMZ looks just the same.

Figure 1 -Network situation for a typical LAN to Internet connection:

Source address is the same as the bind address, whereas the destination address is translated to the internal IP of the FTP

server.

Figure 2 - Network situation for an ftp connection to our FTP server:

Destination address is identical to the connection address, whereas the source address is translated a different bind

address. The bind address is used only for the FTP server: explicit source NAT.



3/9

Figure 3 -Network situation for an ftp connection from our FTP server to another FTP server:

Source address is the same as the bind address, whereas the destination address is translated to the internal IP of the

webmail server: Redirecting

Figure 4 - Network situation for a secure connection to the webmail server:

Source address is the same as the bind address, whereas the destination address is translated to the one of the internal IP

addresses of the www servers: Redirecting with cycling

Figure 5 -Network situation for a client connection to our web server farm:

Source address is the same as the bind address, whereas the destination address is translated to the internal IP of the mail

server: Redirecting. Note that although the destination address for the client is the same as when connecting to the web

servers via http, the internal destination is completely different (Service dependent NAT).

Figure 6 - Network situation for remote web server support:



4/9

Source address is the same as the bind address, whereas the destination address is translated to the internal IP of the mail

server: Redirecting. Note that although the destination address for the client is the same as when connecting to the

web server, the internal destination is completely different (Service dependent NAT).

Figure 7 -Network situation for sending a mail to the mail server:

Example Configuration

Step 1 - Create a Rule for redirection of mail traffic to internal mailserver:

With the information above (figure 7), we are able to define a rule set which lets the firewall act exactly as we want it to. We

will start with the redirection rules as mentioned above. Allow the first one to function as mail traffic to the mail server.

Log into the Barracuda NG Firewall.1.

Create a Destination NAT firewall rule (see: How to Create a Destination NAT Firewall Rule) and set the parameters as2.

shown in the following screenprint:

https://techlib.barracuda.com/display/BNGv52/Step+2%3A+Log+into+the+Barracuda+NG+Firewallhttps://techlib.barracuda.com/display/BNGv52/How+to+Create+a+Destination+NAT+Firewall+Rulehttps://techlib.barracuda.com/display/BNGv52/How+to+Create+a+Destination+NAT+Firewall+Rulehttps://techlib.barracuda.com/display/BNGv52/Step+2%3A+Log+into+the+Barracuda+NG+Firewall


5/9

Step 2 - Create a rule for external support for the web servers:

This rule is almost the same. Therefore, we will go on to the next interesting rule, the redirection of an external IP to the web

server farm (figure 5). HTTP access to one IP, namely 105.8.23.65, is redirected to four other IPs. The redirection algorithm is

the following: the client address in binary form is divided by the number of redirection targets. The remainder now decides

to which target the client is redirected (0 to the first, 1 to the second, 2 to the third, ). Since the IP address space

is approximately equally distributed, this method provides almost perfect load balancing for all practical purposes.

Introduce two rules of the following type:

Source Service Action Connection Type Destination

World ftp Redirect Client 105.8.23.66 redirected to 172.16.0.50

172.16.0.50 ftp Pass Proxy explicit: 105.8.23.66 World

These two rules do not seem to have much in common. But if we have a look at figure 2 and figure 3, it becomes clear that

the rules are just mirrors of each other. Since this is a frequent situation in networking life, the Barracuda NG Firewall has a

single action to handle this Map. One key advantage of mapping is that it can be applied in both ways. Just like in the case

of the FTP server.

Rule which implements load balancing for the web server farm:



6/9

Rule which maps the ftp server to the internet:



7/9

Step 3 - Create a rule from LAN to DMZs and internet (figure 1).Use the action Pass, because the destination IP

is identical to the connection IP.

Allowing access to the world includes access to the DMZs. If you want to give DMZ access to selected nodes only, then

you must insert a rule which blocks access from the LAN to the DMZs. This rule has to be placed after the rules which

allow access for the selected nodes and before allowing access to the world.

Rule for LAN access to the whole world:

Finally, we want to give certain clients of the LAN access to the news gateway in DMZ 2. The network environment is a little

more complicated, because each of the clients is mapped to a certain bind address. To avoid the introduction of an own rule

for each client, we define a new connection object, a translation map. In this map, we define which source IP should get

which bind IP if the rule uses this connection object.

Network situation for a typical LAN to Internet connection:

The destination address is identical to the connection address, whereas the source address is translated into a different bind

address. Each client gets a different bind address: "explicit source NAT".

Connection object dialog window for translation map:



8/9

Rule dialog for the news access rule via explicit source NAT:



9/9

We now end up with a rule set that implements our general security policy. There are however some pending improvements.

Before we refine the ruleset, we will go on with a detailed description of the rule in general. A last attention we care to the

FTP server rule. Since it works in both ways, we have given a DMZ server ftp access to our LAN, too. THIS IS SURELY NOT

WHAT WE INTENDED. Hence we fill in another rule, which blocks all traffic from the DMZs to the LAN.

Advanced Settings in the Example Setup

With the knowledge of the advanced part of rule configuration one would suggest the following improvements for this

example.

Improved rule configuration:

Rule Improvement

Web-support Inbound, Dynamic activation

Web-in Inbound

Mail-in Inbound

Webmail Inbound

FTPServerMap Inbound, Reversed Policy: Outbound

Admin2DMZ Outbound

NewsAccess Outbound

LAN2world Outbound


firewall+configuration+example

Documents