Admin Access Options in pfSense

In this follow-up to a previous article on webConfigurator options, I will look at the other Admin Access options you can configure by navigating to System -> Advanced and clicking on the Admin Access tab.

Admin Access Options: Secure Shell


SSH and serial port options in advanced settings in pfSense 2.0.

Under the “Secure Shell” heading, the first check box, “Enable Secure Shell”, enables you to login to the admin console via SSH. A terminal emulator such as xterm, Konsole, (or Putty under Windows) can be used to login. The next check box, “Disable password login for Secure Shell (RSA/DSA key only)” allows you to login with a public/private key pair instead of a password. Describing in depth how to do this is beyond the scope of this article (I have provided more detailed instructions in my article on SSH server configuration), but there are three basic steps. First, you need to generate a public/private key pair using a utility such as ssh-keygen or PuTTYGen. Second, you need to check the “Disable password login for Secure Shell” check box and save the settings. Third, you need to navigate to System -> User Manager, edit the settings for the admin account, and paste the newly-generated public key into the text box that appears when the “Click to paste an authorized key” check box is checked and save the settings. Finally, “SSH Port” enables you to change the SSH port (leave it blank for the default of 22). Changing the SSH port is often a good idea, as it makes it less likely that the admin account will be hacked via SSH.

Admin Access Options: Serial Port Access

Under the Serial Terminal heading, check the “Serial Terminal” check box to enable console access via the first serial port with settings of 9600 baud/8 bits/no parity/1 stop bit. This will redirect the console output and messages to the serial port, but you can still access the console menu from the internal video card and keyboard. A null modem serial cable or adapter is required to use the serial cable. Finally, under the Console Options heading, checking the “Password protect the console menu” will cause the console to prompt the user for a password (changes to this option will take place after a reboot) before performing admin functions.

External Links:

How to Enable SSH Access at

Secure Shell at Wikipedia

webConfigurator Options in pfSense

Today, I thought it might be interesting to look at some of the advanced pfSense settings. I will start this series by looking at the webConfigurator settings, which you can find by navigating to System -> Advanced, and clicking on the “Admin Access” tab.

webConfigurator Options


webConfigurator settings in pfSense 2.0

The first setting is “Protocol“. The default is HTTP, but you can choose HTTP Secure, which runs HTTP on top of the SSL/TLS protocol, enabling secure communications. Next is “TCP port“; here you can enter a custom port number for the web interface (80 for HTTP, 443 for HTTPS). This provides an extra layer of security, as you can use “security through obscurity” to hide the pfSense webConfigurator from others (this is especially valuable if, for whatever reason, you have to be able to access the webConfigurator from the WAN interface).

The next setting is “Max Processes“, in which you can alter the number of webConfigurator processes that are allowed to run simultaneously. Increasing the number of instances allows more users/browsers to access the GUI concurrently. Next is the “Disable webConfigurator redirect rule“. When this check box is unchecked, access to the pfSense web interface is always permitted from the WAN, even on port 80, regardless of the listening port is configured. Checking this box disables this access. If it is checked, access to the webConfigurator can be allowed, but only via an explicit rule and via NAT port forwarding.

The next setting is “Disable web configurator login autocomplete” When this in unchecked (the default), login credentials for the webConfigurator maybe saved by the browser. Checking this check box disables autocomplete on the login form so that browsers will not prompt to save credentials, but not all browsers respect this option.

Next is “Disable logging of webConfigurator successful logins“; when this is checked, successful logins to the webConfigurator will not be logged. When unchecked, “Disable webConfigurator anti-lockout rule” will allow access to the pfSense web interface regardless of what firewall rules are set. If this box is checked, then access from the LAN will still be possible if the web interface is set to port 80 and the default “Anti-Lockout Rule” is still in place (or if a rule is created to allow traffic on whatever port you choose). Make sure such a rule is in place before you check this box, or you could lock yourself out.

