Shulou(Shulou.com)06/01 Report--

This article shows you what are the rules for pfSense book to configure a firewall. The content is concise and easy to understand. It will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Configure firewall rules

When configuring firewall rules under Firewall > rules policy, there are many options for controlling how traffic is matched and controlled. This section lists most of the options because pfsense book uses pfsense2.31 as an example, which may be slightly different from pfsense2.41 today.

action

This option specifies whether the rule passes, blocks, or denies traffic.

Pass: packets that meet this rule will be allowed to pass through the firewall. If state tracking is enabled for a rule, a status table entry is created that allows related return traffic to be returned.

Blocking: packets that meet this rule will be discarded.

Reject: packets that match this rule will be discarded, and for supported protocols, a message will be sent back to the originator, indicating that the connection has been rejected.

Forbidden

To disable a rule without removing it from the list of rules, check this box. It will still appear on the firewall rules page, but the rule will be grayed out to indicate its disabled status.

Interface

The Interface drop-down menu specifies the interface that receives traffic controlled by this rule. Keep in mind that in the interface and group tab rules, traffic is filtered only on the interface on which the traffic is initiated. Traffic originating from the local area network is directed to Internet or any other interface on the firewall and is filtered by the LAN rule set.

TCP/IP version

Prompt that the rules apply to IPv4,IPv6 or IPv4 + IPv6 traffic at the same time. These rules will only match packets of the correct protocol and take action. Aliases containing both IP addresses can be used, and the rule will match only addresses from the correct protocol.

Agreement

The rules will match the protocol. Most of these options are self-evident. TCP / UDP will match both TCP and UDP traffic. Specifying ICMP displays an additional drop-down box to select the ICMP type. Several other common protocols are also available.

Be careful

This field defaults to the TCP of the new rule because it is a common default value and it will display the expected fields for the protocol. To make the rule applicable to any protocol, change this field to any. One of the most common mistakes in creating a new rule is to accidentally create a TCP rule and then fail to pass other non-TCP traffic, such as ping,DNS, and so on.

ICMP Typ

When ICMP is selected as the protocol, the drop-down list contains all possible ICMP types. When passing through ICMP, the best thing to do is to pass the required types only when feasible. The most common use case is to pass only one response request, allowing ICMP ping communication.

Prompt

Historically, ICMP has a poor reputation, but it is usually beneficial. When ICMP is allowed, it is usually acceptable to allow any ICMP type.

Source address

This field specifies the source IP address, subnet, or alias that will match this rule.

The drop-down box for source addresses allows several different predefined types of source addresses:

Any: matches any address.

Single host or alias: matches an IP address or alias. When it is active, you can type an alias in the Source address field.

Network: use an IP address and subnet mask to match an address range.

PPPoE client: if the PPPoE server is enabled, it matches the traffic from the client address range of the PPPoE server.

L2TP client: if the L2TP server is enabled, the client address range traffic from the L2TP server will be matched.

Interface network: each interface on the firewall has an entry in this list. This source type accurately specifies the subnet of the interface, including any IP alias VIP subnet that is different from the defined interface subnet.

Interface address: each interface on the firewall has an entry in this list. These source types specify the IP address configured on the interface.

Warning

The WAN Net option for the source or destination network only represents the subnet of the WAN interface. This does not mean the "Internet" or any remote host.

For rules that match TCP and or UDP, you can also click

Displays the advanced settings to specify the source port. The source port is hidden behind the Show Advanced button, because usually the source port must remain set to any port, because the TCP and UDP connections originate from random ports within the range of temporary ports (between 1024 and 65535, the exact range used depends on the operating system and operating system version of the connection). The source port is hardly the same as the target port and should not be configured like this unless the application you are using is known to use this atypical behavior. It is also safe to define the source port in the range from 1024 to 65535.

Selecting an inverted match will unmatch so that all traffic except the source value will trigger the rule.

Destination address

This field specifies the destination IP address, subnet, or alias that will match this rule.

For rules that specify TCP and or UDP, the destination port, port range, or alias is also specified. Unlike the source, configuring the destination port is necessary in many cases because it is more secure than using any port and usually knows the destination port in advance based on the protocol. Many common port values are available in the drop-down list, or choose (other) to enter values manually or use port aliases.

Prompt

To specify a continuous range of ports, enter a lower port in the from section and a higher port value in the to section.

Journal

This box determines whether packets that meet this rule are logged to the firewall log.

Description

Enter a description here for your reference. This is optional and does not affect the functionality of the rules. The best thing to do is to enter text that describes the purpose of the rule. The maximum length is 52 characters.

Advanced option

This part of the page already hides options that are unlikely to be needed or have features that confuse new users. Click

Displays advanced options. If the options in this part of the page have been set, they will appear when the rules are loaded in the future.

Source operating system

One of the more unique features of pf and pfSense is the ability to filter the connected operating system. For TCP rules, pf enables passive operating system fingerprinting ("p0f"), which allows rules to match according to the operating system that initiated the TCP connection. The pf function of pf determines which operating system is in use by comparing the characteristics of the TCP SYN packets that initiate the TCP connection with the fingerprint file. Note that the fingerprint of the operating system can be changed to another operating system, especially for open source operating systems such as BSD and Linux. This is not easy, but it is possible if a network contains skilled users and has administrator or root access to the system.

DiffServ code point

