pfSense Multi-WAN Configuration: Part Seven

pfSense multi-WAN

Changing the weight of a WAN gateway in pfSense 2.2.4.

There are some scenarios where you may want to only use failover. Some pfSense users have a secondary backup Internet connection with a low bandwidth limit, and only want to use that connection if their primary connection fails, and only while it is down. Failover pools allow you to do this. Another possible usage for failover pools is when you want to make sure a certain protocol or destination always uses only one WAN.

pfSense Multi-WANs: Configuring Weights

In pfSense 2.2, you can configure a weight/preference value to WANs. As described in an earlier article, you can set up a gateway group where the WAN interfaces have different priorities. In a gateway group, interfaces at the same tier have equal priority. Lower-numbered tiers have higher priority than higher-numbered tiers. For example, if we set WAN and WAN1 to Tier 1 and WAN2 to Tier 2, WAN and WAN1 will have equal priority. WAN2 will only come into use if both WAN and WAN1 are down. This is good, but what if WAN is our high-speed connection and WAN1 is a DSL connection, and therefore we want WAN to get the bulk of the traffic?

In this case, we can navigate to System -> Routing. The Gateway tab should be selected by default; if not, click on Gateway. Press the e button next to the entry for WAN. On the next page, press the Advanced button. The first entry in this section should be Weight. Using the dropdown box, change the weight to 2. The weight sets the ratio for use of a gateway. Once we change WAN’s weight to 2, there will be two Tier 1 gateways (WAN and WAN2) with weights of 2 and 1 respectively. Thus, out of 3 connections, 2 will use WAN, and 1 will use WAN1, so WAN should get two-thirds of the traffic. Similarly, we could change WAN’s weight to 3, so that WAN will get three-fourths of the traffic. When we are done changing the weight, we need to press Save at the bottom of the page and then press Apply Changes on the next page.

Note that this distribution is strictly balancing the number of connections. It does not take interface throughput into account. This means your bandwidth usage will not necessarily be distributed equally, though in most environments it works out to be roughly distributed as configured over time. This also means if an interface is loaded to its capacity with a single high throughput connection, additional connections will still be directed to that interface. Ideally you would want to distribute connections based on interface weights and the current throughput of the interface.

External Links:

Network Load Balancing on Wikipedia

Suricata Intrusion Detection System: Part Three

Suricata

Interface settings in Suricata.

In the previous article, we covered some additional Suricata configuration details, including downloading rules and setting up your first Suricata interface. In this article, we will continue to configure that interface.

Since we already covered the “WAN Settings” tab, we’ll move on to the “WAN Categories” tab. The first heading covers automatic flowbit resolution. Flowbits are a powerful tool that were first implemented in Snort. Many times, you need to look at more than just one packet to know whether an event is occurring. Flowbits give you the ability to do this. With flowbits, you can set a flag that another rule can check and take into consideration. In other words, if condition 1 is met, we can set a flag. If the flag is set and condition 2 is met, then we can take further action (for example, generate an alert).

The first option is the “Resolve Flowbits” check box. If this is checked, Suricata will examine the enabled rules in your chosen rule categories for checked flowbits. Any other rules that set these dependent flowbits will be automatically enabled (even if they were not otherwise enabled) and added to the list of the files in the interface rules directory. By pressing the “View” button, you can view the auto-enabled rules required to satisfy the flowbit dependencies.

The next heading is “Selecting the rulesets Suricata will load at startup”. Here you can select individual rulesets from the rules you have already downloaded. For example, the ET Open Rules have individual rulesets for ActiveX, protecting against DNS hacks, protecting against denial of service (DoS) attacks, and other threats. There are check boxes next to each individual ruleset, and at the top there are buttons to “Select All”, “Unselect All” and “Save” (to save changes and auto-resolve flowbit rules). There is also a “Save” button at the bottom of the page.


Enabling and Disabling Rules

The next tab is “WAN Rules”. Here you can see things on a more granular level, as you can actually view, enable and disable individual rules, as well as enable and disable all rules in an individual category. At the top of the page, there is an “Available Rule Categories” dropdown box that allows you to select rule categories to view. Next to each individual rule, there is a red check mark on the left side of the row; you can click on this to enable/disable the rule. At the top of the list, there are buttons to disable and enable all rules in the current category, as well as buttons to remove all enable/disable changes in the current category or all categories. There is also an option to view the full file contents for the current category. Finally, above the list of rules is an “Apply” button to apply any changes made.

