1.
NAT on pfSense 2.3
May 2016 Hangout
Jim Pingle

2.
NAT on pfSense 2.3
● Project News
● What is NAT?
● Inbound NAT
● Should you use Inbound
NAT?
● Can you use Inbound NAT?
● Port Forwards or 1:1
● Port Forward Capabilities
● Port Forward Example
● 1:1 NAT Capabilities
● 1:1 NAT Example
● NAT Reflection
● Outbound NAT
● Outbound NAT Modes
● Outbound NAT Capabilities
● Outbound NAT Examples
● Troubleshooting
● Q&A

3.
Project News
●
2.3.1 is out!
– Maintenance release with fixes since 2.3
– Fixes lots of upgrade issues and misc things found since 2.3 released, plus a couple security issues
●
2.3.1_1 Also out, security & minor update
●
μFW teased on Twitter (aka MicroFW or uFW)
– ARM-based board that will run pfSense
– Small! 77.4mm x 43.2mm
– Two real Ethernet interfaces
– https://twitter.com/gonzopancho/status/731245772721651712
● μBMC coming as well, ARM-based open solution for OOB management like IPMI
– pfSense test build already running: https://twitter.com/gonzopancho/status/735704319874371584
●
Netgate/pfSense was at Interop in Las Vegas and then OSCON, BSDCan coming up in
June
●
pfSense is live on Azure, version will be updated soon (process has been going for a long
time!)
●
Online training schedule for the rest of the year is up
– http://netgate.com/training/

4.
What is NAT?
● Network Address Translation
● Strictly speaking much of what is commonly referred to as "NAT" is really PAT,
Port Address Translation
● Port forwards/inbound NAT is destination NAT (aka DNAT)
– Changes the destination address of a packet as it enters an interface
● Outbound NAT is source NAT (aka SNAT)
– Changes the source address of a packet as it exits an interface
● Typically used to allow networks with no direct routing to reach each other
without tunneling. It forwards and presents the traffic as if it is from a reachable
address.
– Ex: Outbound NAT to allow private LAN hosts to reach the Internet
– Ex: Port forwards to allow Internet hosts to reach services on private LAN
– Ex: Outbound NAT for VPN hosts to reach a local device that has no gateway
● Processed before firewall rules

5.
Inbound NAT
● Port Forwards and 1:1 NAT both can handle inbound
traffic, forwarding requests sent to the firewall on to a new
target
● Three components:
– Source (Client): The initiator of the request
– Destination (pfSense): The original IP address that receives the
request from the client
– Target (Server): The local, translated address to which the
request is forwarded
● Firewall rules use the private IP address after NAT as
destination

6.
Should you use Inbound NAT?
● Exposing a service on the local network to the Internet should not be taken lightly
● Exposing a service poses an immediate security risk
– If the server is compromised, it could be used to compromise other hosts in the local network
● Ideally, a server should be in a DMZ, but often that is prohibitively difficult for small
networks
● Only publicly accessible services (such as a public web server) should be exposed in
this way
● Private resources should be accessed using a more secure means of connecting,
such as a VPN
– SQL servers, cameras, RDP services, etc
● Restricting remote access to a specific source network can be safe so long as the
service is encrypted
● Port forwards are not needed to access resources on the firewall itself (e.g. WebGUI)
– Some special cases are exceptions:
●
OpenVPN bound to localhost for Multi-WAN access
●
Port shifting for proxies

7.
Can you use Inbound NAT?
● Does pfSense have a public address on WAN?
– If not, upstream device must forward in port/all/etc
– If that is not possible, inbound traffic cannot be accepted (e.g. CGN)
● Does the ISP filter inbound traffic?
● Is the destination address on the firewall?
– If the destination is not on the firewall, a VIP will be needed unless
the destination is in a subnet routed to the firewall
● What type of VIP?
– For NAT only, if L2 is needed then any type than 'other' -- Generally: HA=CARP, IP alias
for most, or Proxy ARP for a large block
– For a routed block 'other' type VIPs.

8.
Can you use Inbound NAT? (2)
● Is the target local to the firewall?
– Local Target
● Target system must use pfSense as its default gateway
– Can use outbound NAT to mask the source to work around
● Target system must have a proper subnet mask
● Target system must be configured to accept the connections (local daemon
listening, local firewall allowing, etc)
– Remote Target
● On WAN: Outbound NAT to mask source so the traffic returns to firewall,
requires a rule with source=any, so it takes care/exceptions.
● On VPN: Depends
– OpenVPN can work with assigned interfaces and rules on specific tabs (they get reply-to
which returns traffic properly)
– IPsec can work if all traffic to/from target is set to go over IPsec (0.0.0.0/0 to target IP
address)