A DiffServ code point is a way in which an application indicates inside a packet how to prefer a router to handle its traffic when the path is forwarded along the path. The most common use is for the purpose of quality of service or traffic. Lengthy names are usually abbreviated to Diffserv Code Point or abbreviated to DSCP, sometimes referred to as TOS fields.

The program or device that generates the packet (for example, Asterisk through its tos_sip and tos_audioconfiguration parameters) sets the DSCP field in the packet, which is then matched, queued, or acted on by firewalls and other temporary routers.

To match these parameters in the firewall, use the DiffServ Code Point drop-down entry that matches the value set by the originating device. There are many options, each with a special meaning for a particular type of traffic. Please consult the documentation of the relevant equipment for relevant information.

The disadvantage of DSCP is that it assumes that the router supports or acts on site, which may or may not be. Different routers may process the same DSCP value in an unintentional or mismatched manner. To make matters worse, some routers completely clear the DSCP field in the packet when forwarding the packet. In addition, the way pf matches traffic, the DSCP value must be set on the first packet of the connection in which the state is created, because each packet is not checked separately after the state is created.

Be careful

This option only reads and matches DSCP values. It does not set a value in the packet.

IP option

Check this box to allow packets with defined IP options to pass. By default, pf blocks all packets with the IP option set to prevent operating system fingerprints, and so on. Check this box to pass IGMP or other multicast traffic with IP options.

Disable answer

By default, the firewall adds the reply keyword to the rule on the WAN type interface to ensure that traffic entering the WAN will also leave through the same WAN. In some cases, this behavior is undesirable, such as when some traffic is routed through a separate firewall / router on the WAN interface. In these cases, check this option to disable reply only for traffic that meets this rule, not globally.

Tag and Tagged

The Tag and Tagged fields are useful with floating rules, so firewalls can mark packets with specific strings as they enter the interface, and then use floating rules to perform different actions on matching packets.

Maximum status entry

This option limits the maximum number of connections (total) allowed by this rule. If more connections meet this rule when the connection limit is met, this rule is skipped during rule execution. If later rules match, the traffic will apply the action of the rule, otherwise the default reject rule will be triggered. Once the number of connections allowed by the rule falls below this connection limit, traffic can match the rule again.

Maximum number of source hosts

This option specifies how many source IP addresses can be connected at the same time for this rule. An unlimited number of connections are allowed per source IP address, but the total number of different source IP addresses allowed is limited to this value.

Maximum number of connections

To restrict access based on the connection of each host, use this setting. This value limits the rule to a specific number of connections per source host (for example, 10) rather than a specific total number of global connections. This option controls the number of fully established (completed handshake) connections for each host matching rule. This option applies only to TCP connections.

Maximum status record per host

This setting is similar to the count established above, but only checks the status entry, not tracks whether the connection was successfully established.

Maximum connections per second

This rate-limiting method helps ensure that higher TCP connection rates do not overload the state table on the server or firewall. For example, you can limit connections to incoming mail servers and reduce the burden of spam overload. It can also be used for outbound traffic rules to set limits to prevent any single machine from loading state tables on firewalls or making too many fast connections, which is a common behavior of viruses. You can configure the number of connections and the number of seconds for that time period for this rule. Any IP address that exceeds the specified number of connections within a given time range will be blocked by the firewall for one hour. This option applies only to TCP connections.

Status timeout (seconds)

Use this field to define the state timeout for traffic that matches this rule, overriding the default state timeout. When the connection is idle for this period of time, any inactive connections will be closed. The default state timeout depends on the firewall optimization algorithm being used.

Be careful

This option only controls the traffic in the inbound direction, so it is not very useful by itself. Outbound traffic that matches the connection will still have a default state timeout. To use this setting correctly, you need to use matching floating rules in outbound paths occupied by traffic with similar state timeout settings.

TCP identification

By default, TCP's new delivery rule checks only the TCP SYN identity to be set and does not include possible SYN and ACK collections. To address more complex situations, such as asymmetric routing or other non-traditional traffic combinations, use this set of controls to change how the identity matches the firewall rules.

The first line controls which identities must be set to matching rules. The second line defines the list of identities that will be queried on the packet to find a match.

The meaning of the most commonly used logo is:

SYN: synchronizes the serial number. Indicates a new connection attempt. ACK: indicates the confirmation of the data. These are replies that let the sender know that the data has been received by the OK. FIN: indicates that the sender does not have more data. Close the connection. RST: connection reset. This flag is set in response to a request to open a connection on a port that is not listening to the daemon. It can also be set up through firewall software to avoid bad connections. PSH: indicates that the data should be pushed or refreshed by passing it to the application, including the data in the packet. URG: indicates that the emergency field is important and that the packet should be sent before non-urgent data.

To allow TCP with any flag set, select any flag.

Status Typ

There are three status tracking options in pfSense, which can be specified by rule:

Keep:

When selected, the firewall creates and maintains state table entries that allow communication. This is the default and is the best choice in most cases.

Sloppy State:

This is a scenario that uses a less stringent means to maintain state for asymmetric routing. When the firewall can only see half of the connected traffic, the validity check for default retention will fail and the traffic will be blocked. Prevent some types of pf mechanisms from not working when reviewing lax states.

Synproxy:

