pfSense Multi-WAN Configuration: Part Three

pfSense multi-WAN

Advanced Outbound NAT settings in pfSense 2.2.4.

Some multi-WAN configurations require special workarounds because of limitations in pfSense. This article covers those special cases.

Because of the way pfSense distributes traffic over multiple Internet connections using the same gateway IP, you will need to insert a NAT device between all but one of those connections. This is not an elegant solution, but it is a workable one.

pfSense can only accommodate one PPPoE or PPTP WAN connection. Therefore, OPT WAN interfaces cannot use PPPoE or PPTP WAN types. If you need to use PPPoE or PPTP, the best workaround is to use them on your modem or another firewall. Most DSL modems can handle PPPoE and either directly assign your public IP to pfSense or give it a private IP and provide NAT. Public IP passthrough is possible on many modems and is the preferred means of doing this.

pfSense Multi-WAN: NAT Rules

The default NAT rules generated by pfSense will translate any traffic leaving the WAN or an OPT WAN interface to that interface’s IP address. In a default two interface LAN and WAN configuration, pfSense will NAT all traffic leaving the WAN interface to the WAN IP address. The addition of OPT WAN interfaces extends this to NAT any traffic leaving an OPT WAN interface’s IP address. This is the default behavior and is all handled automatically unless Advanced Outbound NAT is enabled. The policy routing rules direct the traffic to the wAN interface used, and the outbound and 1:1 NAT rules specify how the traffic will be translated. If you require Advanced Outbound NAT with multi-WAN, you will need to configure NAT rules for all your WAN interfaces.

When using port forwarding with a multiple WAN setup, keep in mind that each port forward applies to a single WAN interface. A given port can be opened on multiple WAN interfaces by using multiple port forward entries, one per WAN itnerface. The easiest way to accomplish this is to add the port forward on the first WAN connect, then click the plus button to the right of that entry to add another port forward based on that one. Change the interface to the desired WAN interface, and press the Save button.

1:1 NAT entries are specific to a single WAN interface. Internal systems can be configured with a 1:1 NAT entry on each WAN interface, or a 1:1 entry on one or more WAN interfaces and use the default outbound NAT on others. Where 1:1 entries are configured, they always override any other Outbound NAT configuration for the specific interface where the 1:1 entry is configured.

External Links:

Network Load Balancing on Wikipedia

Video: Configuring Dynamic DNS with pfSense

You may want to set up a domain name for your home or SOHO WAN IP. This video demonstrates how to do this. In this video I cover:

  • What DDNS is, why you might want to use it, and different methods of implementing DDNS
  • Configuring Duck DNS on the Duck DNS web site; downloading and installing the Duck DNS client
  • Configuring DDNS in pfSense and setting up NAT so we can access an Apache web server behind the firewall
  • Accessing a web site using the domain name I set up in the previous steps

netfilter Operation: Part Fourteen (Firewall Builder, conclusion)

Firewall Builder

Adding inbound and outbound NAT rules in Firewall Builder.

As you can probably see, once you have completed the up-front work of defining your objects, adding or modifying rules is simple. Additionally, unlike the other free GUI solutions, Firewall Builder allows you to centrally and securely administer all of your (supported) firewalls from one location.

Notice that the default chains have rules matching the rule you configured in Firewall Builder, with a target of RULE_<RULE_NUMBER>. These additional chains are used to configure the logging. there s also a rule at the beginning of all chains to ACCEPT traffic related to an established session. This is generally desirable but is still configurable. To remote this automatically generated rule, select the firewall in the object tree and click on Firewall Settings in the dialog area. There is a checkbox that is selected by default called “Accept ESTABLISHED and RELATED packets before the first rule.” Although the Firewall Builder policies you’ve configured can handle any basic rules you might need, there are still a few more issues to cover. If you need to NAT with your Linux firewall, configuring it with Firewall Builder is easy. Follow these steps so that your firewall with NAT all the traffic from the internal network to the DHCP address used on the outside interface. This configuration is also known as source.nat because it is the source address that is being changed.

  1. In the Object Tree, select NAT.
  2. Move your mouse to the pane to the right of the Object Tree, right-click and select Insert Rule.
  3. Drag your INTERNAL network object from the object tree to the Original Src column in the new NAT policy.
  4. Drag the external interface on the firewall from the object tree to the “Translated Source” column in the NAT policy.


