The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My badges

    Mastodon

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now20140424-VMware-Fusion-6.0.3.-no-reclaimable
    More Photos

  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,862 other subscribers
«
»

A few pfSense quirks I got used to over the years

Posted by jpluimers on 2026/01/06

Everytime when installing a pfSense router from scratch, I seem to re-learn a few of the below quirks. So it was finally time to document them (:

Quite a few of my pfSense configurations are just doing routing between various networks, should not provide DHCP leases and do not always need or have a WAN connected (i.e. they are LAN-only).

pfSense maps physical network interfaces to logical network interfaces

Unlike some other routers, pfSense internally uses logical network interfaces to which you can assign physical and virtual network interfaces.

This is confusing at first, especially since:

  1. the mandatory order of adding them is WAN, LAN, OPT1, OPT2, …
  2. after adding them, you cannot change the order (but you can reassign existing ones)

But it is powerful especially as you can rename them which means now suddenly dull interface numbers have gotten a meaningful name.

The WAN interface by default does not respond to ICMP ping

Yes I know about ping flood, but being able to ping is often essential in tracking down configuration hick-ups or spotting down hardware failures.

Allowing ping requires you to add a firewall rule, see [Wayback/Archive] Firewall — Configuring firewall rules: ICMP type | pfSense Documentation

When ICMP is selected as the protocol, this drop-down contains all possible ICMP types to match. When passing ICMP, the best practice is to only pass the required types when feasible. The most common use case is to pass only a type of Echo Request which will allow an ICMP ping to pass.
Tip
Historically, ICMP has a bad reputation but it is generally beneficial and does not deserve the reputation on modern networks. Allowing an ICMP type of any is typically acceptable when allowing ICMP.

and [Wayback/Archive] PfSense doesn’t respond to ping from WAN : PFSENSE

For me, the solution was simply creating a firewall rule for the WAN with ICMP as the protocol. Under ICMP types, select ALL. Using echo reply as suggested by the elitist will not work for most people that are simply using a mostly out-of-the-box pfsense. Add a description so you know what the rule is for and save it. Once applied you should be able to ping the WAN IP from outside the network/VPN.

[Wayback/Archive] Imgur: The magic of the Internet: Interface WAN, allow IPv4 ICMP any subtype from any source to the WAN address

Running pfSense LAN-only with just the one interface means WAN

Yes, this is possible!

Since pfSense assigns physical network interfaces to logical network interfaces in the mandatory order WAN, LAN, OPT1, OPT2, … it effectively means the WAN interface now acts as LAN.

This setup lets you access the pfSense web configuration UI from the WAN interface, but there is one big gotcha:

If you add another interface (for instance because you are playing around to get WireGuard up and running), then suddenly you are being kicked out of the WAN interface.

It usually takes a few seconds (sometimes more than 10) before you get kicked out, but you will be kicked out.

The reason for this gotcha consists of three parts:

  1. the next assigned interface after WAN is LAN
  2. now that pfSense has both a WAN and a LAN interface, it suddenly thinks WAN is the evil outside and LAN the friendly inside
  3. from a security point of view, pfSense tries to prevent you from accessing the web configuration from the evil WAN side

It means you have to set-up the LAN interface correctly right the first time, otherwise pfSense will lock you out.

Which brings me to another quirk:

The default LAN interface has a static IPv4 and a DHCP-server

You can read more on this at [Wayback/Archive] Configuration | pfSense Documentation. It effectively means that you have to either:

  • Set the LAN IPv4 Configuration Type to DHCP
  • Stop the DHCP Server on the LAN interface (from a separate browser tab, although you might need to first save the interface giving a slight risk of flooding invalid DHCP results)

For virtualised pfSense routers, I usually configure LAN on a temporary virtual switch so no harm can be done by running the LAN DHCP server for a short while.

A DHCP Client Configuration of Hostname causes a Client ID to be sent

Most people handing out “static” DHCP leases do this based on MAC address, but there is also a different way to hand out leases: by using DHCP option 61.

This is what the Hostname field under the DHCP Client Configuration is used for. I really wish there were more results from [Wayback/Archive] “DHCP Client Configuration” site:netgate.com – Google Search as it won’t find the actual documentation page you are after, [Wayback/Archive] Interface Types and Configuration — IPv4 Configuration Types: DHCP | pfSense Documentation

Hostname:

Some ISPs require the Hostname for client identification. The value in the Hostname field is sent as the DHCP client identifier and hostname when requesting a DHCP lease.

The does not even tell the actual underlying protocol, but that is at [Wayback/Archive] RFC 2132: DHCP Options and BOOTP Vendor Extensions: – section 9.14. Client Identifier and other links on option 61 further below.

I wrote about DHCP option 43 before in APC 7xxx models, DHCP Option 43 and Mikrotik DHCP servers, and option 61 work in a similar way but more visible in Mikrotik routers.

Option 61 just gives some at first oddly looking hexadecimal client ID digits which you can decode with CyberChef:

These were exactly the two hostnames I configured for the WAN and LAN interface (:

Running with a disconnected WAN

If you do the below, then ensure that if you have a default gateway, then be sure to route it from one of the other interfaces.

[Wayback/Archive] Internal Only Router (No WAN) | Netgate Forum

Q

Being accustomed to Cisco & MikroTik routers, I’m used to only having an interface become a “WAN” interface after all of the necessary firewall and routes are setup manually.  As far as I can tell, pfSense forces you to designate one of the interfaces as WAN.  Is there any way to setup an internal only router that would just route between two or more subnets without a WAN connection?  I’ve accomplished this by pretending WAN is one of the LANs and ripping out a bunch of firewall rules and others, but I’m wondering if there’s a cleaner way.

A

Why not just assign a WAN interface and then attach nothing to it? Are you running into restrictions because of the number of interfaces you have? I have a few situations similar to what you describe and I simply assign a WAN to DHCP and then just connect nothing to the assigned WAN interface.

Odd internet address family error message

I ran into an error message like this when adding a route via a gateway over an interface where all of the IP addresses are in fact IPv4 (and of the same family)

The gateway “172.16.x.y” is a different Address Family than network “192.168.y.0”.

The gateway “172.16.x.y” was on the destination side of a tunnel that on the local interface had IPv4 “172.16.x.z”. The gateway could in fact access the destination network “192.168.y.0”.

All of them IPv4, no IPv6 involved so no address family identifier mismatch according to [Wayback/Archive] Routing — Gateways: Gateway Address Families (IPv4 and IPv6) | pfSense Documentation:

Gateway Address Families (IPv4 and IPv6)

When working with routing and gateways the functionality and procedures are the same for both IPv4 and IPv6 addresses. However, all of the addresses for a given route must involve addresses of the same family. For example, an IPv6 network must be routed through an IPv6 gateway. A route cannot be created for an IPv6 network using an IPv4 gateway address. When working with gateway groups the same restriction applies: All gateways in a gateway group must be of the same address family.

The problem was this supposedly fixed bug, but apparently still present in pfSense 2.6.0 [Wayback/Archive] Bug #8846: Misleading gateway error message adding/editing static routes using a disabled interface – pfSense – pfSense bugtracker

I was adding static route on disabled interface and got the following message:

The following input errors were detected:
The gateway "10.66.0.99" is a different Address Family than network "10.66.10.0".

As you can see from the message itself, network and gateway are in the same family. I’ve tracked that down to the skipping of disabled interfaces in return_gateways_array function.
Possible solutions:

  • change error message to something like: “The gateway “10.66.0.99” is a different Address Family than network “10.66.10.0” or interface disabled”
  • remove skipping of disabled interfaces
  • automatically disable gateways on disabled interfaces

…

fixed
the GW will be disabled if the interface was disabled.
if there was a static route the GW will disappear if the interface is disabled.
22.05-RELEASE (amd64)
built on Wed Jun 22 18:56:13 UTC 2022
FreeBSD 12.3-STABLE

So I wrote this [Wayback/Archive] Thread by @jpluimers on Thread Reader App asking of there was any 2.7.x release horizon:

[Wayback/Archive] Jeroen Wiert Pluimers @wiert@mastodon.social on Twitter: “Nice @pfsense here with 2.6.0: The gateway “172.16.21.22” is a different Address Family than network “192.168.22.0”. The network is a @WireGuardVPN tunnel. Everything is IPv4 address family, including the underlying interface. I pulled my hairs until I found out: 1/”

Given that 2.6.0-RELEASE (amd64) built on Mon Jan 31 19:57:53 UTC 2022 FreeBSD 12.3-STABLE is almost a year old now, is there any rough indication when a 2.7.x might be released that fixes this?

Back to accessing the web interface from WAN: yes you can, no you shouldn’t

This answers why you shouldn’t: [Wayback/Archive] firewall – How to disable PfSense webConfiguration on WAN – Stack Overflow (thanks [Wayback/Archive] Bhaskar and [Wayback/Archive] Gui)

A

Note that once you install Pfsense it adds a “Default allow LAN” to LAN interface but there is no such rule on WAN interface. It means you can access everything from LAN, that is, you can access WAN (and so the internet) but the access from WAN is blocked. Fortunately there is no way to access GUI from WAN by default. This configuration is pretty the same the default config you find in a home/conventional router. I advise you to try Pfsense for a while before installing packages.

But if you insist, read [Wayback/Archive] Accsess pfsense WebGUI over WAN – Networking & Firewalls – Lawrence Systems Forums.

Documentation references

Roughly in order of appearance:

Cool book chapter giving an impression of [Wayback/Archive] pfSense configuration | Mastering pfSense – Second Edition.

DHCP option 61: client id/client identification

  • [Wayback/Archive] dhcp client id – Google Search
  • [Wayback/Archive] Configuring a DHCP client ID for an interface
    A DHCP client ID is added to the DHCP option 61 to uniquely identify a DHCP client. A DHCP server can assign IP addresses to clients based on their DHCP client IDs.
    DHCP client ID includes an ID type and a type value. Each ID type has a fixed type value. You can specify a DHCP client ID by using one of the following methods:
    • Use an ASCII string as the client ID. If an ASCII string is used, the type value is 00.
    • Use a hexadecimal number as the client ID. If a hexadecimal number is used, the type value is the first two characters in the number.
    • Use the MAC address of an interface to generate a client ID. If this method is used, the type value is 01.
  • [Wayback/Archive] Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) Parameters
  • [Wayback/Archive] RFC 2132: DHCP Options and BOOTP Vendor Extensions: – section 9.14. Client Identifier
       This option is used by DHCP clients to specify their unique
   identifier.  DHCP servers use this value to index their database of
   address bindings.  This value is expected to be unique for all
   clients in an administrative domain.

   Identifiers SHOULD be treated as opaque objects by DHCP servers.

   The client identifier MAY consist of type-value pairs similar to the
   'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist
   of a hardware type and hardware address. In this case the type field
   SHOULD be one of the ARP hardware types defined in STD2 [22].  A
   hardware type of 0 (zero) should be used when the value field
   contains an identifier other than a hardware address (e.g. a fully
   qualified domain name).

   For correct identification of clients, each client's client-
   identifier MUST be unique among the client-identifiers used on the
   subnet to which the client is attached.  Vendors and system
   administrators are responsible for choosing client-identifiers that
   meet this requirement for uniqueness.

   The code for this option is 61, and its minimum length is 2.

   Code   Len   Type  Client-Identifier
   +-----+-----+-----+-----+-----+---
   |  61 |  n  |  t1 |  i1 |  i2 | ...
   +-----+-----+-----+-----+-----+---

Some links on documentation and nifty configurations

For my link archive:

Queries

––jeroen

This entry was posted on 2026/01/06 at 12:00 and is filed under Communications Development, Conference Topics, Conferences, Cyberchef, Development, DHCP, Encoding, Event, Hardware, HTTP, Internet protocol suite, MikroTik, Network-and-equipment, pfSense, Power User, routers, Software Development, SSH, TCP, TLS, UDP. Tagged: . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

«
»