Vous êtes sur la page 1sur 26

Firewall Builder

Tutorial

Vadim Kurland
vadim@fwbuilder.org

Use "Shift+Mouse button" or right mouse button or whatever else method your browser provides as a way to save a file pointed at by that link on the page.xml1 In order to view examples in this file.Firewall Builder: Tutorial by Vadim Kurland This tutorial provides an overview of the Firewall Builder application. you need to make sure you download it and not just open it in your browser. The tutorial uses snapshots to graphically orient you to a particular step and to introduce you to the concepts used in the application. you need to download it to your computer and then open it in Firewall Builder. Examples used in this document can be found in the file tutorial_objects. . Since this file is in XML format and many web browsers will try to show it.

.

............................7 Policies and rules................................................................................................................................................ while blocking everything else ......................16 Protecting local host..................................7 Global Policy versus Interface Policy ..........................................11 2.........9 Network Address Translation ..........................................................................14 Anti-spoofing rules ....13 Interchangeable and non-interchangeable objects ...........................................................................21 Server behind the firewall using virtual address for access..............................................................21 Server behind the firewall using address of the firewall for access...........................................................17 Using negation in policy rules...............................................................16 Proper blocking of Ident protocol...........................................23 Redirecting the traffic .......................................................................................................13 Letting certain protocols through........ Network Address Translation Rules.......................24 5 ...................................................21 Providing Internet connection for workstations behind the firewall ...........9 Building policy ................................................................................................................................................................................................................................. Introduction ......7 Concepts ...............................................................18 3........................................................22 Server behind the firewall with port mapping .....................................13 Using groups...............................................................................................................................10 Building a policy using Druid .............................................................10 Building policy by hand .......................................................... Policy Rules...........................................................................................Table of Contents 1.............................14 Blocking IP fragments and other potentially dangerous types of packets ....................................................................................................................

6 .