The next tab is “WAN Flow/Stream”. The first heading is “Host-Specific Defrag and Stream Settings”. Here, you can set different defrag and stream settings for different hosts. By pressing the “plus” button on the right side, you can add new settings; you can also press the “edit” button (the lowercase e) to edit existing settings. The “Policy Name” and “Bind-To IP Address” alias can be edited for everything except the default engine (the “Bind-To IP Address” defines the IP list for this configuration). The “Target Policy” dropdown box allows you to choose an OS target policy appropriate for the protected hosts. The default is BSD, but there are many choices, including IRIX, Linux, MacOS, and variants of Windows. The “Save” button at the bottom allows you to save a configuration, while the “Cancel” button discards the changes.

The next section deals with IP fragmentation. The Internet Protocol (IP) implements datagram fragmentation, breaking it into smaller pieces, so that packet may be formed that can pass through a link with a smaller maximum transmission unit (MTU) than the original datagram size. These settings allow you to control such fragmentation, with settings such as the maximum memory to be used for fragmentation and the maximum number of fragments. Below this is “Flow Manager” settings, which allows you to control parameters for the flow engine. “Flow Timeout Settings” covers timeouts for TCP connections, UDP connections, and ICMP connections. Finally, “Stream Engine Settings” covers parameters for the stream engine, such as the maximum memory to be used be the stream engine and the maximum concurrent stream engine sessions.

In the next article, we will continue our look at Suricata interface settings.


External Links:

The official Suricata web site

ntop: An Introduction

ntopntop is a network probe that shows network usage. It displays a list of hosts that are currently using the network and reports information concerning the IP and non-IP traffic generated by each host. It is a simple, open source (GPL), portable traffic measurement and monitoring tool, which supports various management activities, including network optimization and planning, and detection of network security violations. In interactive mode, it displays the network status on the user’s terminal; in web mode, it acts as a web server, creating an HTML dump of the network status. ntop was developed by Luca Deri, a research scientist and network manager at the University of Pisa. It started development in 1997, and the first public release was in 1998 (v. 0.4). Version 2.0 was released in 2002 and added support for commercial protocols such as NetFlow v5 and sFlow v2, and version 3.0 was released in 2004 and added RRD support, as well as IPv6 and SCSI/FiberChannel support. Binaries for ntop are currently available for Ubuntu and Red Hat/CentOS.


Advantages of ntop

There are several advantages to using ntop. It is portable and platform neutral; you can deploy it wherever you want with the same look and feel. There are minimal requirements needed to leverage its use. Finally, it is suitable for monitoring both a LAN (by default) and a WAN (if ntop is configured properly).

We can classify the network activity measured by ntop into two categories: traffic measurement and traffic characterization and monitoring. Traffic measurement covers data sent and received, including volume and packets, classified according to network and IP protocol, as well as multicast traffic, TCP session history, bandwidth measurement and analysis, VLAN and AS traffic statistics, and VoIP monitoring. Traffic characterization and monitoring involves observing network flows as well as protocol utilization, ARP and ICMP monitoring, and detection of popular P2P protocols. Monitoring such traffic can be an aid in network optimization and planning which encompasses identification of routers and Internet servers, traffic distribution, service mapping, and mapping network traffic.

In the next article, I will cover integration of ntop into your network.


External Links:

The official ntop site

Wireless Support in pfSense

wirelessFirst, I should mention that this is the 100th post on this blog, which if nothing else, shows an unusual (for me) level of persistance on my part. Thanks to all who have visited this blog, visited this site’s Facebook page, or subscribed to this blog’s Twitter feed. I have a number of ideas on how to improve this blog, and I hope to implement some of them in the near future. Now, onto the topic of today’s posting: wireless support in pfSense.

pfSense includes built-in wireless capabilities that allow you to either turn your pfSense box into a wireless access point, use a wireless 802.11 connection as a WAN connection, or both. You can also use another wireless router in conjunction with pfSense. But if you want to use the built-in wireless capabilties, you first need one or more wireless cards supported by pfSense.

FreeBSD has supported wireless cards for a number of years, and there are a variety of wireless cards supported in FreeBSD 8.3. Needless to say, pfSense includes support for every card supported by FreeBSD, although some are supported better than others. Most pfSense developers work with Atheros hardware, so it tends to be the most recommended hardware. Many users have had success with other cards, however, and Ralink is also a popular choice. Other cards may be supported, but do not support all available features. For example, some Intel cards can be used in infrastructure mode but cannot be run in access point mode due to limitations of the hardware itself.