Now, save, compile and install the new policy. Now traffic originating from the internal network will be NAT-ed to the IP on the external interface. Although this source NAT configuration will allow all your internal users to reach the internet, you will need to use destination NAT if Internet users need to reach an internal server. Because the internal server is using a private IP address (which is not routable on the Internet), you need to translate this destination to an IP address that the external users can reach. To configure packets destined for the firewall’s single public IP address to an inside resource using destination NAT, follow these steps:

  1. In the Object Tree, select NAT.
  2. Right-click on rule number zero of the existing NAT ule and select Add rule at Bottom.
  3. Drag the firewall OUTSIDE interface into the Original Destination column of the new rule.
  4. Drag the appropriate services (HTTP and HTTPS) into the Original Service column of the new rule.
  5. Drag the internal server into the translated destination column of the new rule.

Firewall Builder: Creating a Time Policy

Firewall Builder

Creating a time policy with Firewall Builder.

Another nice feature is being able to create a time policy. In this example, we’ll alter the rules so the internal systems can only surf the web from noon to 1:00 PM:

  1. In the Object Tree, right-click Time, and select New Time Interval.
  2. In the “Name” field, we’ll call this rule LUNCH.
  3. In the two time fields provided, enter a time for the rule to START and a time for the rule to STOP. In this case we will enter 12:00 and 13;00 and leave the date field as zeros. You can check off every day of the week at the below the time fields, so the time interval applies to all days. When done, click Apply.
  4. Drag the LUNCH time interval from the Object Tree to te Time column of rule #1.

Now, rule #1 (which permits outbound web surfing) will only be active from noon to 1:00 PM. The ability to configure the rules to be active based on the time of day is a very powerful feature. If the organization is a strictly 8 AM to 5 PM type of place, you could configure the firewall to disable all access during non-business hours. Alternatively, certain non-business-related protocols could be enabled after the normal business day ends.


External Links:

The official Firewall Builder site

netfilter Operation: Part Six

netfilter operationIn the previous article, we began the process of simulating a home router with netfilter. We will continue that process in this article.

We began with the these iptables commands:

iptables -P OUTPUT ACCEPT
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -p tcp -s 192.168.1.0/24 -i eth0 –dport 80 -j ACCEPT
iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -o eth1 -j ACCEPT
 iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT

The INPUT chain allows port 80 to go to the firewall itself from the internal network. Many of the home routers have a Web interface for configuring them, and while your configuration may not need this port open to the firewall, it is included here to help emphasize how the different chains are used. It is important to specify the input interface (using -i) so that the source IP cannot be spoofed by an external attacker. In this way, you ensure that even if a packet was generated with the proper source IP, if it came in on the outside interface (eth1) it would not match the rule and would thus not be permitted. The FORWARD rule allows any outbound traffic from the internal network to the external network. This configuration is simple to implement; however, the 192.168.1.0 IP range is a private IP range and is not routable on the Internet. Thus, this range would not allow traffic from the internal network to the Internet quite yet. To make this Linux firewall a useful replacement for a home network router, you need to enable NAT, which allows all of the systems on your internal network to appear as a single IP address when communicating on the Internet.

Enabling NAT

In principle NAT is simple, but in a complex environment it can get confusing. Basically, NAT means that the NAT device (in this case the Linux netfilter firewall) will change the IP address in apacket and retransmit that packet. Depending on your needs, you can alter the source IP address (source NAT, or SNAT), the destination IP address (destination NAT, DNAT), or both (double NAT). With a home router, the objective behind the NAT capability is to allow all of the internal hosts to communicate on the Internet using the single public IP provided by your Internet Service Provider (ISP). (In this case, SNAT is being used). As each of the hosts on your private network make a connection to an Internet server, the firewall is altering the source address to look like the public IP from your ISP. By doing this, the return traffic can find its way back to the firewall and be retranslated and sent to the originating host.