Disable DNS Rebinding Checks” when unchecked blocks private IP responses from your configured DNS servers. Sometimes, however, it may interfere with webConfigurator access or name resolution; if so, you can check this box so that such private IP responses will not be blocked. Below this, at “Alternate Hostnames for DNS Rebinding and HTTP_REFERER Checks“, you can specify alternate hostnames by which the router may be queried to bypass the DNS rebinding attack checks (hostnames should be separated by spaces). Finally, when unchecked, “Disable HTTP_REFERER enforcement check” will disable access to the webConfigurator from scripts that try to redirect traffic based on the HTTP_REFERER field. Checking this box disables this protection, which may help if you use external scripts to interact with the system.

External Links:

HTTP_referer at Wikipedia

Video: PPPoE Server Configuration

Someone requested a video on PPPoE server configuration, so I made one yesterday and posted it to YouTube:

Traceroute Utility in pfSense

Traceroute Explained


The traceroute command in action under Windows.

In computer networking, traceroute is a computer network diagnostic tool for displaying the route and measuring transit delays of packets across an Internet Protocol network. The history of the route is recorded as the round-trip times of the packets received from each successive host in the route; the sum of the mean times in each hop indicates the total time spent to establish the connection. Ping, on the other hand, only computes the final round trip time to the destination, not the intermediate times. It is defined in RFC 1393.

Traceroute sends a sequence of three ICMP echo request packets addressed to a destination host. The time-to-live (TTL) value, also known as hop limit, is used in determining the intermediate routers being traversed towards the destination. Routers decrement packets’ TTL value by one and discard packets whose TTL value has reached zero. When a packet is discarded because its TTL value reached zero, the router sends an ICMP Time Exceeded message back to the source. Traceroute, on the other hand, sends packets with gradually increasing TTL value, starting with a value of 1. The first router receive the packet, decrements the TTL value and drops the packet. The router sends an ICMP Time Exceeded message back to the source. When the source receives this ICMP message, it sends out a new set of packets with a TTL value of 2. This way, traceroute is able to build a list of routers that the packets traverse, until the destination is reached and returns and ICMP Echo Reply message. The timestamp values returned for each router along the path are the latency values, typically measured in milliseconds.

While traceroute under Windows (invoked with the tracert command) uses ICMP and the original specification called for using ICMP, the command did not initially work well because of the interpretation of RFC 791 (the Internet Protocol RFC) by routing equipment vendors. Thus to fix this, Van Jacobson wrote a variant to traceroute that worked so well and reliably, it was ported to many systems and used as the default. The Van Jacobson version used outbound UDP datagrams from the host running traceroute instead of ICMP. This was the default on any system using the Van Jacobson version of the command, including most BSD and UNIX-type systems. Systems using the Van Jacobsen version also use destination port numbers ranging from 33434 to 33534. The utility under Unix usually has an option to instead use ICMP echo request. If a network has a firewall and operates both Windows and Unix systems, both protocols must be enabled inbound through the firewall for traceroute to work and receive replies. Some traceroute utilities use TCP packets (e.g. tcptraceroute or layer four traceroute).

Using Traceroute in pfSense


Using traceroute in the pfSense web interface.

To use traceroute from the pfSense web interface, first browse to Diagnostics -> Traceroute. At “Host”, set the host to the IP address or hostname of the machine you are trying to trace. At “Maximum number of hops”, set a maximum number of hops for the trace to traverse. At “Use ICMP”, you can check this check box (if not, traceroute will use UDP). Then press the “Traceroute” button to perform the function. The output of the traceroute function will appear below the button.

Note that traceroute can sometimes take a long time to complete. You can click the browser’s stop button at any time to cancel the traceroute and display the results. It should be noted that multi-WAN is not supported by this utility.

External Links:

Traceroute at Wikipedia

How Traceroute Works at

Why traceroute sends UDP packets and not ICMP ones? from Stack Overflow

Traceroute at

FTP Server Configuration with pfSense

FTP Server Issues

FTP serverFile Transfer Protocol (FTP) is a standard network protocol used to transfer files from one host to another host over a TCP-based network. The original specification for File Transfer Protocol was published as RFC 114 in 1971, and thus predates even TCP/IP. Thus it is a mature protocol, but since it predates the time when security was a paramount concern, it is problematic for several reasons:

  • Passwords are transferred in the clear.
  • The protocol demands the use of at least two TCP connections (control and data) on separate ports.
  • When a session is established, data is communicated via ports selected at random.