The object has a number of basic parameters that describe its IP address. and so on). routers. where each rule consists of abstract objects that represent real network objects and services (hosts. associated with its network interfaces 7 . In Firewall Builder. The following list shows all supported object types: • Network objects and groups: • • • • Firewall Host Network Group of hosts and networks • Services: • • • • • • IP (Internet Protocol) ICMP (Internet Control Message Protocol) UDP (User Datagram Protocol) TCP (Transmition Control Protocol) Custom Service Group of services • Time interval A Firewall object describes the firewall itself. protocols.Chapter 1. networks. software platform. a firewall policy is a set of rules. Policies and rules A Firewall object has three sets of rules associated with it: • • • Global Policy rules Network Address Translation (NAT) rules Rules. Introduction Concepts Firewall Builder consists of an object-oriented graphic user interface (GUI) and set of policy compilers for a number of firewall platforms. and so on. firewalls. Firewall Builder helps you maintain a database of objects. and the parameters specific to the chosen software platform. in addition to enabling you to edit a policy using simple drag-and-drop operations. It also provides a way to describe which network interfaces the firewall has.

If a rule’s action is Reject. In the end. Host or Network objects. Action can be one of the following: • • • Accept Deny Reject If a rule’s action is Accept. For target platforms that support it. Host and Network objects specify the address that is going to be used for the target platform code. Three different rule sets: Both Global Policy rules and Interface Policy rules include the following common elements: • • • • • • Source Destination Service Action Logging Comment Source and Destination correspond to the source and destination addresses in the packet. A Group object is simply a container that can include any number of Firewall. There are different types of objects available for TCP. Host. such a packet is silently dropped. message type and code for ICMP messages. Firewall. UDP. there might be an option to send a TCP RST packet back in response for TCP services. Network. Introduction Figure 1-1. If a rule’s action is Deny. Firewall Builder provides different types of objects that can be used in these rule elements.Chapter 1. and Group. then a packet with source and destination addresses and service matching the rule is let through. then the packet is dropped and an appropriate ICMP message is sent back to the sender. and generalized IP protocols. 8 . Service is a generalized way to describe port numbers in case of UDP and TCP protocols. ICMP. and protocol number and options for other IP protocols. each type of service object provides its own means of setting port numbers and other parameters. these are: Firewall.

a high level Firewall Builder policy rule might need to be converted into multiple rules going into different groups or chains in the target platform code because of a number of reasons. One example of such platform is the Cisco routers. although there might be no such direct correspondence in other firewall platforms. this is equivalent to the FORWARD chain. However. 9 . direction can be specified for Interface Policy rules. where access lists (ACL) are always associated with interfaces. At the same time. Therefore. Place most rules in Global Policy and only a few rules into Interface Rules. This simplifies the analysis of the rule set and makes a compiler’s job easier. regardless of the interface through which they enter or exit. Global Policy rule Figure 1-3. Interface Policy rule Global Policy versus Interface Policy Global Policy rules apply to packets crossing the firewall. Obviously. Even when such correspondence does exist. using Global Policy rules might not be practical because writing policy compiler capable of guessing correct interface might be too complex. Unlike Global Policy rules. Interface Policy rules are associated with a certain network interface of the firewall. This provides a mechanism for dealing with situations where knowing both interface and direction is necessary. Introduction In addition. so it can use a built-in optimizer to compact the resultant code. there are target platforms that require that all rules are always associated with interfaces. setting up anti-spoofing rules. In case of iptables. for example.Chapter 1. if the source is Any. including the firewall itself. then it should cover any object. Interface Policy rules have a Direction option that can be one of the following: • • • Inbound Outbound Both Figure 1-2 and Figure 1-3 represent examples of a Global Policy rule and an Interface Policy rule Figure 1-2. To explain one need for a conversion. In this case. both final iptables rules won’t have an interface specified in them since the original fwbuilder rule was part of the Global Policy that is not associated with any interface. consider a situation when Firewall Builder has to generate code for an iptables firewall and the rule has Any as source. a policy compiler that generates code for iptables places a rule into both FORWARD and OUTPUT chains.

Adding Policy Rules using menu selection Rules 10 . Building policy At this point. When the policy compiler generates code for the target platform. The Policy compiler is supposed to be smart enough to generate correct NAT code for the target platform and determine parameters like chain and type of translation (for example SNAT. and Interface Policies. DNAT.Chapter 1. This can be done either manually or with the help of another Druid. you should be ready to start building a firewall policy. while the last three refer to those parameters after translation. it has an empty Global Policy. Building policy by hand Once a firewall object is created. or REDIRECT in case of iptables). This determines the order in which lines of the target code are generated. use main menu item Rules. To create rules. see Figure 1-4 Figure 1-4. MASQUERADING. NAT. For an example. it first scans NAT rules. the first three refer to the source and destination address and service of the packet before translation. Introduction Network Address Translation Network Address Translation (NAT) rules consist of the following elements: • • • • • • • Original Source Original Destination Original Service Translated Source Translated Destination Translated Service Comment As names of these elements suggest. then Global Policy. then Interface Policies.

call the pop-up menu by clicking the right mouse button on any rule number. Move rules up and down either by using the menu. select firewall object in the tree of objects and call menu Rules−→"Help me build firewall policy" (see Figure 1-4). Adding objects to the rule using drag and drop Once a policy is filled. Figure 1-5 illustrates this process. that is. Remember that the Druid might add rules to both Global Policy and Interface Policy. you can always modify them later and change them to fit your needs. Both main menu Rules and the pop-up menu provide ways to insert rules in the middle of the policy. We recommend that you start with the Druid to get few initial rules to see what they look like. simply drag objects from the tree to the policy elements. You can simply drag and drop objects from the tree on the left into appropriate rule fields. depending on your choices as specified in your answers to the Druid’s questions. To build a policy manually. Then you can modify your policy by hand. Rules created this way are not different from those created by hand. 11 . Building a policy using Druid To call the Druid.Chapter 1. You can also move rules up and down simply by dragging them by the number field in the direction you want them to go. The Druid will ask a series of questions and generate the firewall policy rules. Use menu Rule to add and remove rules. by adding more rules or changing those created by the Druid. Introduction Start with adding a rule on top of the policy. or by dragging the rule by its number field. and move rules up and down. remove rules. Figure 1-5. then proceed by adding more rules and filling them with objects. or to modify an existing policy. add a rule at the top or bottom of the policy.

Chapter 1. Introduction 12 .

We want to let protocols SMTP and FTP through to the server "hostA" from the Internet. This actually reflects general principle Firewall Builder is based on: put the object you want to control access for in the Source or Destination field of the policy rule.block all the traffic but let certain protocols through. so using proper syntax for ICMP protocol turns certain features on. two objects of the same type with different names but the same values of all other parameters are perfectly interchangeable. All we need to do is put the following rules in the Global Policy: Figure 2-1. then put Firewall object into the policy rule. Another example of two objects which may on the first glance represent the same thing. Let’s assume we have a network consisting just of the firewall "firewall1" and few hosts behind it. most basic tasks you may want your firewall to do . Using just IP with protocol number 1 will most likely not turn these features on and therefore will lead to unexpected results. Policy Rules Letting certain protocols through. Interchangeable and non-interchangeable objects In the previous example we put object "hostA" into the Destination field of the policy rule #0 because our goal was to permit protocols SMTP and FTP to that host and not to any other one. and block everything else. depending on their type and other parameters. It is worth mentioning that this policy also blocks all the access to firewall itself. while blocking everything else This is one of the simplest. Rule #0 allows SMTP and FTP through to the server. is IP service object with protocol number set to 1 and ICMP service object with type and code set to "any". We do not need any additional rules to take care of "reply" packets coming back from the server to clients because our underlying firewall software supports stateful inspection and "understands" that such packets should be let through. One of the frequent mistakes is to create Host object with IP address of the firewall. then use it in the policy and expect Firewall Builder to build policy controlling access to the firewall. namely "Any ICMP message". Two different objects with the same address may or may not be interchangeable. However. including access to it from internal hosts. If you wish to control access to or from the firewall machine. like for example session state tracking. Example of the rule permitting only certain protocols to the server and block everything else. while rule #1 blocks and logs everything else. On the other hand. Although using different 13 . Both objects might represent the same type of service. target firewall software typically uses special syntax for indication of different protocols. IP protocol 1 is in fact ICMP. Unfortunately it does not work that way.Chapter 2. so one would expect the behaviour of the firewall to be the same regardless of what type of service object is used. but in fact are not interchangeable.

Two options deal with fragments: one is called "all fragments" and another "short fragments". Once appropriate group has been created. Figure 2-2 shows how does object "ip_fragments" look like with both options turned on. although useful in certain situations. service objects can not be put in a such group. Obviously this can make firewall policy quite cluttered. Group is just a container which includes multiple objects of the same or similar type. "TCP Service". are often used as a tool to probe and penetrate simple packet filters. Policy compilers recognize this object and generate correct code for underlying firewall software platform. In Firewall Builder. there may be a need to permit the same service to 10 different hosts on the network. 14 . IP Service object which represents fragmented packets. "Network" and "Firewall" objects in the group of objects.Chapter 2. we provide a way to set flags or options in the IP service object. Similarly group of services can contain "IP Service". The simplest way to accomplish this is to add 10 rules with the same source and service fields and just different destinations. Using groups Sometimes we need to define a lot of very similar rules for multiple hosts or networks. are especially bad because they can cause some Operating Systems to crash (for example Windows NT was known to crash before fix was developed and published by Microsoft). Policy Rules objects to describe the same object may be confusing. To add objects to a group simply drag them from the tree on the left into group view on the right. Firewall Builder supports groups of objects and groups of services. One can put "Host". To avoid this and make policy readable we can use groups. Groups can contain other groups of the same type as well. For example. Blocking IP fragments and other potentially dangerous types of packets Fragmented IP packets. Figure 2-2. it can be used for policy and NAT rules just like any other object. while still blocking it to all others. "UDP Service" and "ICMP Service" objects and can not contain hosts or networks. or use Copy/Paste functions available via menus. Particular kind of fragmented packets. These packets therefore are considered potentially harmful and should be blocked on the perimeter of your network. namely those with incorrect length specification. the final firewall policy will be correct. Many firewall platforms provide ways to deal with such packets.

Chapter 2. Turning it off on those rules which do not require it may improve performance of the firewall. This combination is never used in real communications. Policy Rules Object "ip_fragments" is included in the section "Services/IP" of the standard objects database coming with Firewall Builder. so if any packet like that comes to your network. so we can safely use this option on this rule. it indicates that this rule has non-default options set. ACK. PSH). Another potentially harmful type of packets is so called "Christmas tree" packet. Rule options dialog for iptables firewall Here is an example of the policy rule which is intended to block all fragmented and TCP "Christmas tree" packets. Obviously we do not need stateful inspection while analysing fragmented packets as we do not really want any session to be established. this can be done in the rule options dialog (which is platform-sensitive and shows different options for different platforms). Note an icon in the "Options" column. it should be considered illegal and blocked. One example of firewall platform which supports stateful inspection but provides a way to turn it on and off is iptables. Rule blocking all fragmented packets and TCP "cristmas tree" packets This rule is part of the Global Policy and therefore applies to all packets crossing the firewall regardless of their origin. If by some reason you might want 15 . In Firewall Builder. Some platforms provide a mechanism to turn on and off stateful inspection on individual rules. Object "tcpxmas" is included in the section "Services/TCP" of the standard objects database coming with Firewall Builder. This means that it will block such packets originating in your network. This one is just a TCP packet with all TCP flags turned on at once (SYN. Figure 2-4. headed out to the Internet. Figure 2-3 shows rule options dialog for iptables firewall: Figure 2-3. FIN. RST.

but its source address belongs to one of the address blocks or subnets used on your network. packet should be dropped. it must be put into Interface Policy. To create anti-spoofing rule in Firewall Builder we need objects for all subnets inside the firewall perimeter and obviously an object for firewall itself. Objects for internal subnets can be put in the single group. Then we create a rule in the Interface Policy of firewall’s external interface and put all these objects.Chapter 2. An interactive Druid available via menu item "Rules/Help me build firewall policy" can create anti-spoofing rules. Figure 2-5. An interactive Druid available via menu item "Rules/Help me build firewall policy" can create a rule to protect against fragmented packets. it may be advantageous to turn stateful inspection off on anti-spoofing rules. You can use "Options" element to do it. Anti-spoofing rule Just like in the previous example. "Destination" and "service" must be set to "any" and Direction must be set to "inbound". Since we want to prevent these packets from entering our network. to make rule compact. then put this rule in the Interface Policy on your external interface. there is going to be no session opened and we do not want to keep state at all. Policy Rules to be able to send this kind of packets out. and the firewall object in the "source" rule element. spoofed packet is one which is coming from the Internet into your network. Figure 2-5 shows the anti-spoofing rule. Your host may or may not have its IP address assigned via PPPoE or DHCP. which examines source address of all packets crossing that interface coming from outside. Anti-spoofing rules First of all. with Direction "Inbound". or a group which contains them. If that address belongs to internal network or firewall itself. Since rule must take into account both interface packet is coming through and the direction in which it is coming. Under normal circumstances such packet can only originate on your network. Basic idea of antispoofing protection is to have a firewall rule assigned to the external interface of the firewall. This is one of the rare cases when the rule can not be put into Global Policy. therefore it can not be entering it from the Internet. Protecting local host This is the kind of policy you would want if you are using firewall software running on the host itself. Here is what you do if address is static: 16 .

address 127.1/255. mark it as "external" add loopback interface named "lo". Policy Rules • • • • create firewall object. sender never knows what happened to it and keeps waiting for responce. You can edit these and add more rules now.0 call Druid. 17 .0. since the firewall drops the packet and connection can not be established. mark its address as "dynamic" create interface for it in "Interfaces" tab.0.0.0 call Druid.0.1/255. In fact. I am not going into discussion regarding usefulness of Ident protocol here as my intent is simply to show how one can construct a policy rule which will block Ident without causing delay in email delivery. Proper blocking of Ident protocol Suppose we want to block connections to certain ports on the server behind the firewall. but want to do it in a "polite" manner.0. Since "Deny" causes firewall to silently drop the packet. enter its IP address create interface for it in "Interfaces" tab. The simplest way to block any protocol is to use "Deny" action in the policy rule.xml includes firewall object called "firewall_on_the_host" which illustrates local host protection rules created with the aid of the Druid.0. that is send TCP RST packet back so our server would look like nothing is listening on that port at all. Many believe Ident protocol is practically useless and does not really serve as protection against SPAM or any other useful function. most OS do not recognize ICMP "administratively prohibited" message and do keep trying. mark address as "external" and "dynamic" add loopback interface named "lo". One of the practical applications of this setup would be blocking Ident connections to the mail relay or mail server. it will just wait until its timeout expires. This happens because remote mail relay tries to connect to Ident port on our server and. Sendmail and many other MTA’s (Mail Transport Agents) attempt to connect to Ident port (TCP port 113) on the mail relay every time they accept email from that relay.Chapter 2. This can be done by adding appropriate rule option (see Figure 2-7) It is also safe to turn stateful inspection off on this rule since we do not want connection to be estabslished and therefore do not need to keep track of it. chose "Firewall protects local host" and then pick rules you want. See what Druid have created for you. address 127. File tutorial_objects. thus indicating that access to requested port is denied by the firewall.0. This means that denying on the firewall will lead to a delay in the delivery of each email message. Normally "Reject" makes firewall to send ICMP "unreachable" message back to sender. chose "Firewall protects local host" and then pick rules you want. To avoid this delay we will set rule Action to "Reject". If address is dynamic: • • • • create firewall object. To make host on the other side drop its attempts right away we need to send TCP RST packet back instead of ICMP message.0. This may be insufficient yet because host trying to connect to our Ident port won’t understand this type of ICMP message and will keep trying.

which is going to open undesired hole in the firewall. First. we have to use "any" as a destination in the policy rule. we can use two rules: first will deny access from "mail_relay_1" to "internal_net" and the second will permit access from "mail_relay_1" to "any".Chapter 2. Policy Rules Figure 2-6. Since rules are consulted in the order they are specified in the policy. We can specify destination in the rule as "not internal_net". These two rules are represented on Figure 2-8 Figure 2-8. Using two rules to block access from DMZ to internal net and permit access to the Internet Another solution uses negation. Negation can be 18 . There are two solutions to this problem. Since we want it to connect to hosts on the Internet and can not predict their addresses. Unfortunately "any" includes our internal net as well. Adding rule option to make send TCP RST packet Using negation in policy rules Suppose we want to set up a rule to permit access from the host on DMZ net "mail_relay_1" to hosts on the Internet. Using action "Reject" with rule option Figure 2-7. access to internal net will be blocked by the first rule since the packet would hit it first. but do not want to open access from it to machines on our internal network represented by the object "internal_net". thus permitting access to anything but "internal_net".

19 . Policy Rules enabled and disabled in the pop-up menu which you call by clicking right mouse button on the corresponding rule field. Using rule with negation to block access from DMZ to internal net and permit access to the Internet Negation can be used in NAT rules in a similar way. Figure 2-9.Chapter 2.

Policy Rules 20 .Chapter 2.

firewall rewrites source IP address of each packet sent by internal machines to the Internet replacing private IP address with the address of its external interface. When configured this way. These addresses are: • • • 10.240. we do not need to worry about reply packets because underlying firewall software keeps track of translations done for all the connections opened through the firewall and rewrites addresses in all reply packets automatically. The rule on Figure 3-1 provides address translation for all the packets.Chapter 3.168. and you want to provide Internet access for machines on this net.0 172.0. In Firewall Builder this type of the NAT rule is composed as shown on Figure 3-1 Figure 3-1.0.0. then you may need Network Address Translation (NAT) configured on the firewall. object representing internal network is placed in "Original Source" and firewall’s object is placed in "Translated Source".0. Masquerading rule (this rule is part of NAT ruleset) Here. but to permit connections to the Internet a special Global Policy rule is needed.0. Rule #3 permits connections from internal network to the Internet (this rule is part of Global Policy) 21 . This particular type of NAT configuration is often called Masquerading.0 / 255.0 / 255. As before. This rule simply permits all connections from internal network to "any" and should be placed somewhere close to the end of the policy. Figure 3-2.0.0 If your network uses addresses from one of these blocks.0 192.0. for example right on top of "catch all and log" rule.16. Network Address Translation Rules Providing Internet connection for workstations behind the firewall Suppose your internal network is configured using so-called private IP addresses as defined in RFC 1918.0 / 255. thus indicating that we want source address of the packets to be translated.0.255.

NAT rule for the server behind the firewall Since we wanted to use address of the firewall’s external interface to access the server. Server’s object was placed in "Translated Destination" part of the rule so that original destination address of the packet will be replaced with server’s address. The rule which provides translation from address "hostA-nat" to "hostA" is shown on Figure 3-6 22 . and a web server on it. We need to provide access to this server from the Internet in a such way that connections will be established to the address of the firewall. but for simplicity I call it "hostA-nat" since it will be used to configure NAT rule for hostA in our example. This can be done using slightly different NAT rule. Server behind the firewall using virtual address for access Those who have more than one IP address allocated by their ISP may want to configure the firewall in a such way that extra addresses be mapped to different servers inside their network. Just like in the previous case we need one NAT rule to provide translation and one Global Policy rule to permit connecitons. firewall’s object is placed in "Original Destination" part of the rule. We also need a Global Policy rule to permit connections to the server. we create additional "Host" object with IP address which we are going to use for the translation. This rule is shown on Figure 3-4 Figure 3-4. First of all.all using single IP address of the firewall’s external interface! This configuration can be useful for those with cable or DSL connection and single IP address. rule #1 permits access to the server (This rule is part of Global Policy) Configuration on Figure 3-3 and Figure 3-4 can be combined with configuration on Figure 3-1 and Figure 3-2 Such combination illustrate a situation when machines on the local network can go out to the Internet. Network Address Translation Rules Server behind the firewall using address of the firewall for access Suppose we have a network using private IP addresses behind the firewall. This object can have any name. In this case we need destination address of packets to be rewritten so packets would reach the server on internal network.Chapter 3. Figure 3-3 shows NAT rule we need: Figure 3-3. and at the same time server located on internal network can provide service for the Internet users .

222.Chapter 3. Firewall Builder provides simple way of doing this. one could use it to 23 . This can be useful if server behind the firewall runs on some alternative port. Additional object used for "Original Destination" in the NAT rule Figure 3-6. This can be done either by setting up static ARP entries on the router or on the firewall.222.33 eth1 pub Another way is to use tool /sbin/ip to assign an "alias" ip address to the same interface of the firewall: ip addr add 222.33 to the MAC address of the interface eth1 and add appropriate routing entry pointing to the internal interface eth0: route add 222. There are two approaches to this problem: One way to do it is to basically take care of ARP requests sent by the router in front of the firewall. except it illustrates how NAT rule can help change a port number besides of the address. Here are the commands we would need to run on Linux firewall to map address 222.222. This rule looks exactly like that in the previous case .222. NAT rule for the server behind the firewall with different address used for access Finally we need a Global Policy rule to permit connections to the server. yet we want to make it so that users would access it using another port when connect to it. For example.222. so the additional address we use for translation will get mapped to the same MAC address of the firewall’s external interface.222. Server behind the firewall with port mapping This case is similar to two previous ones. Just check option "Create virtual addresses for NAT rules" in the "Firewall" tab in Firewall dialog and policy compiler will include all the neccesary code in the firewall script.33 dev eth0 arp -Ds 222.222. Network Address Translation Rules Figure 3-5.222.33 dev eth0 scope link Tool /sbin/ip is a part of the package iproute.see Figure 3-4 Using different address for translation requires additional set up to be done on the firewall to ensure packets would reach firewall while headed for that address.

Network Address Translation Rules provide access to the web server running on non-standard port #8080 by setting up translation of TCP ports to the standard one #80. Policy rule should use TCP Service object "tcp-8080" instead of "http". see Figure 3-8 Figure 3-8. run transparent web proxy on the firewall box. Global Policy rule which permits access to the server Redirecting the traffic this is a special case of NAT where packet’s destination address gets changed to that of the firewall itself. TCP Service object for port tranlsation rule Now we can create the rule. This may be useful if you. Since Policy rules are consulted after NAT. Figure 3-7 illustrates this object’s setup: Figure 3-7. This object would have its port number set to that used by the real server. The rule goes to NAT ruleset and should have firewall ob- 24 . it would look just like previous translation rules except we put appropriate service objects in "Original Service" and "Translated Service" columns. NAT rule with port translation Of course we need Global Policy rule as well to permit connections to our server. This kind of translation works for both TCP and UDP services. First of all.Chapter 3. See Figure 3-9 Figure 3-9. that is translation can be done using either firewall’s external interface address or some different address. for example. additional Service object needs to be created. This configuration can be combined with either one of the two above.

25 . These requests will originate from the firewall itself.Chapter 3. In a real policy this rule would have specific port number in "Original Service" to limit its scope to the protocol supported by the proxy server and will also be placed on top of other NAT rules dealing with the same source addresses so it would match first. Network Address Translation Rules ject in "Translated desination". Figure 3-10 shows redirection rule which bounces all HTTP connections opened by users on "internal_net" to the Squid proxy server running on the firewall box on port 3128. Redirection rule may be combined with port mapping. Obviously squid has to be configured properly to work as transparent proxy. so redirected packet will hit firewall on a different port. Figure 3-10. Redirect rule Note that for this setup to work a Global Policy rule is needed to permit HTTP requests made by Squid.

Network Address Translation Rules 26 .Chapter 3.