Cipafilter Support:
Support@Cipafilter.com
309 517 2022 option 2
Mon - Fri 7 AM - 6 PM CT
Cipafilter Documentation - Firewall
Posted by Jim Giseburt, Last modified by Jim Giseburt on 09 May 2017 05:18 PM

A stateful firewall is a secure, easy-to-use firewall that tracks all open connections and the state of those connections. A regular (stateless) firewall only inspects packets.

With a regular firewall, if you wanted your client workstations to be able to access Web servers on the Internet you would have to allow any machine on the Internet to access all the high ports on any client. This is a vulnerability many worms and trojans have been written to exploit.

With a stateful firewall, you specify how connections are to be made. For example, you can allow any client inside your network to make a connection to port 80on any server outside. When that happens, only that server will be able to send packets back to the high port on your client that originated the connection, and it will be allowed to do so only from port 80.

The default policy of a firewall determines whether it drops or accepts connections by default. Cipafilter ships with the Default Policy set to ACCEPT. This mode is acceptable if the Cipafilter is in bridging mode behind another firewall. However, if the Cipafilter is the firewall in your network, we recommend setting the Default Policy to DROP. The DROP policy, while giving you specific control of the traffic passing through the firewall, will require the creation of rules for any traffic that you wish to allow through the firewall. Tech support will be happy to assist you with the creation of appropriate rules for your network.

Note: Connections are only matched against the firewall when they are first opened. If you change the firewall, any established connections will remain open even if the new firewall rules prohibit them. Also note that the firewall does not apply to Cipafilter itself; the router automatically adjusts its own firewall based on the configuration of the system to assure proper operation.

The firewall rule syntax is similar to what is used on the Port Forwarding page:

  • : can be used to denote port ranges; e.g., 80:110 to match ports 80 through 110.

  • , can be used to string multiple ports or port ranges together; e.g., 21,22,80:110 for ports 21, 22, and 80 through 110. Up to 15 port references can be used in a single rule.

  • Accept allows the connection.

  • Reject rejects the connection and sends an error message back to the client.

  • Drop loses all the packets and sends no error message back to the client.

  • Do not use any spaces in the rules.

  • The firewall is fully integrated with the port-forwarding system. Make firewall rules using the actual private IP addresses of your internal servers, not the public IP address from which traffic is being port-forwarded.

Example firewall configurations

Action Protocol Source Destination Port(s) Result
Reject TCP 10.0.0.14/32 0.0.0.0/0 80 Prevent 10.0.0.14 from accessing the Web
Reject TCP 0.0.0.0/0 1.2.3.4/32 80,81 Prevent all clients from accessing ports 80 and 81 on host 1.2.3.4
Reject ALL 10.0.0.25/32 0.0.0.0/0 ALL Prevent 10.0.0.25 from accessing outside world

The firewall rules are interpreted top down, so the first rule that matches a connection will determine its fate. For example:

Action Protocol Source Destination Port(s) Result
Accept TCP 203.0.113.0/24 10.0.0.1/32 80 Allow subnet 203.0.113.0/24 to access Web server
Accept TCP 198.51.100.0/24 10.0.0.1/32 80 Allow subnet 198.51.100.0/24 to access Web server
Drop ALL 0.0.0.0/0 10.0.0.1/32 ALL Drop all other unaccepted connections to Web server

The first two rules will allow machines on the 203.0.113.0/24 and 198.51.100.0/24 subnets to access the internal Web server at 10.0.0.15. However, they will only be able to access the Web service on that server. All connections going to all other services or from other subnets will be dropped on the third rule.

Firewall rules may also be applied according to filter authentication groups. For instance:

Action Protocol Source Destination Port(s) Result
Accept TCP teachers 0.0.0.0/0 22 Allow clients authenticated to group teachers to access SSH

Note: Firewall rules will only apply to traffic that is required to pass through the Cipafilter; in practice, this means rules will usually apply only to traffic between two different subnets. This is because traffic between two devices within the same subnet will generally be moved directly between them rather than going through their gateway.

Note: Group-based firewall rules are currently not affected by Permissions Scheduling.

ICMP Firewall

If you are experiencing a problem with ICMP traffic, simply enable the ICMP Firewall and select the types of ICMP packets you wish to let through.

Note: Always allow ICMP fragmentation-needed packets. These packets are required by Path MTU Discovery. If fragmentation-needed packets are blocked, you may experience problems where you can transmit small amounts of data over a connection but large amounts cause the connection to hang.

(0 vote(s))
Helpful
Not helpful

Comments (0)
©Cipafilter 2017. All Rights Reserved.