These points create security challenges that can potentially led to issues. The best option a security professional could choose is to abandon FTP entirely, and utlilize one of several alternate methods of file transfer:

  • Explicit FTPS is an extension to the FTP standard that allows clients to request that the FTP session be encrypted. This is done by sending the “AUTH TLS” command. The server has the option of allowing or denying connections that do not request TLS, and is specified to use different ports than plain FTP.
  • SFTP, the “SSH File Transfer Protocol”, uses Secure Shell (SSH) to transfer files. Unlike standard FTP, it encrypts both commands and data preventing passwords and sensitive information from being transmitted openly over the network.
  • FTP over SSH refers to the practice of tunneling a normal FTP session over an SSH connection. Because FTP uses multiple TCP connections, it is difficult to tunnel over SSH. Nevertheless, there are several software packages that are able to rewrite FTP control channel messages and automatically open new packet forwardings for FTP data channels.
  • SFTP and SCP, in which the entire conversation is protected by the SSH protocol.


Regardless, in some situations you may have to deal with setting up an FTP server. The best solution in this case is to redirect FTP traffic to a proxy that was written for this purpose. The proxy will then interact with pfSense. The program, which originated in OpenBSD, is called ftp-proxy. In pfSense 2.0 and later, the FTP proxy is in-kernel. To confirm that the FTP proxy is running, navigate to System -> Advanced, and click on the “System Tunables” tab. The first variable on the list, “debug.pfftpproxy” will be set to 0 if the FTP proxy is enabled (set it to 1 to disable the proxy). Also note that the FTP proxy will only work on the primary WAN at this time. It will not fail over and it will not load balance.

There are a few other configuration tips that should be mentioned, especially if you utilize FTP-proxy:

  • If you have a restrictive rule set or are utilizing policy-based routing for multiple WANS, make sure you have permitted traffic to / ports 8000-8030 (the default port for ftp-proxy is 8021). This rule should be on top of all other LAN rules that utilize policy-based routing.
  • If you are running Windows to access the FTP server, try turning off Windows Firewall if it is running.
  • If Snort is running, try disabling Snort, and if you are able to access the server when it is disabled, try upgrading to a more recent version of Snort.
  • Delete any existing FTP ort forwards or firewall rules and add new port forwarding and firewall rules for the destination port 21 and the destination private NAT IP address. For more information on port forwarding with NAT, see my earlier posting on NAT/port forwarding.

If these tips do not help, you probably should consider using one of the alternatives to FTP listed above. However, this may not always be an option in a corporate environment or if a client wants an FTP server. If so, the use of ftp-proxy under pfSense when setting up an FTP server should provide at least a modicum of security.

External Links:

File Transfer Protocol at Wikipedia

Howto Setup FTP Server Behind pfSense at

Ethernet Fundamentals

EthernetEthernet was developed at Xerox PARC between 1973 and 1974, and was developed as a network technology based on a bus topology. It was originally based on the idea of computers communicating over a shared coaxial cable, and the original specification enabled them to transfer data at a rate of up to 3 Mbps. It remained a largely in-house technology within Xerox until 1979, when Xerox decided to look for partners to help promote Ethernet as an industry standard. They worked with Digital Equipment Corporation (DEC) and Intel to publish what became known as the Digital-Intel-Xerox (DIX) standard. These companies then transferred control of the Ethernet standard to the IEEE, which in turn created the now famous 802.3 committee that continues to control the Ethernet standard. The 802.3 standard initially specified communications over coaxial cable at speeds up to 10 Mbps. Since then, Ethernet has evolved from a single network technology into a standard for a family of network technologies that share the same basic bus topology, frame type, and network access methods.

Ethernet Fundamentals: CSMA/CD and MAC Addresses

Developing a networking standard at the physical level and beyond requires designing a way to send data, a way to determine which computer should use the shared cable at what time, and identify the sending and receiving computers. Ethernet deals with the first two issues by using a process called Carrier Sense Multiple Access with Collision Detection (CSMA/CD), and deals with the third issue by using data frames that contain Media Access Control (MAC) addresses to identify computers on the network. Carrier sense means that each node using the network examines the cable before sending a data frame. If another machine is using the network, then the node will detect traffic on the segment, wait a few milliseconds, and then recheck. If it detects no traffic, the node will send out a frame of data.