Another factor to take into account is that major wireless card manufacturers commonly change the chipsets used in their wireless cards without changing the model number. As a result, there is no way to ensure a specific model card from these vendors will be compatible, since you have no way of knowing which minor card revision you will end up with. While one revision of a model may be compatible and work, another card of the same model may be incompatible. For this reason, it may be a good idea to avoid cards from major manufacturers such as Linksys, D-Link and Netgear, although if you already have one, it is worth trying to see if it is compatible.

Supported Wireless Drivers

The following drivers are included in pfSense 1.2.1 and newer kernels:

  • ath(4): Supports cards based on the Atheros AR5210, AR5211 and AR5212 chipsets. The following cards are known to work in pfSense:
    • CB9-GP-EXT Cardbus/PCMCIA
    • 5004 MP Atheros 4G
    • DCMA-82 Atheros 6G
    • DCMA-82 Industrial Temp
  • rai(4): Ralink Technology IEEE 802.11 wireless network driver – supports cards based on the Ralink Technology RT2500, RT2501 and RT2600 chipsets. There are too many cards supported to list, but the FreeBSD man page for ral has a list of supported cards.
  • wi(4): Lucent Hermes, Intersil PRISM and Spectrum24’s IEEE702.11 driver supports cards based on the Lucent Hermes, Intersil PRISM-II, Intersil PRISM-2.5, Intersil, Prism-3, and Symbol Spectrum24 chipsets. These cards support only 802.11b, and a list of cards supported can be found at the FreeBSD man mage for wi.
  • an(4): Aironet Communications 4500/4800 wireless network adapter driver supports Aironet Communications wireless network adapters and variants, such as:
    • Aironet Communications 4500 and 4800 series
    • Cisco Aironet 340 and 350 series
    • Xircom Wireless Ethernet Adapter
  • awi(4): AMD PCnetMobile IEEE 802.11 PCMCIA wireless network drive – supports cards based on the AMD 70c930 controller with Intersil PRISM radio chipset, such as:
    • BayStack 650
    • BayStack 660
    • Icom SL-200
    • Melco WLI-PCM
    • NEL SSMagic
    • Netwave AirSurfer Plus
    • Netwave AirSurfer Pro
    • Nokia C020 WLAN
    • Farallon SkyLINE

With the release of pfSense 2.0, even more wireless cards were supported. Again, the list is too large to include here, but there is a spreadsheet of compatible wireless cards that should work with 2.0. Be aware of the “hostap” column, which shows drivers capable of running in wireless access point mode. If that column is marked “N”, then the card could only be used as a client. The second tab on the sheet lists part numbers for a given driver.

In the next article in this series, I will cover how to configure your wireless card.


External Links:

Supported Wireless Cards at doc.pfsense.org

Ad Links:




Traffic Shaping Wizard: Introduction

traffic shaping wizard

These are the options seen under the Wizards tab in the Traffic Shaper in pfSense 2.1.

Traffic Shaping Wizard Introduced

You can configure the traffic shaper through one of the traffic shaping wizards, manually through the pfSense web GUI, or even at by editing pf.conf in FreeBSD at the command line. It is recommended, however, that when you are using the traffic shaper for the first time, you use the traffic shaping wizard, which will guide you through the process. Due to the complexity of the shaper queues and rules, it is not a good idea to attempt starting out configuring the traffic shaper manually. If you need custom rules, step through the wizard and approximate what you will need, then make the custom rules afterward. Each screen will set up unique queues and rules that will control what traffic is assigned to the queues. If you want to configured everything manually, simply specify your WAN speed at the first screen, then click Next through all the remaining screens without actually configuring anything.


To start the traffic shaping wizard under pfSense 2.1, navigate to Firewall -> Traffic Shaper, and click on the “Wizards” tab. There are several different wizards, each one pertaining to a different pfSense network interface setup:

  • Single LAN multi WAN: There is one local network, but there are multiple interfaces for the WAN (this would be common in a load balancing scenario, in which outgoing and incoming traffic is distributed among two or more WAN interfaces). NOTE: You would also use this in the case where you only have one WAN and one LAN. Just specify 1 for the number of WAN links when going through the wizard
  • Single WAN multi LAN: There is only a single WAN interface, but there are multiple local networks.
  • Multiple LAN/WAN: This will set up traffic shaping in cases where you have both multiple local networks and multiple WAN networks.
  • Dedicated Links: This is for when you want to manage more than one link which gets routerd to a separate, different LAN in the same box. For example, assume you were providing services to 4 different customers in one building and they each had their own separate internet connections. You could run all 4 internet connections through a single pfSense box and provide different traffic shaping configurations for each. Thus, you could have several “virtual” links through a single interface.