In this example, assume that the internal host has a private IP address of 192.168.1.11. The public address of the firewall is 5.5.5.5, which is provided by the ISP. If a host on the private network wants to make a connection to pfsensesetup.com. The firewall alters the source address to its own public IP address of 5.5.5.5 and sends the packet on its way. When the server replies to destination 5.5.5.5, the firewall again edits the packet, this time inserting a new destination of 192.168.1.11. All of this takes place and is transparent to the 192.168.1.11 host and the pfsensesetup.com server. When multiple hosts are using SNAT, the firewall tracks which connections belong to which private hosts using the port numbers. While the destination port of the Web server remains static (typically port 80 for the Web), the source port is usually a random port above 1024. By tracking the source port, the firewall knows which address belongs to which session. In the event that two hosts attempt to use the same source port, the NAT device edits the source port of one of the connections and replaces it with another random source port. When the return traffic is received, it translates the source port back, just like it did for the IP address. because this method of NAT relies heavily on using the source port number, it is sometimes referred to as port NAT (PNAT).

To add the SNAT functionality to the example firewall, use the following command:

iptables -t nat -A POSTROUTING -o eth1 -j SNAT –to-source 5.5.5.5

The -r option is used to specify the table we want to modify, and -A option specifies that we are going to append this rule to the POSTROUTING chain. By specifying the outbound interface, we are ensuring that the SNAT only occurs as traffic leaves the private network, meaning only in the proper direction.

The jump target SNAT is self explanatory. The –to-source option specifies what IP address we want to use as the new source address. SNAT assumes we have a static IP address to SNAT the outgoing packets to. While this is likely the case in a corporate environment, a more appropriate solution to more closely mimic the configuration of a home router would be to use the MASQUERADE command:

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

The masquerade command does not require an IP specification, and will use the IP address of the firewall interface. You might be wondering why you would not use the masquerade target all of the time instead of the SNAT target. Because the source IP is static, the SNAT target will cause the NAT calculations to be performed once for a given session. Subsequent packets belonging to that session are handled the same way as the first. With the masquerade target, each packet is checked for the source IP to use, which requires more overhead than with SNAT. This is why SNAT is preferable if you have a static source IP address, and masquerade is your only option if you do not have a static source IP address to use.


External Links:

Linux 2.4 NAT HOWTO at www.netfilter.org

netfilter Operation: Part One

netfilter operationBefore covering some of the specific commands used to configure the Linux firewall, I will cover some basic Linux firewall vocabulary and some of the basics of netfilter operation. netfilter contains the firewall logic, and iptables is the program that is used to modify the rules that the firewall uses. These rules (or ACLs) define the rules used to permit or deny packets and how to react to denied packets. The current iptables use both tables and chains. Tables are the blocks of processing where various actions are performed on the packets. Different tables process different chains. Chains are a set of rules (or ACLs). There are four built-in tables that help define netfilter operation: nat, mangle, filter and raw, each of which processes different chains.

netfilter Operation: Tables and Chains

The following tables and chains are not listed in any particular order, as a given packet may be impacted by multiple tables and chains as it is processed. The primary built-in chains are INPUT, OUTPUT, and FORWARD. In addition to these, you can create your own user-defined chains to customize netfilter operation.


  • Nat Table: In netfilter operation, this table is referenced with a packet that is used to create a new connection.
    • PREROUTING: This chain is processed as soon as a packet is received and before any routing decisions are made.
    • POSTROUTING: This chain is processed before a packet is sent to an interface but after any routing decisions have been made.
    • OUTPUT: This chain is processed for packets generated locally.
  • Filter Table: This is the default table that is used when the iptables command is used to modify the rules and do not specify an alternate table. This is where the bulk of a firewall’s processing is consumed.
    • INPUT: This chain is processed for packets destined for the local system.
    • FORWARD: This chain is processed for processed for packets passing through the local system.
    • OUTPUT: This chain is processed for packets generated by local system.
  • Mangle Table: This table is used for any specialized packet alterations that are needed. Examples are performing Network Address Translation (NAT) or manipulating various bits within the packet.
    • PREROUTING: This chain is processed on incoming packets before a routing decision is made.
    • POSTROUTING: This chain is processed last before a packet is sent to an interface.
    • OUTPUT: This chain is processed before a routing decision is made for packets generated locally.
    • INPUT: This chain is processed for packets destined for the local system.
    • FORWARD: This chain is processed for packets passing through the local system.
  • Raw Table: This table is primarily used for packets that are exempt from connection tracking, and if required, are called before any other netfilter table.
    • PREROUTING: This chain is processed as soon as a packet is received.
    • OUTPUT: This chain is processed for packets generated locally.