9.
Port Forwards or 1:1
● How many ports?
– One or a few, or a range, or an alias: Port forwards
– Many: 1:1 NAT is easier
● Which protocols?
– Some protocols do not have entries in “port” forwards and may require 1:1 NAT to forward
● Outbound needs
– If outbound NAT is needed for the same VIP as the inbound, or static port is also needed,
1:1 can be easier
● Security
– Minimal security edge goes to port forwards. With 1:1 NAT it's easier for an admin to
accidentally create an overly permissive rule allowing the public to reach unintended
services on the local target, but this is not a significant concern in most cases.
● Working around LAN Subnet Conflicts with OpenVPN
– Typically would use 1:1 NAT if bidirectional communication is required

10.
Port Forward Capabilities
● Can forward a single port or contiguous range of ports
– Define the port range start/end as the same port for one port
– Target range must be the same size, so only the starting port of the target is defined
● Can use aliases to forward a set of ports
– Same alias must be used in the destination and target areas
● Can only forward one port on destination to one target from the same source
– The same destination port cannot be forwarded to multiple targets unless there is a specific
distinction to set them apart, such as different sources
– If that is required, a reverse proxy or VPN may be required if the service supports it (e.g. for
HTTP/HTTPS, haproxy can direct using host header/SNI)
● Can shift ports (Destination port does not have to match target port)
– e.g. WAN IP:8080 to Target:80 so the target daemon binding need not be changed
● Can be used on internal interfaces to intercept and redirect traffic
– Capturing DNS requests, forwarding requests to a proxy, etc
● Automatic firewall rules are possible, linked or unlinked
– “pass” style can bypass firewall rules entirely, but since it cannot be filtered after, it's not as flexible

11.
Port Forward Example
● If necessary, define aliases first for ports, any needed VIPs, etc.
● Firewall > NAT, Port Forward tab
● Add to the top or bottom – Rules are processed from the top down
● Interface would typically be WAN (or a WAN)
● Protocol: Depends on needs, generally TCP or UDP or TCP/UDP
●
Source: Generally left alone unless making a source restriction.
– Never touch the source port field!
● Destination: WAN or pick the VIP from the list, or manually enter
● Destination Port Range: Set to “other” to manually enter or put in an alias, for single well-known ports, pick
from the list
– For a range, set the “From port” to the low port (e.g. 10000), “To port” to the high port (e.g. 20000)
● Redirect Target IP: The local IP address/server to which the connection will be forwarded
● Redirect Target Port: Port(s) where the target daemons are listening. Similar to the dest. Port, can be an
alias, start of range, etc.
● NAT Reflection: Covered later
●
Filter Rule Association: Majority of time you'll want to leave this on the default, which creates a linked
firewall rule
– When updating the port forward, the firewall rule updates as well.
●
Save, then double check firewall rules under Firewall > Rules on the same tab as the interface

12.
1:1 NAT Capabilities
● Can operate on a single address or a block of addresses on subnet
boundaries
● Forwards all ports and protocols sent to the destination on to an
internal target
● Handles outbound translation
– Traffic leaves using the external address of the 1:1
– Source ports are kept static
● Requires manual firewall rules to allow inbound traffic
● There is no advantage to defining port forwards+outbound NAT
separately
● Some SOHO gear incorrectly calls 1:1 NAT on the WAN IP address
a “DMZ”. This can be done on pfSense, but it is not recommended.

13.
1:1 NAT Example
● Define any necessary VIPs first
● Firewall > NAT, 1:1 tab
● Interface would typically be WAN (or a WAN)
● External subnet IP address: the VIP or address on WAN (or
routed block address) to which remote/public traffic is sent
● Internal IP: The local address(es) for the translation
● Destination: Typically left blank, can be used for a source
restriction (inbound) or a destination restriction (outbound). Leave
blank to apply 1:1 in all cases
● NAT Reflection: Covered later
● Save, then add firewall rules (if any inbound traffic is allowed!)

14.
NAT Reflection
●
Allows users on local networks to access resources using the external (destination) address
of a port forward or 1:1 NAT
– Ex: Port forward on WAN is not triggered by a request from LAN host, since the rule only triggers
inbound on WAN. Reflection adds internal rules to catch traffic on internal interfaces to perform the
same redirect
●
Undesirable as it requires bouncing off the firewall to access local resources that may not
even need to exit the subnet
– Consumes resources on the firewall for connections that don't involve the firewall
●
If client and server are in the same subnet, requires special handling to ensure proper traffic
flow
– If the client request bounces off the firewall with its source intact, the server will reply directly to the
client instead of back through the firewall. Since the server's actual address is not the address
contacted by the client, the client will drop the connection.
●
Split DNS is the preferred means to allow access to internal resources
– Internal clients resolve hostnames to internal IP addresses, external hosts see external addresses
●
System > Advanced, Firewall/NAT Tab