In the next article, we will begin working our way through the traffic shaping wizard and look at the different options available within it.


Other Articles in This Series:

Traffic Shaping in pfSense: What it Does
QoS Management Using the Traffic Shaper Wizard
Queue Configuration in pfSense 2.1
Traffic Shaping Rules in pfSense 2.1
Layer 7 Groups in pfSense 2.1
Bandwidth Limiting with the pfSense Limiter
Deep Packet Inspection Using Layer 7 Traffic Shaping

External Links:

Traffic shaping at Wikipedia

External Links:

Traffic Shaping Guide at doc.pfsense.org

Link Ads:


pfSense Load Balancing: Part One

pfSense Load Balancing

Configuring OPT1 as WAN2 so we can set up a gateway group later on.

In computer networking, load balancing is a method for distributing workloads across multiple computers or a computer cluster, network links, CPUs, storage devices, or other resources. When load balancing is employed, we are looking not just to distribute workloads but to optimize resource use, maximize throughput, minimize response time, and avoid overhead. Using multiple components with load balancing instead of a single company can also increase reliability through redundancy. Load balancing has implicit failover capabilities, since load balancing software is capable of detecting when a resource (e.g. network interface, hard drive) is down and excludes it from the group. Load balancing is usually provided by dedicated software or hardware, such as a multilayer switch or a Domain Name System process, or, as we shall soon see, through pfSense. In this article, I will begin our look at pfSense load balancing.


pfSense Load Balancing: Gateway Configuration

As an example, let’s assume we want to set up multiple WAN interfaces and use load balancing on the group. A default WAN gateway was already created when pfSense was set up. In this example, we will use OPT1 as an additional gateway, and then add both the default interface and OPT1 to a newly-created gateway group, which will employ pfSense load balancing to distribute the workload in round-robin fashion.

The first part of our configuration follows the steps outlined in my <a href=”http://pfsensesetup.com/pfsense-gateways/”>article on gateways</a>. In order to set up our second gateway, first browse to System -> Routing. Click on the “Gateway” tab, if it is not already selected. Click on the “plus” button to add a new gateway. At “Interface”, select OPT1 in the drop-down box. At “Name”, type a name, such as “WAN2”. At “Gateway”, type in the IP address of the network interface (in this case, 192.168.3.1). Check “Default Gateway”, and at “Description”, add a description. Then press the “Save” button to save changes, and, if necessary, press the “Apply changes” button on the next screen.


Next, we will make some changes to the WAN interface (the one described as “Interface WAN Dynamic Gateway”). From the Gateways tab, click on the “edit” button. We can leave “Interface and Name” unchanged, but at “Gateway” we will type an IP address (in this case, 192.168.3.11). Click on “Default Gateway” and change the description to something appropriate (e.g. “WAN gateway). Then press the “Save” button to save the changes, and press the “Apply Changes” button if necessary.

Now we have the two interfaces configured correctly. In part two of this series on pfSense load balancing, we will take our newly-configured WAN interfaces and add them to a gateway group, and configure load balancing for the group.

Erratum: The Original Instructions I Posted Contained an Error, and Here’s Why

It occurred to me when composing Part Two of this article that I made a mistake. I set the WAN gateway to 192.168.4.1 originally; however, since WAN2 is on the 192.168.3.0 subnet, and both WAN gateways will likely be connecting to the same network, they should be on the same subnet. Therefore, I amended the instructions for Part One so that WAN is set to 192.168.3.11. I apologize for any confusion I may have caused.

Other Articles in This Series

pfSense Load Balancing: Part Two

pfSense Load Balancing: Part Three (Web Server Failover)

External Links:

Load Balancing at Wikipedia

Setup Incoming pfSense Load Balancing at doc.pfsense.org

Multi-WAN Load Balancing at pfsensesolution.blogspot.com

pfSense Traffic Shaping: Part One

pfSense Traffic Shaping

The traffic shaping wizard page in the pfSense web GUI.