This option results in incoming TCP connections from the pfSense agent. The TCP connection begins with a three-way handshake. The first packet of the TCP connection is the SYN from the source, which raises the SYN ACK response from the destination and then returns the ACK from the source to complete the handshake. Normally, the host behind the firewall handles it on its own, but the synproxy state allows the firewall to complete the handshake. This helps prevent a type of denial of service, SYN flooding. This is usually used only for rules on the WAN interface. At present, this type of * * is best handled at the target operating system level, because each modern operating system includes the ability to handle it independently. Because the firewall does not know which TCP extensions the back-end host supports, it declares that it does not support TCP extensions when using synproxy state. This means that connections created using synproxy state do not use window zooming SACK or timestamps that in most cases result in significant performance degradation. It is useful to open TCP ports to hosts that do not handle network abuse well, and the most important performance is not an issue.

None:

This option does not maintain the state of the rule. This is only needed in highly specialized advanced scenarios, which are not covered in this book because they are very rare.

Be careful

Setting "None" here only affects traffic in the inbound direction, so it is not very useful on its own, because a state is still created in the outbound direction. It must be paired with a floating rule in the outbound direction, which has the same option.

Out of sync XML-RPC

Check this box to prevent this rule from synchronizing to other high availability cluster members through XMLRPC. This is included in high availability. This does not prevent rules on the secondary node from being overwritten by the primary node.

VLAN priority (matching and setting)

802.1p (also known as IEEE P802.1p or priority code point) is a method of matching and tagging packets with a specific quality of service priority. Unlike DSCP, 802.1p runs using VLAN at layer 2. However, like DSCP, upstream routers must support 802.1p in order to be useful.

This section has two options. The first will match an 802.1p field so that the firewall can operate on it. The second will inject an 802.1p tag into a packet through this firewall. Some ISP may need to set 802.1p tags in some regions, such as France, to properly handle voice / video / data on the quarantined VLAN to ensure quality.

802.1p has eight priorities, each with a two-letter code in GUI. The order from the lowest priority to the highest is:

BK:BackgroundBE:Best EffortEE:Excellent EffortCA:Critical ApplicationsVI:VideoVO:VoiceIC:Internetwork ControlNC:Network Control

Schedule

This option configures a schedule that specifies the date and time when the rule takes effect. Selecting "None" means that the rule will always be enabled.

Gateway

This option configures gateways or gateway groups for use by traffic that meets this rule, which is included in policy routing.

In / out pipe (limiter)

These selection lists define that the limiter applies bandwidth restrictions on traffic entering the interface (In) and leaving the interface (Out).

Ack queue / queue

These options define which ALTQ traffic queue will be applied to traffic entering and exiting this interface.

Floating rule

A floating rule is a special type of advanced rule that can perform complex operations that are not feasible on the interface or group tab. Floating rules can run on multiple interfaces in inbound, outbound, or both directions. The use of inbound and outbound filtering complicates design rules and is prone to user errors, but they are desirable in specific applications.

Most firewall configurations never have floating rules, or only traffic xx devices have floating rules.

Matters needing attention

Floating rules are more powerful than other rules, but they are also more chaotic and more likely to have unintended consequences that may be short-lived or disconnected.

Floating rules, inbound directions, applied to multiple WANs, will not be answered, because they will also add rules on each interface, so the same problem exists in the interface group here: traffic will always exit WAN with the default gateway, rather than correctly return from the input WAN.

Given that many users are relatively unfamiliar with floating rules, they may not feel the need to view rules when maintaining firewalls. As a result, they may be more difficult to manage because it may not be looking for rules in an obvious place.

Be careful when considering the source and destination of packets based on inbound and outbound directions. For example, a rule for outbound direction on WAN will have a local source (after NAT) and a remote destination for the firewall.

Potential use

The most common use of floating rules is ALTQ traffic × ×. Floating tab rules are the only types of rules that can match and queue traffic without explicitly passing it.

Another way to use floating rules is to control the traffic flowing out of the firewall itself. Floating rules prevent firewalls from reaching specific IP addresses, ports, etc.

Other common uses are to ensure that no traffic can exit from other paths to a secure network, regardless of the rules that exist on other interfaces. By blocking the outward security network of all security networks except the approved location, the likelihood of accidentally allowing communication through some other unwanted path is reduced. Similarly, they can be used to prevent traffic from private networks from leaving the WAN interface to prevent leakage of × × traffic.

As mentioned earlier in interface rules, they can also effectively set state timeouts for asymmetric routes, marking or matching operations "no state" rules and "sloppy state" rules.

Processing task

In the inbound direction, floating rules are basically the same as interface or group rules, except that they are processed first. However, in the exit direction, things will become more chaotic.

Firewall rules are processed after NAT rules, so if the outbound NAT on this interface is active, the rules in the outbound direction on the WAN never match the local / private IP address source. When the rule is reached, the source address of the packet is now the IP address of the WAN interface. In most cases, this can be done by using the match option to mark packets on the LAN, and then match the tag at the firewall exit.

Floating rules are processed before interface group rules and interface rules, so they must also be considered.

Matching action

Matching actions are unique to floating rules. Rules with matching actions do not deliver or block packets, but simply to assign traffic to queues or limiters for traffic. The matching rule is not valid when fast is enabled.

fast