15.
NAT Reflection
● NAT Reflection for Port Forwards
– Pure NAT Mode
● Handled purely in pf – the preferred mode if it must be used
● No source masking by default, can have issues if client and server are in the same subnet
– NAT+Proxy Mode
● Connections proxied through a “bounce” daemon on the firewall
● Consumes more firewall resources per connection, involves xinetd and other overhead
● Reflection Timeout – For NAT+Proxy, timeout for daemon
● NAT Reflection for 1:1 NAT
– Adds pf rules to handle reflection for 1:1 NAT entries
● Automatic outbound NAT for Reflection
– Adds pf rules to mask the source of reflected connections so that traffic will always return to
the firewall
– Required for full functionality of Pure NAT mode and for 1:1 Reflection

16.
Outbound NAT
● Changes the source address of a packet as it exits an interface
– Commonly used to allow private networks on LAN to reach the Internet using one or
more routable IP addresses
● It does not direct traffic, it only controls the translation along the path it is
already taking
● Most common use is “overload” style with port translation, allowing many
internal hosts to use a single external address
● By default, source ports of outgoing connections are randomized
– Static Port setting can override this behavior
– Careful with the use of static port, if a specific post-NAT source IP address:port is in
use to a specific destination address:port, additional requests for that combination
including source port will fail. Typical example is multiple IP phones using a 5060
source all going to the same PBX. First will work, additional requests will fail.

17.
Outbound NAT Modes
● Automatic Outbound NAT
– Keys off interfaces with and without gateways set on interface settings.
GW=WAN, No GW=LAN
● Hybrid Outbound NAT
– Utilizes rules from auto mode, uses manually specified rules before auto rules
– Best method for customizing rules
● Manual Outbound NAT
– If rules list is empty, makes a set of rules for you
– No auto rules after, fully manually managed
● Disable Outbound NAT
– No outbound NAT will be performed, useful if all addresses on internal interfaces
are routed/public

18.
Outbound NAT Capabilities
● Source restrictions
– Typically LAN or the local network(s) to mask
– Do NOT use "any" since it would also NAT traffic from the firewall itself, which
will cause problems with gateway monitoring, VPNs, and other outbound traffic
from the firewall
● Destination
– Typically "any" meaning "The Internet" but can also be used for special cases
where specific NAT settings are not needed for all traffic (e.g. static port
outbound only going from PBX to SIP Trunk)
● Can use aliases of IP addresses or subnets for outbound NAT to help
with large numbers of local clients
– With sufficient connection load, it's possible to need more outbound connection
ports than can be supported with a single external address. Using a group can
be done with several modifiers:
● Round robin, Random, Source hash, Bitmask, Sticky. Only RR works with aliases, others
require a subnet.

19.
Outbound NAT Examples
● Before starting, add any required VIPs
●
Firewall > NAT, Outbound tab
●
For manually entered rules, you must be on Hybrid mode (recommended) or Manual
●
Add a rule, keep the top-down processing order in mind
– Put more specific rules on top, more general on bottom
●
Do Not NAT: Negates the meaning of the rule. If the source matches, NAT will be skipped
– Useful for making an exclusion so a local public subnet does not have NAT applied
● Interface: The interface the traffic is exiting, typically WAN
●
Protocol: Typically “any”, but can be more specific
– Example: UDP for PBX SIP/RTP traffic
●
Source: The network address(es) to mask (e.g. LAN)
●
Destination: Where the traffic is going. Typically “any”, as in “the Internet”
●
Translation: Defines what happens to the traffic source address/port as it leaves
– Address controls which Interface address, VIP, or manual entry is used to mask the source
– Port can set a specific port for the traffic, almost always left blank
– Static Port disables the randomization of outbound ports. See previous warnings about its use.

20.
Testing & Troubleshooting
● Reset states after making changes – If an existing connection is present, it
will not obey the new rules
– Especially important for UDP services such as SIP/RTP
● Check the state table, searching on the source and/or destination, to see
what is happening to the traffic
– No state entry = probably not passing the firewall
– State entry but going the wrong place = probably not matching the NAT rule
● Check rule restrictions and ensure the test traffic should and is actually
matching the rule
● Check packet captures to see if the traffic is arriving at the firewall, or if
replies are coming back from the local target
● See https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting for
more suggestions

21.
Conclusion
● Questions?
● Ideas for hangout topics? Post on forum,
comment on the blog posts, Reddit, etc