Multiple access means that all machines have equal access to the cable. If the line is free, any Ethernet node may begin sending a frame. It does not matter what function the node is performing. Ethernet assigns access on a first-come, first-serve basis, leaving it to other networking technologies (such as pfSense) to discriminate based on what type of traffic it is.

If two computers try to use the cable simultaneously, then a collision occurs, and both of the transmissions are lost. At the same time the network interface is sending a frame, it compares the data being sent with the data received over the cable. If there is a difference, both nodes will detect a collision and immediately stop transmitting. Then each node generates a random number to determine how long it waits to begin trying again. Whichever node generates the lowest number begins retransmission first. The losing node sees traffic on the wire and waits for the wire to be free again before attempting to retransmit.

As you can imagine, any Ethernet node will waste some time dealing with collisions instead of sending data. Moreover, as more nodes are added to the network, the collisions increase. We call a collision domain a group of nodes that hear each other’s traffic. Ethernet standards dictate that within a collision domain, there should be at most 5 segments tied together with 4 repeaters, and no more than 3 populated segments.

Ethernet requires a means of identifying sending and receiving nodes, and its method is to use special 48-bit binary addresses known as MAC addresses. MAC addresses give each network interface card (NIC) a unique address. When a computer sends out a data frame, all other NICs on the collision domain listen to the wire and examine the frame to see if it contains their MAC address. If not, they ignore the frame. If a NIC sees a frame with its MAC address, it accepts the frame and begins processing the data.

One issue with this method is that any device connected to the network cable can potentially capture any data frame transmitted across the wire. Network diagnostic programs can order a NIC to run in promiscuous mode, in which case the NIC will process all frames it sees on the cable regardless of their MAC addresses. Such programs are useful diagnostic tools but also pose a security risk, as anyone with access to the network can potentially intercept every frame on the collision domain.

External Links:

Ethernet at Wikipedia

5-4-3 Rule at Wikipedia

Ping Utility in pfSense

The Ping Utility Explained


Using the Ping utility in pfSense.

Ping is a computer network administration utility used to test the reachability of a host on an IP network and to measure the round-trip time for messages sent from the originating host to a destination host. It operates by sending Internet Control Message Protocol (ICMP) echo request packets to the target host and waiting for an ICMP response. In the process it measures the time from transmission to reception and records any packet loss.

RFC 1122, which defines communication layer requirements for Internet hosts, says the following about Echo Requests and Replies:

Every host MUST implement an ICMP Echo server function that receives Echo Requests and sends corresponding Echo Replies. A host SHOULD also implement an application-layer interface for sending an Echo Request and receiving an Echo Reply, for diagnostic purposes.

An ICMP Echo Request destined to an IP broadcast or IP multicast address MAY be silently discarded.


This neutral provision results from a passionate debate between those who feel that ICMP Echo to a broadcast address provides a valuable diagnostic capability and those who feel that misuse of this feature can too easily create packet storms.

The echo request (“ping”) is an ICMP message whose data is to be received back in an echo reply (“pong”). The host must respond to all echo requests with an echo reply containing the exact data received in the request message. The echo reply is an ICMP message generated in response to an echo request, and is mandatory for all hosts and routers.

Using the Ping Utility in pfSense

To use the pfSense ping utility, first navigate to Diagnostics -> Ping. Then at “Host”, set the host to the IP address or hostname of the host we are trying to ping. At “Interface”, choose the interface from which to initiate the ping (WAN for remote hosts, LAN for local hosts). At “Count”, use the dropdown set the number of ping requests (anywhere from 1 to 10; the default of 3 is usually sufficient). Then press the “Ping” button to invoke the utility. Sending out ICMP echo requests is often a useful diagnostic tool; however, multi-WAN is not supported with this utility.

External Links:

Ping at Wikipedia

RFC 1122 (which mandates that Internet hosts reply to ICMP echo requests)