Quickly control whether rule processing stops when rules match. Quick behavior is automatically added to all interface tab rules, but is optional on floating rules. If there is no quick check, the rule takes effect only if there are no other rules that match the traffic. It reverses the behavior of "winning the first game" to "the last victory".

Using this mechanism, you can develop a default sorting behavior that takes effect only if no other rules match, similar to the default blocking rules on the WAN.

In most cases, we recommend quick choices. There are some specific cases where leaving a quick uncheck is necessary, but they are rare. In most cases, the only rule that they do not quickly select is the matching rule traffic × × rule.

Interface

The interface selection of a floating rule is different from a normal interface rule: it is a multi-check box, so you can select one, many, or all possible interfaces. Ctrl + click interfaces to select them one by one, or use another combination of click / drag or shift-click to select multiple interfaces.

Direction

Floating rules are not limited to the entry direction, such as interface rules. They can also choose the outbound direction of action in either direction by choosing here or in either direction. Directions are also available.

Outbound direction is useful for filtering traffic from the firewall itself, for matching other unwanted traffic trying to exit the interface, or for fully configuring "sloppy state" rules, "no state" rules, or standby state timeouts.

Marking and matching

Using the Tag and Tagged fields, you can use interface tab rules to mark connections and then match in the outbound direction of floating rules. This is an effective way to take action on WAN outbound traffic from specific internal hosts, otherwise NAT cannot match because the source address is masked. It can also be similarly used for outbound traffic that is applied to specially marked traffic arriving at the firewall.

For example, in the LAN rule, packets from the 10.3.0.56 source are marked with a short string in the Tag field. Then on the floating rule, quickly outbound to the WAN, using Tagged for the same string to handle the traffic matched by the LAN rule.

Methods of using other public IP addresses

The method of deploying additional public IP addresses depends on how the address is delegated, the size assigned, and the target of a particular network environment. For example, to use other public IP addresses through NAT, the firewall will need a virtual IP address.

There are two options for assigning public IP addresses directly to hosts: routing public IP subnets and bridging.

Select routing, bridging, and NAT

Additional public IP addresses can be used by assigning or using NAT directly on the system that uses them. The options available depend on how ISP assigns addresses.

Additional static IP address

The method of using additional static public IP addresses varies depending on the type of allocation. Each common situation is described here.

A single IP subnet on WAN

For a single public IP subnet on WAN, one of the public IP addresses will be on the upstream router, usually belonging to ISP, and the other IP address will be the WAN IP address on pfSense. The rest of the IP address can be used for NAT, bridging, or a combination of both.

To use an address in NAT, add a proxy ARP,IP alias or a CARP type virtual IP address.

To assign public IP addresses directly to hosts behind the firewall, the private interfaces of those hosts must be bridged to the WAN. When used with bridging, hosts that are directly assigned public network IP addresses must use the same default gateway as the firewall wide area network (that is, the upstream ISP router). If a host with a public IP address needs to initiate a connection to a host behind other interfaces of the firewall, it can be difficult because the ISP gateway does not route traffic from the internal subnet back to the firewall.

The following figure shows an example of using multiple public IP addresses combined with NAT and bridging.

Multiple public IP addresses use a single IP subnet

Small LAN IP subnets with larger WAN IP subnets

Some ISP will assign a small IP subnet as a "WAN side" assignment, sometimes referred to as a transport or interconnection network, and route a larger "internal" subnet to the firewall. Usually this is a / 30 on the WAN side and a / 29 or larger subnet inside the firewall. The service provider router is assigned one end of / 30, usually the lowest IP address, and the firewall is assigned a higher IP address. The provider then routes the second subnet to the WAN IP address of the firewall. Additional IP subnets can be used by firewalls on routed LAN or OPT interfaces, public network IP addresses are assigned directly to hosts, NAT uses other types of VIP, or a combination of both. Because the IP address is routed to the firewall, ARP is not required, so the VIP entry does not need to be used for NAT.

Because pfSense is the gateway on the local network segment, routing from the public local subnet host to the local area network is much easier than the bridging scenario required when using a single public IP subnet. The following figure shows an example of combining a routed IP subnet with a NAT using multiple public IP addresses for two IP subnets. Routing public IP addresses include NAT in routing public IP addresses and network address translation.

Multiple public IP addresses using two IP subnets

If the firewall is part of a high availability cluster that uses CARP, the subnet on the WAN side will need to be / 29, so each firewall has its own WAN IP address and CARP VIP. The provider will route larger internal subnets to the WAN CARP VIP in this type of configuration. The internal IP subnet must be routed to an IP address that is always available, regardless of which firewall has been enabled, and the smallest subnet available for CARP is / 29. This setting for CARP is the same as above, where the OPT1 gateway is CARP VIP and the provider routes to the CARP VIP, not the WAN IP address. CARP covers high availability.

Multiple IP subnets

In other cases, a site may be assigned multiple IP subnets from ISP. Usually when this happens, the site starts with one of the two arrangements described earlier, and then when requesting an additional IP address, the site is provided with an additional IP subnet. Ideally, this additional subnet will be routed to the firewall by ISP, or to the WAN IP address in the case of a single firewall, or to CARP VIP when using HA. If the provider refuses to route the IP subnet to the firewall, but routes it to its router and uses an IP address in the subnet as the gateway IP address, the firewall will need to use the proxy ARP VIP,IP alias VIP, or a combination of IP alias and CARP VIP for other subnets. If possible, the provider should route the IP subnet to the firewall because it works more easily regardless of whether the firewall is used or not. It also eliminates the need to add three IP addresses to the additional subnet, one for network and broadcast addresses and one for gateway IP addresses. By routing subnets, the entire subnet can be used in combination with NAT.

