Firewall Builder Troubleshooting

• After activating the policy, some web sites do not work
• After activating the policy firewall becomes very slow
• X won't start on the server protected by the firewall
• "Interface eth0 does not exist" error message
• Workstations behind the firewall can not access Internet

After activating the policy, some web sites do not work

Here is another troubleshooting tip for the CookBook.

Sometimes after activating the firewall policy you can access most of the web sites through the firewall just fine, except for a few. The browser would state "waiting for www.somesite.com" for a while and then time out when you connect to one of these sites.

This might be caused by a MTU problem if you are on a DSL connection using PPPoE. Here are couple of useful pages that describe the problem in details:

• http://www.dslreports.com/tweaks/MTU
• http://www.internetweekly.org/llarrow/mtumss.html

If your firewall runs iptables you can use option “Clamp MSS to MTU” in the firewall settings dialog to work around it.

For the PF firewalls similar option is called “Enforce maximum MSS” and is located in the “Scrub rule options” tab of firewall settings dialog. It allows for setting MSS value of TCP sessions opened through the firewall; try values between 1460 or 1464 (1464 is the maximum MSS value that can be used on PPPoE connections without fragmentation).

There is no way to change MSS value on the ipf, ipfw and pix firewalls. If your firewall is one of these, you may need to change MTU on your workstation. See links above for recommendations on how to do it.

After activating the policy firewall becomes very slow

You compiled and started firewall policy script and then noticed that seemingly every operation on the firewall takes a lot longer than before. It takes forever to log in to it using telnet or ssh, different services take a few minutes to start or won't start at all.

Most likely the firewall needs to be able to do DNS lookups but can't. Look in /etc/resolv.conf for the address of the name server it is using and make sure you have a rule in the policy to permit connections to it. Use firewall object in “Source”, the name server object in “Destination” and a standard service object group “DNS” in the Service field.

If your firewall runs caching name server and file /etc/resolv.conf lists “127.0.0.1” as a name server address, then you need to permit firewall to talk to itself. Here is how such /etc/resolv.conf file looks like:

domain your_domain.com
nameserver 127.0.0.1

You need to add a rule with firewall object in both Source and Destination and service object “DNS” in the Service field to the loopback interface. This rule permits firewall machine to communicate with the name server running on it, but you need another rule to permit the name server to send DNS queries and receive answers. This rule should have firewall object in Source, Destination should be set to “any” and the same standard service object group “DNS” should be used in the Service element. Now not only firewall can query the name server process running on it, but the process in turn can send queries to other name servers on the Internet and receive answers.

Here is the rule that should be added to the loopback interface:

Here is the rule that permits name server process to communicate with name servers on the Internet (rule should be added to the Global policy):

Depending on your policy design, you may want to permit all services rather than just DNS on the loopback interface because there are many other processes that need to be able to communicate with the same host , such as X11, RPC etc. The dedicated firewall machine should not run anything unnecessary, so there you may experiment with limiting number of services in the rule on loopback interface. On the other hand, if you use fwbuilder to protect a server that runs many different services, permitting any service on the loopback may be a simpler solution.

The next rule permits processes running on the firewall to communicate with other processes running on the same machine on all protocols:

Note:

A “Help me build policy” druid can automatically build a rule on the loopback interface to permit all services. It can also add a rule to permit name server running on the firewall to send DNS queries to servers on the Internet, as well as a rule that permits hosts on the local net to use firewall as a name server.

X won't start on the server protected by the firewall

You've built a firewall script to protect a server, but after you ran the script, X (KDE, Gnome) won't start anymore.

The reason for this is the same as in the previous problem - you need a rule to permit processes communicate with other processes running on the same machine. This can easily be achieved with the following rule added to the loopback interface:

“Interface eth0 does not exist” error message

You are trying to execute iptables script generated by fwbuilder but get an error message “Interface eth0 does not exist” or similar.

There are several conditions that may cause this error.

The script generated by fwbuilder uses tool /sbin/ip to verify configuration of the firewall interfaces and make sure that interfaces of the real firewall machine correspond to the interface objects created in the GUI. You may get this error if the tool /sbin/ip is not installed on your system. All modern Linux distributions come with the package iproute2 which includes /sbin/ip; check if iproute2 is installed and /sbin/ip exsits.

Another case when you may encounter this error is when firewall script is executed prematurely during the boot sequence and interface really does not exist at that time. For example, interface ppp0 is created only when the system is configured for PPP and daemon pppd is running. If firewall script is activated before the daemon started during the boot sequence, interface ppp0 is not there yet, which leads to this error. Make sure you start firewall script after all interfaces has been initialized.

Workstations behind the firewall can not access Internet

I compiled and activated firewall policy, but workstations behind the firewall still can not access the Internet.

Here are few troubleshooting steps:

• Make sure you compiled, then installed and activated firewall policy. Were there any errors during compile and activation?
• check if ip forwarding is turned on (pull down menu in the “Network” tab of the firewall object dialog).
• try to ping hosts on the Internet by their IP address, not their name. This helps isolate DNS problems. If you can ping by address but can't ping by name, then you need to add policy rules to permit DNS queries.
• Look in firewall's log for records indicating that it drops packets. Error in the policy design can cause it to block connections that you really want to go through.
• Use option “Log everything” to make all rules generate log entries, this sometimes helps pinpoint a rule that drops packets.

Things to check in the policy:

• Check if you have a NAT rule if your protected network is using “private” IP addresses.
• If the NAT rule is there, then you may need to add a policy rule to actually permit connections from the protect network. See examples in the User's Guide and in Firewall Builder Cookbook online
• In case when NAT is not used, check if the routing is configured properly. If your firewall separates subnets A and B, and you are trying to connect from the host on subnet A to the host on subnet B, then both hosts should have routing to the opposite network. Host on the net A needs a route for the net B, pointing at the firewall. Similarly, host on the net B needs a route for the net A, also pointing at the firewall. If one (or both) host has a default route pointing at the firewall, then it won't need a special route for another network.