Traffic shaping (also known as “packet shaping”, or “Quality of Service” [QoS]) is a computer network traffic management technique which prioritizes some datagrams while delaying other datagrams to bring them into compliance with a desired traffic profile. It is a form of rate limiting (a method of controlling traffic by which traffic that exceeds a specified rate is dropped or delayed) and is used to optimize or guarantee performance, improve latency, and/or increase usable bandwidth for some kinds of packets by delaying other kinds. It is widely used for network traffic engineering, and often appears in ISPs’ networks as one of several Internet Traffic Management Practices (ITMPs).

pfSense Traffic Shaping: An Example

pfSense Traffic Shaping

Configuring VoIP settings in the pfSense traffic shaping wizard.

In the following example, we will use pfSense traffic shaping to limit VoIP throughput to 125 kbps. First, navigate to Firewall -> Traffic Shaper. Select the “Wizards” tab. From the Wizards table, click on “Single WAN multi LAN“. [Assume we have a LAN and a DMZ.] On the next page, at “Enter number of LAN type connections“, enter “2”. At “Link Upload“, type the upload bandwidth (remembering to select either Kbit/s, Mbit/s, or Gbit/s in the drop-down boxes), and at “Link Download“, type the download bandwidth. Leave the other settings unchanged and click the “Next” button.

The next page deals with VoIP settings. At “Enable“, click on the check box to prioritize VOIP traffic. Under “VOIP specific settings“, assume we’re using Asterisk for VoIP and at “Provider” select “Asterisk/Vonage“. Set “Upload Speed” to 125 Kilobit/s, and set “Download Speed” to 125 Kilobit/s. Leave the other settings unchanged and click the “Next” button.


The next page, “PenaltyBox“, allows us to reduce the priority of an IP address or alias. We will assume that we have no use for this feature right now and click on the “Next” button.

pfSense Traffic Shaping

The final page in the pfSense traffic shaping wizard

The next page is for peer-to-peer networking and allows you to lower the priority and/or disable about 20 different specific P2P protocols. There is also a “P2P Catch all” queue which allows us to place all uncategorized traffic into the P2P queue. Again, we will assume that we have no use for this feature now and click on the “Next” button.

The next page is for network games, and allows us to raise the priority of gaming traffic and/or enable/disable specific games (e.g. Call of Duty, Unreal Tournament, World of Warcraft, and several others). Again we will click the “Next” button.

The final page, “Other Applications“, allows us to shape other common types of traffic. These include remote access programs like PC Anywhere, messaging programs like IRC and Teamspeak, VPN traffic, and other programs. Click on the “Next” button. On the next page, click the “Finish” button to apply the new settings.

We now have used pfSense traffic shaping to prioritize VoIP traffic while also limiting the amount of VoIP throughput to 125 Kbit/s. In part two of this series on traffic shaping, I will cover the Hierarchical Fair Service Curve, one of several traffic shaping algorithms supported by pfSense. In part three, I will cover class based queuing and priority queuing.


External Links:

Traffic Shaping Guide at doc.pfsense.org (with links)

Firewall Rules in pfSense: Part One

Firewall Rules: Part One

Firewall: Rules page in the pfSense web GUI.

In the previous article about NAT port forwarding, we used “Add associated filter rule” in order to generate the firewall rule for the Apache web server. We could, however, have chosen “None” for the “Filter Rule Association” and created the rule ourselves. This next article describes how to create firewall rules.


Adding Firewall Rules

In order to do this, first browse to Firewall -> Rules. There will be two pre-configured firewall rules by default: “Block private networks” (for blocking 10.x.x.x, 172.16.x.x, and 192.168.x.x addresses) and “Block bogon networks” (for blocking bogus addresses). There will be at least three tabs: “Floating“, “WAN” and “LAN“. Select “WAN” if it isn’t already selected. Press the “Plus” button to add a new firewall rule. Under “Action”, there are three options: “Pass“, “Block”, and “Reject“. The web GUI has the following explanation of the difference between “Block” and “Reject“:

Hint: the difference between block and reject is that with reject, a packet (TCP RST or ICMP port unreachable for UDP) is returned to the sender, whereas with block the packet is dropped silently. In either case, the original packet is discarded.

In this case, you can leave the default unchanged as “Pass“. Next is the option to “Disable this rule“; we don’t want to do this so leave this box unchecked. At “Interface”, you will again have a choice of “LAN“, “WAN” and whatever other interfaces were configured; choose “WAN“.