In the case of routing an IP subnet to a firewall, the scenario described in a small WAN IP subnet with a larger LAN IP subnet applies to additional internal subnets. Subnets can be assigned to a new OPT interface, used with NAT, or a combination of both.

Through other IP addresses of DHCP

Some ISP need to get additional IP addresses through DHCP. This is not a good way to obtain multiple public network IP addresses and must be avoided in any serious network. This should not be required for business-level connections. PfSense is one of the few firewalls that can use DHCP's additional IP address at any capacity. This provides limited flexibility.

Bridging

If additional IP addresses from DHCP must be assigned directly to the system that will use them, bridging is the only option. These systems use the OPT interface bridged with WAN, and the system must be configured to use DHCP to obtain their address.

Pseudo multi-WAN

The only option for the firewall to use these DHCP addresses as lease extraction is pseudo-multi-WAN deployment. Install one network interface for each public IP address and configure one for each DHCP. Plug all interfaces into the switch between the firewall and the modem or router. Since the firewall will have multiple interfaces sharing the same broadcast domain, under system > Advanced Settings, select "suppress ARP messages" on the network settings page to eliminate ARP alarms in the system log. This configuration is normal.

The only use of multiple public IP addresses assigned in this manner is for port forwarding. Port forwarding can be used on each WAN interface, and the ISP DHCP server uses the IP address assigned to that interface. Outbound NAT to OPT WAN will not work because each WAN must have a unique gateway IP address to correctly direct traffic out of that WAN. This will be discussed further in multiple WAN connections.

Virtual IP address

PfSense allows multiple IP addresses to be used in conjunction with NAT or local services through virtual IP (VIP).

There are four types of virtual IP addresses in pfSense: IP aliases, CARP, proxy ARP, and others. Each is useful in different situations. In most cases, pfSense will need to answer ARP requests to VIP, which means that you must use the IP alias, proxy ARP or CARP. Use other types of VIP when ARP is not required, such as when the service provider routes other public IP addresses to WAN IP addresses on the firewall.

Regardless of the firewall rule configuration, pfSense does not respond to the ping of proxy ARP and other types of VIP. Using proxy ARP and other VIP,NAT must exist on the firewall to forward traffic to the internal host to run.

IP alias

IP aliases work like any other IP address on an interface, such as the actual interface IP address. They will respond to layer 2 (ARP) and can be used as binding addresses for services on the firewall. They can also be used to handle multiple subnets on the same interface. PfSense will respond to the ping on the IP alias, and services bound to all interfaces on the fire wall will also respond to the IP alias VIP unless these ports are forwarded to other devices using VIP (for example, 1:1 NAT).

The IP alias VIP can use the local host as its interface and bind the service using the IP address in the routed address block without specifically assigning the IP address to the interface. This is very useful for HA and CARP scenarios, so that when the subnet exists only in the firewall (such as NAT or firewall), the IP address does not need to be consumed by CARP settings (one IP per node, the rest is CARP VIP) services such as × ×.

The IP alias itself does not synchronize to the XMLRPC configuration synchronization peer because this causes IP address conflicts. The IP alias VIP uses the CARP VIP "interface" as an exception. Those will not lead to conflict, so they will be synchronized. Another exception is the IP alias VIP bound to the local host as its interface. Because these are inactive outside the firewall itself, there is no chance of conflict, so they are also synchronized.

Agent ARP

The proxy ARP VIP function is strictly at layer 2, providing ARP replies for the specified IP address or CIDR range of IP addresses. This allows pfSense to accept traffic for these addresses within the shared subnet. For example, pfSense can send traffic to other addresses within the Wang subnet based on its NAT configuration. Addresses or address ranges are not assigned to any interfaces on pfSense because they are not needed. This means that pfSense itself does not have any services that can respond to these IP addresses.

The agent ARP VIP does not synchronize to the XML-RPC configuration synchronization peer because doing so results in an IP address conflict.

CARP

CARP VIP is mainly used for highly available redundant deployments that leverage CARP. Each CARP VIP has its own unique MAC address, and these MAC addresses are derived from their VHID, which is useful even outside the high availability deployment.

Referenc

CARP VIP can also be used for a single firewall. This is usually done when the pfSense deployment is eventually converted to a HA cluster node or has a unique MAC address. In rare cases, vendors require that each unique IP address on a wide area network segment have a different MAC address, and CARP VIP provides these addresses.

Other

Other types of VIP define additional IP addresses for use when ARP requests IP addresses that are not needed. The only function of adding other types of VIP is to make the address available in the NAT configuration drop-down selector. This is convenient when the firewall has a public IP module that routes to its WAN IP address, IP alias, or CARP VIP.

Time-based rules

Time-based rules allow firewall rules to be activated within a specified date and / or time range. Time-based rules have the same function as any other rule unless they do not exist in a rule set other than the scheduled time.

Time-based rule logic