Now that we have reviewed all the various tables and chains, we can continue our look at netfilter operation by discussing the overall packet flow, which we will do in the next article.

External Links:

Netfilter Overview at www.shorewall.net

How the netfilter System Works at www.mad-hacking.net

NAT and Firewall Advanced Options in pfSense

In this article, I will cover some additional advanced settings available for firewall and NAT, which you can find by navigating to System -> Advanced and clicking on the “Firewall/NAT” tab.

Firewall Advanced Options

NAT

Advanced firewall and NAT options in pfSense.

Under “Firewall Advanced”, you will find the “Bypass firewall rules for traffic on the same interface” check box. This option applies only if you have defined one or more static routes (and presumably, at least one gateway; I covered configuring static routes in a previous article). If multiple subnets are connected to the same interface (e.g., if you divide the LAN into two or more separate subnets), using this option may be advantageous.

Next is the “Disable all auto-added VPN rules” check box. Checking this will disable any rules automatically added when a VPN was created. Next is the “Disable reply-to on WAN rules” check box. With Multi-WAN, you generally want to ensure traffic leaves the same interface it arrives on. Hence, reply-to is added automatically by default. When using bridging (or 1:1 NAT port forwarding with multiple interfaces), you must disable this behavior (by checking this box) if the WAN gateway IP is different from the gateway IP of the hosts behind the bridged interface. Finally, there is the “Disable Negate rule on policy routing rules” check box. With Multi-WAN, you generally want to ensure traffic reaches directly connected networks and VPN networks when using policy routing. You can disable this for special purposes (by checking this box), but it requires manually creating rules for this network.


NAT Advanced Options

The next section is “Network Address Translation”. The first option is the “Disable NAT Reflection for port forwards” check box. With NAT reflection, packets from internal networks that are addressed to the network’s public IP address will be treated as if they are coming from from the WAN interface. The router’s port forwarding rules will then determine where the packets go. Checking this box disables the automatic creation of additional NAT redirect rules for access to port forwards on your external IP addresses from within your internal networks.

Next is “Reflection Timeout“. This edit box allows you to set a NAT reflection timeout in seconds. The next option is the “NAT Reflection for 1:1 check box“. Checking this disables the automatic creation of additional NAT 1:1 mappings for access to 1:1 mappings of your external IP addresses from within your internal networks. The next check box is “Automatically create outbound NAT rules which assist inbound NAT rules that direct traffic back out to the same subnet it originated from.” This only applies to 1:1 NAT rules, and is helpful when NAT reflection is enabled.


The last option is “TFTP Proxy“. You can click on an interface listed (hold down SHIFT to select multiple interfaces) to enable TFTP proxy on the interface. Since TFTP is considered to be a security risk (no security or authentication is provided by the protocol specification), this option should only be enabled if absolutely necessary. Finally, click on “Save” to save the changes.

Other articles in this series:

webConfigurator options in pfSense

Admin Access Options in pfSense

Firewall Advanced Options in pfSense

External Links:

Network Address Translation at Wikipedia

pfSense Virtual IP Addresses: Part Two

In the previous article, I covered setting up pfSense virtual IP addresses with Proxy ARP and CARP. In this article, I will cover pfSense virtual IP addreses with IP Alias and Other types.

pfSense Virtual IP Addresses: IP Alias

pfSense virtual IP addreses