Packet Capture in pfSense

Packet Capture Explained

Packet Capture

Enabling packet capture from the pfSense web interface.

Packet capture is useful if you need to intercept and log traffic passing over a network. As data streams flow across the network, the sniffer captures each packet and if needed, decodes the packet’s raw data showing the values of various fields in the packet, and analyzes its content.

Ethernet sniffers can take advantage of the way Ethernet frames are transmitted. When a node sends out an Ethernet data frame, it transmits it to every other node across the write in both directions. All the other computers on the network listen to the wire and examine the frame to see if it contains their MAC address. If not, they ignore the frame. If a node sees a frame with its MAC address, it opens the frame and begins processing the data. This is a simple means of sending frames (much simpler, for example, than the way a token ring network operates), but it also means Ethernet sniffers can order an NIC to run in promiscuous mode and process all the frames it sees on the cable, regardless of their MAC address. The ability to capture all packets on the local network segment would change with the advent of switched ports, but a router can still function as a packet analyzer.

Packet Capture from the pfSense Web Interface

The easiest way to capture packets in pfSense is to use the built-in packet capture feature. First, navigate to Diagnostics -> Packet Capture. At “Interface“, select either the LAN or WAN interface. If you are trying to track down IP addresses in your local network, you should specify LAN; if you are trying to track down traffic originating outside you network, select WAN. At “Address Family“, you can leave it set to “Any”, but you can also filter the traffic to capture only IPv4 or IPv6 addresses. You can leave “Host Address” blank, but if you are looking for traffic from a specific address or subnet (in CIDR notation), you can specify it here. You can also specify a “Port” if you want to filter by port, or leave it blank. At “Packet Length“, you can set a maximum number of bytes of each packet that will be captured, or leave it at zero, which will cause it to capture the entire frame. At “Count“, you can set a maximum number of packets the packet capture will grab. The default value is 100, and you can enter zero for no count limit. At “Level of Detail“, you can set how much detail is displayed in the capture window after you press the “Stop” button at the bottom of the screen. If you download the capture file, however, this setting will not affect the contents of it. You can check the “Reverse DNS Loookup” check box to cause the packet capture to perform a reverse DNS lookup associated with an IP address. It can cause delay, however, for large packet captures.

Packet Capture

Wireshark in action under Windows.

Once you have run a capture using the pfSense web interface you can use Wireshark, a free and open-source packet analyzer, for packet analysis by downloading the pcap file and loading it into the program (You can do this by navigating to File -> Open in Wireshark and loading the appropriate file). A complete overview of Wireshark and its functionality is beyond the scope of this article, but you can find the packets you are looking for by applying different filters to locate the packets for which you are looking. For example, we can limit the results to a specific IP address by navigating to Analyze -> Display Filters and clicking on the “IP address” display filter, then specifying the desired IP address.

Using tcpdump

Another possibility for packet capture analysis is to run the “tcpdump” command at the pfSense command land. Again, a complete overview of the tcpdump command is beyond the scope of this article, but suffice it to say -i denotes the interface whose packets should be captured and -w indicates that the output should be written to a file. For example:

tcpdump -i fxp1 -w output.pcap

indicates that tcpdump should capture all packets on interface fxp1 (our LAN interface) and save them to output.pcap. Omitting “-w output.pcap” would result in the output going to the screen. Specifying “host” would limit results to traffic to and from To analyze the logs produced by tcpdump, you could use Wireshark or a program such as tcptrace.

External Links:

Packet Analyzer at Wikipedia

How to Capture Packets Using pfSense at HubPages

ARP Configuration in pfSense

Address Resolution Protocol (ARP)

Address Resolution Protocol (ARP) is a protocol used for resolution of network layer addresses into link layer addresses. It was defined by RFC 826 in November 1982. ARP is used to convert an IP address to a physical address (the RFC specifies a 48-bit Ethernet address, called the MAC address). The RFC also specifies 10 Mb Ethernet, but ARP applies to all variants of Ethernet, regardless of speed.