When working with time-based rules, the plan determines when to apply the actions specified in the firewall rules. If the current time or date is not overwritten by the plan, the firewall behaves as if the rule does not exist. For example, if there is a separate blocking rule below it, the rule that passes through traffic on Saturday will be blocked only on other dates. Rules are processed from top to bottom, the same as other firewall rules. Using the first match, once a match is found, if the rule is in the plan, the action is performed, and no other rules are executed.

Prompt

Keep in mind that when using a schedule, the rule is not valid outside the scheduled time. Since the current time is not within the scheduled time, the rules will not be reversed. This behavior may result in unexpected access by the customer outside the defined time frame in the plan.

Configure timesheets for time-based rules

Schedules must be defined before they can be used for firewall rules. Schedules are defined under Firewall > timesheet, and each schedule can contain multiple time ranges. In the following example, a company wants to deny access to HTTP during working hours, while the rest of the time can access the network normally.

Define timesheet

Add timesheet:

Navigate to Firewall > time Plan

Click to bring up the timesheet editing page, as shown in the following figure to add a time range.

Enter a schedule name. This is the name that appears in the selection list for the firewall rule. Like an alias, the name can only contain letters and numbers, not spaces. For example: BusinessHours

Enter a description of this timesheet, such as Normal Business Hours

Define one or more time ranges:

Set the month by selecting a specific month and date, or by clicking the title of the day of the week on which you repeat the schedule each week.

Select a start time and stop time to control that the rule is active on the selected date. Time cannot pass midnight on any day. It's from zero to 23:59 all day.

Enter an optional time range description for this specific range, such as Work Week

Click add time to add options as range

Repeat month, time, add another time range

Click Save

The schedule can be applied to specific dates, such as September 2, 2016, or days from Monday to Wednesday. To select any day of the next year, select a month from the drop-down list, and then click a specific date or date number on the calendar. To select the day of the week, click its name in the column header.

For this example, click Monday, Tuesday, Wednesday, Thursday and Friday. This will make the plan work from Monday to Friday, regardless of the month. Now choose the 24-hour schedule. The business hours for this example are from 9 to 17:00 (5 p.m.). All times are based on the local time zone.

Add a time range

Once the time range is defined, it appears in the list at the bottom of the timesheet editing page, as shown in the following figure.

Add time range

To expand this setting, there may be half a day to define Saturday, or the store may open later on Monday. In this case, define a time range for the same number of days, and then define a different time range for another range of each day. This collection of time ranges will be a complete schedule.

Once the timesheet entry is saved, the browser returns to the schedule list, as shown in the following figure. This time is available for firewall rules.

List of time plans after addition

Use timesheets in firewall rules

To create a firewall rule using this schedule, create a new rule on the desired interface. For this example, add a rule to deny TCP traffic on the LAN interface from the LAN subnet to any destination on the HTTP port. In the advanced options for the rule, locate the time schedule setting, and then select the BusinessHours plan, as shown in figure, select the schedule for the firewall rule.

Use timesheets in firewall rules

After you save the rule, the schedule is displayed in the list of firewall rules, along with the activity status of the schedule. As shown in the following figure, this is a reject rule, and the scheduling column indicates that the rule is currently active blocked because it is being viewed at some point in the scheduled range. If the mouse cursor hovers over the schedule status indicator, the firewall displays a tooltip showing how the current rule will run. Because this is viewed within the time defined in the BusinessHours timesheet, the message "Traffic matching this rule is being denied" will be displayed. If there is a general rule after this rule that will match traffic from port 80 of the LAN network, it will be allowed outside the specified time.

List of firewall rules and schedule

The rules are now defined and tested both internally and externally at the scheduled time to ensure that the required administrative behavior is in effect.

Prompt

By default, when the timesheet expires, the status is cleared to make the active connection allowed by the scheduled rule. This closes access to anyone allowed by the rule while active. To keep these connections open, select do not terminate the connection when the schedule expires under system > Advanced Settings > accompanying components.

View firewall log

The firewall creates log entries for each rule that is configured to be logged and for the default deny rule. There are several ways to view these log entries, each with a different level of detail. There is no "best" approach because it depends on the preference and skill level of the firewall administrator, although using GUI is the easiest way.

Prompt

The recording behavior of default reject rules and other internal rules can be controlled using the settings tab under system status > Syslog.

Like other logs in pfSense, firewall logs only retain a certain number of records using the binary circular log format clog. If your organization needs to log firewall logs for a long time, refer to the Syslog section for information about copying these log entries to the Syslog server.

View in WebGUI

The firewall log is displayed on the system status > system Log and Firewall tab of WebGUI. The log can be thought of as a parsed log, which is easier to read, or as a raw log that contains more details. There is also a setting that can display these entries forward or backward. If the order of the log entries displayed is unknown, check the timestamps of the first and last lines, or check the change log settings for information on how to view and change these settings.

The parsed WebGUI log is divided into six columns: Action,Time,Interface,Source,Destination and Protocol.

Action: displays the packet that generated the log entry (for example, pass or block) Time: the time the packet arrived. Interface: where packets enter the firewall. Source: source IP address and port. Destination: destination IP address and port. Protocol: packet protocol, such as ICMP,TCP,UDP, etc.

View log entries from WebGUI

The Action icon is a link that finds and displays the rule that caused the log entry. Usually, this is the "default reject rule", but it can help narrow the scope of suspects when troubleshooting rule problems.

Prompt

On the Settings tab under system status > Syslog, you can configure this rule description to display directly in the log entry. Firewalls can display instructions in separate columns or in separate rows.