Setting up a pfSense virtual IP address with IP Alias in pfSense 2.0.

IP aliasing is the ability to associate more than one IP address to a network interface. With it, one node on a network can have multiple connections to a network, each serving a different purpose. In a sense, it is the reverse of some of the other scenarios envisioned with virtual IP addresses, in which traffic for one IP address can be directed to several different nodes. IP Alias is:

  • New to pfSense 2.0 (and later)
  • Can be used or forwarded by the firewall
  • Allows entire IP addresses to be added to an interface
  • Works on Layer 2 (Data link layer)
  • Can be in a different subnet than the real interface IP
  • Will respond to a ping request if allowed by firewall rules
  • Can be stacked on top of a CARP VIP to bypass VHID limits and lower the amount of CARP heartbeat traffic. Stacked IP Alias VIPs will synchronize via XMLRPC.
  • Can be used with CARP to add additional subnets to CARP, e.g. Add one unique IP Alias from the new subnet to each node, then add CARP VIPs. Must be added to each node individually as these will not synchronize via XMLRPC or else an IP conflict would occur.


To set up a VIP using IP Alias, start at Firewall -> Virtual IPs and once again click on the “plus” button to add a new virtual IP address. Select “IP Alias” as the “Type” with the radio buttons at the top. For “Interface“, select “WAN” (it should be the default). At “IP Addresses“, type an address at “Address” (everything else should be grayed out). At “Description“, add a description if desired. Click on the “Save” button to save the changes, and then on the next screen, click on “Apply changes” if necessary.


pfSense Virtual IP Addresses: Other

“Other” is the only option of the four provided for VIPs in pfSense 2.0 that can be used if routed to the firewall without needing ARP/Layer 2 messages. Its properties are:

  • Can only be forwarded by the firewall
  • Can be in a different subnet than the interface
  • Cannot respond to pings
  • Can be added individually or as a subnet to make a group of VIPs (As of 2.1)
  • Can be used with CARP, e.g. subnet routed to external CARP VIP

Notably, both IP Alias and Other can be used for clustering (master firewall and standby failover firewall).
To add a virtual IP of type “Other”, again navigate to Firewall -> Virtual IPs and click the “plus” button to add a new virtual IP address. At type, choose “Other” with the radio buttons. At “Interface“, select “WAN” (the default). At “IP Addresses“, type an address at “Address” (all other options are grayed out). At “Description“, add a description if desired. Then press “Save” to save the changes and press “Apply changes” if necessary.

As you can see, setting up pfSense virtual IP addresses is almost trivially easy. The more difficult task is deciding which type of VIP is suited for your requirements and choosing accordingly. The official pfSense documentation site has a table which lists some of the features of the different pfSense VIP types, and I am reprinting it here:

VIP Features Table

VIP Features
VIP Type Version NAT Binding ARP/L2 Clustering In Subnet Subnet Mask ICMP Single/Group
CARP 1.x+ Yes Yes Yes Yes Yes Yes Yes Single
Proxy ARP 1.x+ Yes No Yes No No n/a No (1) Either
Other 1.x+ Yes No No Yes (2) No n/a No (1) Either
IP Alias 2.0+ Yes Yes Yes See Notes No No Yes Single

1: ICMP Column represents responses from the firewall itself without NAT. With 1:1 NAT, any VIP will pass ICMP through to the target device. On 2.1+ ICMP can also be used as a protocol in port forward entries.
2: “Other” type VIPs are for routed subnets, and CARP is irrelevant, so they work

External Links:

What are Virtual IP Addresses? at doc.pfsense.org

Firewall Rules in pfSense: Part Two

Firewall Rules

Highlighting a rule in the pfSense GUI.

In the previous article, I covered basic firewall rules in pfSense. But pfSense 2.0 has a whole new set of advanced setup options, which I will cover in this article.

pfSense rules are evaluated from the top down. The first rule to match is executed and the rest of the rules are skipped. It is a good idea to put very specific rules at the top and more generic rules at the bottom, and this is what many administrators do. To reorder a rule, simply select the rule and click the “move selected rules before this rule” button.