Firewall Rules: Part One

Adding a firewall rule in pfSense.

At “Protocol“, there are a number of options in addition to the four listed under NAT port forwarding. “ICMP” stands for Internet Control Message Protocol and is used to send error messages indicating, for example, that a requested service is not available or that a host or router could not be reached. ICMP can also be used to relay query messages. “AH” stands for Authentication Header, which is part of the IPsec suite and provides connectionless integrity and data origin authentication for IP datagrams and provides protection against replay attacks. “IGMP” stands for Internet Group Management Protocol and is a connectionless protocol used by hosts and adjacent routers on IP networks to establish multicast group memberships; it is used for one-to-many networking applications such as online streaming video and gaming, among other uses. “OSPF” stands for Open Shortest Path First, a link-state routing protocol for IP networks that uses a link state routing algorithm and falls into the group of interior routing protocols. “CARP” stands for Common Address Redundancy Protocol, a protocol which allows multiple hosts on the same local network to share a set of IP addresses. Its primary purpose is to provide failover redundancy. Finally, “pfsync” is a computer protocol used to synchronize firewall states between machines running Packet Filter (PF) for High Availability. If is used along with CARP to make sure a backup firewall has the same information as the main firewall. In this case, we should leave the default protocol “TCP” unchanged.


At “Source“, specify “any”, as the “Type” and at “Source Port Range“, also specify any. The “Type” options are the same as the options under “Source” and “Destination” for NAT port forwarding; therefore I will not go into detail on them here. In “Destination“, select “Single host or alias” as the type, and specify 192.168.1.125 (our Apache server) for the “Address”. At “Destination Port Range“, specify “HTTP“. You can leave “Log packets that are handled by this rule” unchecked unless you have reason to log the packets. Specify a “Description” if you wish and press the “Save” button to save the changes.

Firewall Rules: The Source Port Range is Usually Unknown

It should be noted that when a firewall rule is created, the “Source Port Range” is almost always set to “any“. This is because the client decides which port to open on the client computer, which may or may not be the same as the port requested on the server. The source port is an an ever-changing port which the end user probably never knows about. So most of the time, we will not know the Source Port Range of the traffic being allowed in.

In the next article, I will go into some detail on rules governing firewall rules, and some of the advanced options for firewall rules under pfSense 2.0.

External Links:

Firewall Rule Basics at doc.pfsense.org

Port Forwarding with NAT in pfSense

Firewall Configuration: NAT port forwarding

Firewall -> NAT configuration page in the pfSense web GUI.

In computer networking, Network Address Translation (NAT) is the process of modifying IP address information in IPv4 headers while in transit across a traffic routing device. In most cases, it involves translating from the WAN IP address to the 192.168.x.x addresses of your local network. In this article, I will describe how to set up NAT port forwarding.

NAT and firewall rules are distinct and separate. NAT rules forward traffic, while firewall rules block or allow traffic. In the next article, I will cover firewall rules, but for now keep in mind that just because a NAT rule is forwarding traffic does not mean the firewall rules will allow it.

NAT Port Forwarding

NAT port forwarding rules can differ in complexity, but in this example, let’s assume we set up an Apache server at 192.1.168.125 on the local network, and we want to direct all HTTP traffic (port 80) to that address. First, browse to Firewall -> NAT. The options are “Port Forward“, “1:1” and “Outbound“. Select the “Port Forward” tab. Click the “plus” button in order to create a new NAT port forward rule. “Disable the rule” and “No RDR” can be left unchanged. For “Interface” you can choose WAN and LAN; we are concerned about incoming requests from the Internet, so you can keep it as WAN.


For “Protocol”, there are five choices: TCP, UDP, TCP/UDP, GRE, and ESP. TCP stands for Transmission Control Protocol, and is the transport level protocol of the Internet protocol suite. This is usually what we want to use. Next is UDP, or User Datagram Protocol, another transport level protocol which is also part of the Internet protocol suite. It is suitable for purposes where error checking and correction are either not necessary or are performed in the application. GRE stands for Generic Routing Encapsulation, a tunneling protocol that can encapsulate a wide variety of network layer protocols inside virtual point-to-point links. It can be used, among other things, in conjunction with PPTP to create VPNs. ESP stands for Encapsulating Security Payload, a member of the IPsec protocol suite which provides authenticity, integrity and confidentiality protection of packets. In this port forwarding scenario, you can leave the protocol unchanged (TCP).