Next to the source and destination IP addresses are. When you click this icon, the firewall performs an DNS lookup on the IP address. If the address has a valid hostname, it appears under the IP address of all instances of that address on the page.

The log entry for the TCP packet appends additional information to the protocol field that shows the presence of the TCP flag in the packet. These flags indicate various connection states or packet attributes. Common signs include:

S-SYN: synchronous serial number. Prompts for new connection attempts when only SYN is set. A-ACK: prompt for confirmation of the data. These are replies to let the sender know that the data has been received by the OK. F-FIN: indicates that the sender does not have more data, close the connection.

R-RST:

Connection reset. This flag is set in response to a request to open a connection on a port that is not listening to the daemon. It can also be set up through firewall software to avoid bad connections

Add firewall rules from the log view (simple rules)

Simple rules make it easy to quickly add firewall rules from the firewall log view.

The icon next to the source IP address adds a blocking rule for that IP address on the interface. More specifically, it creates or adds an alias that contains IP addresses added from Easy Rule and blocks them on the selected interface.

The icon next to the destination IP address is similar to the block action, but adds more precise delivery rules. This pass rule allows traffic on the interface, but it must match the same protocol, source IP address, destination IP address, and destination port.

Use the easyrule command to add firewall simple rules in shell

Easyrule can be used to add firewall rules from the shell prompt. When the easyrule command runs without arguments, a usage message is printed to explain its syntax.

It uses aliases or specified protocols, precise delivery rules for source and destination, to add blocking rules in a manner similar to the GUI version. For example, to add a blocking rule, run:

# easyrule block wan 1.2.3.4

The adoption of rules must be more precise:

# easyrule pass wan tcp 1.2.3.4 192.168.0.4 80 from the console menu

The raw log can be viewed and tracked in real time from the filter.log file using option 10 in the console menu. A simple example is the log entry shown in the figure above: the sample log entry viewed from WebGUI:

Aug 308: 59:02 master filterlog: 5,16777216,1000000103,igb1,match,block,in,4,0x10,128,0,0,none,17,udp,328198.51.100.1198.51.100.2,67,68308

This shows that rule ID 1000000103 is matched, resulting in a blocking action on the igb1 interface. The source and destination IP addresses are displayed near the end of the log entry, followed by the source and destination ports. Packets from other protocols may display more data.

View from Shell

When using shell from SSH or from the console, there are many options for viewing filter logs.

Log entries can be quite complex and lengthy when viewing the contents of the clog file directly.

View the current contents of the log file

Filtering logs are included in binary circular logs, so traditional tools such as cat,grep cannot be used directly on files. The log must be read back with the blocker and can then be sent through another program.

To view the full contents of the log file, run the following command:

# clog / var/log/filter.log

To restrict log output to the last few lines, through the tail pipe:

# clog / var/log/filter.log | tail after real-time log output

To "follow" the output of the log file, use the-f parameter to block it. For users using normal log files on UNIX systems, this is equivalent to tail-f:

# clog-f / var/log/filter.log

This will output the full contents of the log file, but will not exit later. It will wait for more entries and print them when they occur. This output can also be sent to other commands as needed.

View the parsed log output in shell

There is a simple log parser written in PHP that can be used from shell to generate reduced output instead of a complete raw log. To view the parsed contents of the current log, run:

# clog / var/log/filter.log | filterparser.php

Log entries output one per line:

Aug 3 08:59:02 block igb1 UDP 198.51.100.1 67 198.51.100.2 68 found the rule that caused the log entry

When viewing one of the original log formats, the ID number of the entry is displayed. This rule number can be used to find the rule that caused the match. In the following example, the rule identified as 1000000103 is:

# pfctl-vvsr | grep 1000000103 Default deny rule IPv4 5 (1000000103) block drop in log inet all label "Default deny rule IPv4"

As the output above shows, this is the default reject rule for IPv4.

Why are log entries for legitimate connections blocked?

Sometimes log entries exist, and although they are marked with the "default reject" rule, they look as if they are legitimate connections. The most common example is to see a connection involving a Web server blocked.

This may occur when the state of the connection is removed or when an ACK is received outside the acceptable window time, when a TCP FIN packet that normally closes the connection arrives. The reason for this is that sometimes packets will be lost or delayed, and retransmission will be blocked because the firewall has closed the connection.

These log entries are harmless and do not represent connections that are actually blocked. All stateful firewalls do this, although some log messages do not generate log messages for blocked traffic, even if all blocked traffic is logged.

This behavior occurs even if the allow all style rule exists on all firewall interfaces, because the rule for TCP connections is set to allow only TCP SYN packet creation. All other TCP traffic will be part of the existing state in the state table, or packets with deceptive or other invalid TCP flags.

When there is an asymmetric route on the network, a special change in the problem can be pointed out. In these cases, the log entry shows that the TCP:SA (SYN + ACK) packet is blocked instead of FIN or RST.

How do I prevent access to the website?

The question we are often asked is "how to prevent access to the website?" Or, more accurately, "how do I prevent access to Facebook?" It's not always an easy question to answer. There are several possible strategies to achieve this goal, some of which are discussed elsewhere in this book.

Use DNS

If the built-in DNS parser or transponder is active, you can enter an override here to resolve unwanted Web sites to invalid IP addresses, such as 127.0.0.1.