You also may want to create a rule that’s very similar to an existing rule. To save time, you can copy the rule with the “add a new rule based on this one” button (the plus button).

Firewall Rules: Advanced Features

Firewall Rules

Advanced features section for firewall rules in the pfSense web GUI.

With pfSense 2.0, when you add or edit firewall rules, there is an Advanced Features section. Various features can be specified as criteria for a rule. If an advanced feature is specified, the rule will only be executed if a match is found. Click the Advanced button for each feature to display configuration settings for that feature. Here are the features:

Firewall Rules

Source OS option under firewall rules in pfSense 2.0.

  • Source OS: This option will attempt to match the operating system of the source traffic. The UNIXoid world is well represented on this list, with FreeBSD, NetBSD, and OpenBSD on the list, as well as Linux and Solaris. Windows and Novell are also on the list.
  • Diffserv Code Point: Diffserv is a mechanism for providing Quality of Service of network traffic. Systems can prioritize traffic based on their code point values.
  • Advanced Options: This contains a number of options. The options are as follows:
    • Allow packets with IP options to pass: Packets with IP options are blocked by default, and for good reason: some IP options can be used by attackers to hide the true source of a packet or to gain access to a protected network, or to glean information about the topology and the addressing scheme of a network. Also, IP options tax the CPU of the router, and may be used in denial of service (DoS) attacks. Nonetheless, there may also be legitimate reasons for allowing these packets to pass.
    • Disable auto-generated reply-to for this rule: By default, pfSense replies to a host regarding a rule; this disables it.
    • Mark a packet: Mark a packet matching a rule; you can then use this mark to match on other NAT/filter rules.
    • Match packet on a mark placed before on another rule.
    • Maximum state entries this rule can create: Limits the maximum number of state entries this rule can create to a specific number. If the maximum is reached, packets that would normally create state fail to match this rule until the number of existing states falls below the limit.
    • Maximum number of unique source hosts: Limits the number of unique hosts to this number.
    • Maximum number of established connections per host: Limits the number of connections per host to this number; good for protecting against DoS attacks.
    • Maximum state entries per host: Limits the number of state entries per host to this number.
    • Maximum new connections/per seconds: Limits the number of connections to X connections per Y seconds, where X and Y are entered here.
    • Timeout in seconds
  • TCP Flags: Specific TCP flags can be set here. These flags are:
    • FIN – No more data from sender
    • SYN – Synchronize sequence numbers (seen on new connections)
    • RST – Reset the connection (seen on rejected connections)
    • PSH – Push function
    • ACK – Indicates that the ACKnowledgment field is significant
    • URG – Indicates that the URGent pointer field is significant
  • State Type: Select which type of state stracking mechanism you would like to use from the following options – keep state, sloppy state, synproxy state (to protect against TCP SYN floods), and none. If in doubt, use keep state.
  • No XMLRPC Sync: This prevents a rule from syncing with the other CARP members.
  • Schedule: Specify the schedule for when the rule is valid. Schedules defined in Firewall -> Schedules will appear in the drop-down box.
  • Gateway: Gateways other than the default may be specified here. Leave as ‘default’ to use the system routing table.
  • In/Out: Specify alternative queues and virtual interfaces. Choose the Out queue/Virtual interface only if you have also selected In. The Out selection is applied to traffic leaving the interface where the rule is created, In is applied to traffic coming into the chosen interface. If you are creating a floating rule, if the direction is In then the same rules apply, if the direction is out the selections are reverted Out is for incoming and In is for outgoing.
  • Ackqueue/Queue: Specify alternative acknowledge queries here.
  • Layer7: Choose a Layer7 container to apply application protocol inspection rules. These are valid for TCP and UDP protocols only.

That covers advanced options for firewall rules in pfSense 2.0, demonstrating the unique level of granularity that pfSense offers in firewall configuration. Most of these options can be left unchanged a majority of the time, but many of them, such as “Source OS”, will undoubtedly be useful in enterprise-level deployments.


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

© 2013 David Zientara. All rights reserved. Privacy Policy