To demonstrate how ARP works, let’s assume that we have two systems on our local network: NODE1 ( and NODE2 ( NODE1 wants to send data to NODE2. It knows the IP address, but it does not know the MAC address, and without the MAC address, it cannot make a frame. So NODE1 sends out a broadcast frame to the broadcast address, which is FF:FF:FF:FF:FF:FF. All systems on the network receive and process frames sent to the broadcast address. This frame asks all systems on the local network what the MAC address for IP address is. This frame is called an ARP request. The system with the IP address replies to NODE1 with an ARP reply.

Once NODE1 gets the MAC information for NODE2, it stores this information in a cache. You can see the ARP cache in your Windows or Linux system by typing arp -a (in Unixoid environments, you may have to specify the path; e.g. /sbin/arp -a). In some situations, a computer knows the MAC address, but needs the system’s IP address; in those cases, it can broadcast a Reverse ARP (RARP) command. While ARP is fairly common, few applications require RARP.

ARP is an essential networking component, but it will not work if the target computer is not part of the local network. If NODE1 wanted to send data to a remote computer, it cannot ARP that system, because the Internet does not allow any form of broadcast frames. In this case, NODE1 creates frames with the remote system’s IP addres and runs an ARP to determine the MAC address of the remote system. The sending system’s network interface card (NIC) then creates frames with the gateway’s MAC address. As each frame comes into the gateway, it strips off the frame, leaving the IP packets, which still have the IP address of the remote system as its destination. The gateway then wraps the IP packets in whatever type of frame the outgoing connection needs and sends them toward the intended system.

Viewing the ARP Table and Other Configuration Tips


Viewing the ARP table in pfSense.

To view the pfSense ARP table, navigate to Diagnostics -> ARP Table. The table will contain some, but not necessarily all, of the systems in pfSense’s local network. Only systems that have been the target of an ARP query show up in the table.

Because ARP does not provide methods for authenticating ARP replies on a network, ARP replies can come from systems other than the one with the required Layer 2 address. An ARP proxy is a system which answers the ARP request on behalf of another system for which it will forward traffic, normally part of the network’s design. Proxy ARP configuration in pfSense has already been detailed in a previous article.

There is one last setting that should be noted. In some cases, you may have two NICs on the same physical network, but on different subnets. Everything works, but you get a lot of messages like this in the system log:

kernel: arp: is on fxp2 but got reply from 00:30:ab:0e:de:a2 on fxp0

You can ignore these error messages, but because of the sheer amount of them, they may hide some of the more important error messages. Fortunately, pfSense has provided an easy way of getting rid of them. Navigate to System -> Advanced, and click on the “Networking” tab. Under “Network Interfaces“, check the “Suppress ARP messages” check box. Now ARP log messages will be suppressed between multiple interfaces on the same broadcast domain, even if they are on separate subnets.

External Links:

Address Resolution Protocol at Wikipedia

Ethernet Address Resolution Protocol at

Switch management on two interfaces at

IGMP Proxy Configuration in pfSense

Internet Group Management Protocol Explained

The Internet Group Management Protocol (IGMP) is a communications protocol used by hosts and adjacent routers on IP networks to establish multicast group memberships. IGMP operates between the client computer and a local multicast router. Like other network management protocols, it operates above the network layer. There are three versions of IGMP: version 1, defined by RFC 1112, version 2, defined by RFC 2236, and version 3 was initially defined by RFC 3376 and has been updated by RFC 4604. A router can serve as  an IGMP proxy, as we shall soon see.

The IPv4 address scheme assigns Class D addresses for IP multicasting. IGMP is the protocol that uses these addresses. The following addresses have specific functions or are unavailable:

  • is reserved, and you cannot assign it to a group.
  • is the all-hosts address – a pack sent to this address reaches all hosts on a subnet.
  • is the all-routers address – a packet sent to this address reaches all routers on a subnet.

This implementation of IGMP complies with IGMPv2, which involves the exchange of the following types of messages between routers and hosts:

  • Group membership queries
  • Group membership reports
  • Leave group membership messages

A multicast router can be a querier or a nonquerier. There is only one querier on a network at any time. Multicast routers monitor queries from other multicast routers to determine the status of the querier. If the querier hears a query from a router with a lower IP address, it relinquishes its role to that router.

Multicast routers send two types of group membership queries to hosts on the network: [1] general queries to the all-hosts group address, and [2] specific queries to the appropriate multicast group address. The purpose of a membership group query is to discover the multicast groups to which a host belongs. When a host receives such a query, it identifies the groups associated with the query and determines to which groups it belongs. Since the query has a Max Response Time field (the maximum time a host can take to respond to a query), the host sets a timer less than this field, and when the timer expires, the host muliticasts a group membership report to the group address. When a multicast router receives a report, it adds the group to the membership list for the network and sets a timer to the Group Membership Interval. If this timer expires before the router receives another group membership report, the router determines that the group has no members left on the network. If the router does not receive any reports for a specific multicast group within the Max Response Time, it assumes that the group has no members on the network. The router does not forward subsequent multicasts for that group to the network.

New to IGMP version 2 are the leave group membership messages. When a host leaves a group, it sends such a message to multicast routers on the network. A host generally addresses leave group membership messages to the all-routers group address,

The IGMP protocol is implemented on a particular host and within a router. A host requests membership to a group through its local router while a router listens for these requests and periodically sends out subscription queries.

IGMP Proxy Configuration

IGMP Proxy

IGMP proxy configuration in pfSense. Here, we configure the upstream interface.

IGMP proxy configuration is relatively simple. You enable IGMP proxy on one interface, which connects to a router closer to the root of the tree. This interface is the upstream interface. The router on the upstream interface should be running IGMP. You also enable IGMP on the interfaces that connect the system to its hosts that are farther away from the root of the tree. These interfaces are known as downstream interfaces. When you configure IGMP proxy, the system interacts with the router on its upstream interface through the exchange of IGMP messages. However, when acting as the proxy, the system performs the host portion of the IGMP task on the upstream interface as follows:

  • When queried, sends group membership reports to the group.
  • When one of its hosts joins a multicast address group to which none of its other hosts belong, sends unsolicited group membership reports to that group.
  • When the last of its hosts in a particular multicast group leaves the group, sends an unsolicited leave group membership report to the all-routers group.
IGMP Proxy

IGMP Proxy page showing the upstream and downstream interfaces.

To configure IGMP Proxy in pfSense, first navigate to Services -> IGMP Proxy. Click on the “plus” button to add a new interface. To configure the upstream interface, select “WAN” in the “Interface” dropdown box. Then at “Description“, add an appropriate description. For “Type“, select “Upstream Interface”. At “Threshold“, you can set a time to live (TTL) threshold (the default is 1). At “Network(s)“, press the “plus” button and add one or more networks (along with the number of bits in the network name at the “CIDR” dropdown box). This defines which subnets are allowed to communicate via the IGMP proxy. I set it to “” for the network and “0” for the CIDR to allow all outside hosts to send IGMP messages, but you can change this setting if necessary. Then press “Save” to save the new interface, and “Apply changes” on the next page.

Now you need to configure the downstream interface. Click the “plus” button again. At “Interface“, choose the interface on which the hosts will belong to a multicast group (probably LAN). At “Description, type an appropriate description, and at “Type“, select “Downstream Interface” from the dropdown box. At threshold, define a TTL threshold if necessary. At “Network“, click on the “plus” button and specify at least one network name and CIDR. Then press “Save” to save the changes and “Apply changes” to apply the changes.

You also need a firewall rule on the downstream side (typically LAN) that matches/passes this traffic which has the advanced option checked to allow packets with IP Options.  To do this, navigate to Firewall -> Rules, and click on the appropriate tab (probably LAN).  Click on “plus” to add a new rule. Leave settings for “Interface“, “TCP/IP Version“, “Protocol“, “Source” and “Destination” unchanged. At “Description“, enter a description. Scroll down to “Advanced features“, and at “Advanced Options“, click on the “Advanced” button, and check on the first check box to allow packets with IP options to pass.  Then scroll down, press the “Save” button to save this rule and on the next page press “Apply changes” to apply the changes.

External Links:

Internet Group Management Protocol at Wikipedia

IGMP Proxy at

IGMP Proxy at

© 2013 David Zientara. All rights reserved. Privacy Policy