Use firewall rules

If your site rarely changes its IP address, you can use an alias that contains its IP address to block access, and then use this alias in your firewall rules. For sites that return low TTL, this is not a viable solution and spreads the load to many servers or data centers, such as Google and similar very large sites. Most small and medium-sized websites can use this method to effectively block because they rarely change the IP address.

The hostname can also be in the network alias. The hostname will be resolved periodically and updated as needed. This is more efficient than finding IP addresses manually, but it is still insufficient if the site returns DNS records in a rapidly changing manner, or if randomization results appear in the server pool of each query, which is common for large sites.

Another option is to find the IP subnet assignments for all sites, create an alias for these networks, and block traffic to these destinations. This is particularly useful for sites such as Facebook, which spread a lot of IP space, but is limited to a few network blocks. Use regional registration sites such as ARIN to help track these networks. For example, in areas covered by ARIN, all networks used by Facebook can be found under http://whois.arin.net/rest/org/THEFA-3.html 's "related networks". The company may have other addresses in different regions, so please check other regional websites, such as RIPE,APNIC, etc.

As an alternative to manually finding IP blocks, find the target company's BGP Autonomous system (AS) number by performing a whois lookup on one of the IP addresses, and then use it to find all assignments. For example, the AS number of Facebook is AS32934:

# whois-h whois.radb.net -'- I origin AS32934' | awk'/ ^ route:/ {print $2;}'| sort | uniq

Copy the result of this command to a new alias, which will overwrite all currently assigned networks. Check the results regularly for updates.

The pfBlocker package provides useful mechanisms in this regard, such as DNSBL, geographic IP address blocking, and automation of the AS lookup process.

Use proxy

If network traffic flows through a proxy server, then the proxy server is likely to be used to block access to these sites. For example, Squid has a plug-in called SquidGuard that allows you to block Web sites through URL or other similar standards.

Prevent detour restrictions

Using any of the above methods, there are many ways to solve the defined block. The easiest and most common is to use any number of proxy sites. It is impossible to find and block all these separate and up-to-date lists. The best way to ensure that these sites are inaccessible is to use external proxies or content that can be blocked by category.

To maintain further control, use a restricted exit rule set and only allow traffic to be sent to specific services or hosts. For example, only DNS is allowed to access the firewall or DNS server dedicated to LAN clients. In addition, if a proxy is being used on the network, make sure that direct access to HTTP and HTTPS through the firewall is not allowed, and that only proxy server or traffic from the proxy server is allowed.

Firewall troubleshooting

This section provides guidance on troubleshooting firewall rules.

Check the firewall log

The first step in troubleshooting suspicious blocking traffic is to check the firewall log (system status > Syslog Firewall tab).

By default, pfSense logs all dropped traffic and does not record any passing traffic. Unless a block or reject rule exists in a rule set that does not use logging, all blocked traffic is logged. If no log entry in the firewall log matches the traffic in question is red, then pfSense is less likely to lose traffic.

Check the status table

Try to connect and immediately check the status table in the system Diagnostics > status and filter on the source or destination to see if the status exists. If there is a state table entry, the firewall has passed through the traffic.

If the rule in question is through the rule, the state table entry indicates that the firewall has passed through the communication, and the problem may be elsewhere than on the firewall.

If the rule is a blocking rule and a status table entry exists, the open connection will not be severed. To see an immediate effect in the new blocking rule, you must reset the state.

View rule parameters

Edit the rule in question and view the parameters for each field. For TCP and UDP traffic, keep in mind that the source port is hardly the same as the destination port and should usually be set to any.

If the default deny rule is blocking, a new pass rule will match the allowed traffic. If traffic is still blocked, there may be some special packets in the rule configuration that require additional processing. For example, some multicast traffic may need to enable the allow IP option, or log entries may be caused by asymmetric routing, or packets may have invalid combinations of parameters, such as segmented packets with "Do not Fragment" set internally.

Sorting of review rules

Keep in mind that for interface tab rules, the first matching rule wins-no more rules are evaluated.

Rules and interfaces

Ensure that the rules work as expected on the correct interface. Traffic can only be filtered through a rule set configured on the interface on which the traffic is initiated. Traffic from a system on a local area network to a system on any other interface is filtered only by LAN rules. The same is true of all other interfaces.

Enable rule log

Determine which rule matches the traffic under discussion. The hit counter in the rule list can help solve this problem to some extent. By enabling login through rules, the firewall log displays a separate entry to determine which rule passes through the connection.

Troubleshooting using packet capture

Packet capture is valuable for troubleshooting and debugging traffic problems. With packet capture, it is easy to determine whether traffic reaches the outside interface or leaves the inside interface, as well as for many other purposes.

The new rules do not apply

If the new rules do not seem to apply, there are several possible explanations.

First, if the rule is a blocking rule and there is a status table entry, the open connection will not be severed.

Second, the rule set may not be reloaded correctly. Check system status > filter reload to see if an error is displayed. Click the reset filter button on the page to force a new filter to be reloaded. If an error is displayed, resolve the problem as needed.

If none of the above reasons solve the problem, the rules may not match, so please re-check the traffic and rules.

Other reasons

There are other flaws in firewall rules, NAT, routing, and network design that may interfere with connections.

The above is what are the rules for configuring firewalls in pfSense book. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.