Firewall Configuration: NAT

Adding a NAT port forwarding rule.

For “Source“, you can specify the allowed client source. Typically you can leave it as “any”, but there are several choices: “Single host or alias“, “Network“, “PPTP clients“, “PPPoE clients“, “L2TP clients“, “WAN subnet“, “WAN address“, “LAN subnet“, and “LAN address“. In this case, you can leave the default (any) unchanged.

For “Source port range“, we want to redirect HTTP traffic (port 80), so choose HTTP for the from and to drop-down boxes. “Destination” offers the same choices as “Source” and can be left unchanged. “Destination port range” should be changed to HTTP for the from and to drop-down boxes. For “Redirect target IP“, specify the web server the traffic to be forwarded to (in our case, 192.168.1.125). For “Redirect target Port“, choose HTTP. Next is “No XMLRPC Sync“; enable this option to prevent this rule from being applied to any redundant firewalls using CARP. This option can be left unchecked now. “NAT Reflection” can be enabled or disabled, usually it is disabled. “Filter Rule association” will automatically create a firewall rule and associate it to this NAT rule. Check this box to avoid having to create a separate firewall rule. Add a description if you wish, and press “Save” to save the changes. The port forwarding rule set up should now be in effect.

NAT Port Redirection

In this case, we passed traffic from port 80 on the source to port 80 on the destination, which is the classic port forwarding scenario. But there’s no reason you can’t redirect traffic to a different port. There are two reasons you might want to do this:

[1] Security: A good way to thwart hackers is to put services on non-standard ports. For example, everyone knows the standard port for FTP is 21, but an outsider is unlikely to find your FTP server if you place it on port 69, or better yet, an even higher port number (e.g. 51782). The same can be said of SSH. Users will have to know the port in order to access it.

[2] Single Public IP Address, more than one computer with the same services: Smaller networks with only a single public IP address may be stuck if the want to expose a lot of public services. For example, imagine that we want to have two separate FTP servers, but on two separate computers. With port redirection, we create two different NAT rules: the first rule will redirect port 51782 to port 21 on FTPServer1, and the second will redirect port 51783 to port 21 on FTPServer2. We can then remote into two separate FTP servers on two different computers using the same IP address.


External Links:

Port Forwarding Troubleshooting at doc.pfsense.org

pfSense Setup: Part Four (Setting up a DMZ)

DMZ

The optional interface configuration page in the pfSense web GUI (which is similar to the WAN and LAN config pages).

In the first three parts, I covered booting and installing pfSense, general configuration options in the pfSense web GUI, and configuring WAN and LAN interfaces (also with the web GUI). In this part, I cover using an optional interface to create a DMZ.

In networking, a DMZ (de-militarized zone) is a place where some traffic is allowed to pass and some traffic is not. The area is separate from the LAN and WAN. In simple terms, a DMZ looks like this in relation to the rest of the network:

Internet traffic | <- DMZ <- LAN

Unsafe Internet traffic is allowed to enter the DMZ, but not the LAN. To configure it, we will need an optional interface.

Configuring the DMZ

From the web GUI, browse to Interfaces -> OPT1. If “Enable Interfaces” isn’t checked, check it. Set “Description” to DMZ. Under “Type”, choose “Static” as the address configuration method. For “IP address”, enter an IP address and the subnet mask (the subnet should be different than the subnet for your LAN). For example, if your subnet for the LAN is 192.168.1.x, it could be 192.168.2.x for the optional interface.

For “Gateway”, leave this option set to “None”. The last two options are “Block private networks” and “Block bogon networks”. Ensure that these two options are unchecked; we don’t want the system to block access from the Internet to the DMZ. Finally save changes by pressing the “Save” button.


Now that the DMZ is configured, your DMZ will allow WAN access. Your DMZ will also allow access from the LAN, but it won’t be permitted to send traffic to the LAN. This will allow devices on the Internet to access DMZ resources without being able to access any of your LAN. This could be useful, for example, for setting up an e-mail or FTP server.

You could now attach a switch to your DMZ interface. This would enable you to connect multiple machines to the DMZ.

External Links:

Setting Up a DMZ in pfSense


The Rest of the Guide:

Part One (installation from LiveCD)

Part Two (configuration using the web GUI)

Part Three (WAN and LAN settings)

Ad Links:


© 2013 David Zientara. All rights reserved. Privacy Policy