1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

#!/usr/bin/env python3
"""Encode classless routes (RFC 3442) for DHCP option 121."""
import ipaddress

def encode(routes):
    out = bytearray()
    for dest, via in routes:
        net = ipaddress.ip_network(dest, strict=False)
        n = (net.prefixlen + 7) // 8                 # significant destination octets
        out.append(net.prefixlen)
        out += net.network_address.packed[:n]
        out += ipaddress.ip_address(via).packed
    return bytes(out)

routes = [
    ("192.0.2.0/24", "192.168.1.254"),   # the other site, through the VPN router
    ("0.0.0.0/0",    "192.168.1.1"),     # the default route: mandatory when you send 121
]
raw = encode(routes)
print("hex      ", raw.hex())
print("mikrotik ", "0x" + raw.hex())
print("isc      ", ", ".join(str(b) for b in raw))
print("pfsense  ", ":".join(f"{b:02x}" for b in raw))

1
2
3
4

hex       18c00002c0a801fe00c0a80101
mikrotik  0x18c00002c0a801fe00c0a80101
isc       24, 192, 0, 2, 192, 168, 1, 254, 0, 192, 168, 1, 1
pfsense   18:c0:00:02:c0:a8:01:fe:00:c0:a8:01:01

The format

Every route in option 121 is three fields glued together, no separators:

A /24 carries three destination octets, a /16 two, a /32 four, and the default route /0 none: 00 followed directly by the router. Several routes are concatenated; the whole option fits in 255 octets (about 28 /24 routes).

The rule that breaks the network

RFC 3442, section 3: “If the DHCP server returns both a Classless Static Routes option and a Router option, the DHCP client MUST ignore the Router option.” If you start sending 121 with a single route to the other site, clients that understand it lose the gateway from option 3 and are left with no way out to the Internet. The default route goes inside 121, always, as in the example. Clients that do not understand 121 keep using option 3, so leave that configured too.

Where it goes

ISC dhcpd (dhcpd.conf): the option has to be declared, and it is worth sending it as 249 as well, which is what older Windows ask for:

1
2
3
4
5
6
7
8
9

option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
option ms-classless-static-routes code 249 = array of unsigned integer 8;

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.100 192.168.1.199;
  option routers 192.168.1.1;
  option rfc3442-classless-static-routes 24, 192,0,2, 192,168,1,254, 0, 192,168,1,1;
  option ms-classless-static-routes     24, 192,0,2, 192,168,1,254, 0, 192,168,1,1;
}

Kea (2.4 or later) understands the option by name with a readable notation, no hex:

1
2
3
4

"option-data": [
  { "name": "classless-static-route", "code": 121,
    "data": "192.0.2.0/24 - 192.168.1.254, 0.0.0.0/0 - 192.168.1.1" }
]

pfSense / OPNsense: with the ISC backend, Services → DHCP Server → Additional BOOTP/DHCP Options, number 121, type String, value in colon-separated hex (18:c0:00:02:…); add another with 249 for Windows. With the Kea backend, option 121 is not in the UI yet (as of this post there are open requests in both projects); if your version allows custom Kea options, use the JSON above; if not, that is a reason to stay on ISC.

MikroTik RouterOS:

1
2
3
4

/ip dhcp-server option add name=classless code=121 value=0x18c00002c0a801fe00c0a80101
/ip dhcp-server option add name=classless-ms code=249 value=0x18c00002c0a801fe00c0a80101
/ip dhcp-server option sets add name=routes options=classless,classless-ms
/ip dhcp-server network set [find address=192.168.1.0/24] dhcp-option-set=routes

Which clients understand it

Check on the client with ip route (Linux), route print (Windows) or netstat -rn (macOS) after renewing the lease.

Traps

• A /32 with a router in another subnet: valid in the encoding, but the client needs a prior route to that router; order routes from most to least specific and put the local segment’s first if needed.
• Routes to networks the DHCP server does not control (a DHCP server on one VLAN advertising routes through another) are accepted anyway: 121 is a list of bytes, nobody validates it. A one-octet mistake becomes a route to a made-up network.
• Clients do not revisit routes until they renew the lease; after changing the option, T1 (half the lease) is how long they take to see it, or force a renewal.
• Windows and 249: if you only send 121, modern Windows uses it; 249 is for compatibility and carries exactly the same bytes.
• /0 advertisements from a rogue DHCP: any DHCP server on the LAN can rewrite every client’s default route with 121; DHCP snooping on the switch is the only real defense.

Reference: RFC 3442.

See also

• GCP Cloud VPN will not come up — the VPN these routes usually point at.
• pfSense: NAT reflection and split DNS — the other LAN setting clients receive without noticing.

In Logs Explorer, every tunnel phase has its query:

Cloud VPN runs strongSwan underneath, so the messages are strongSwan’s: if you know charon, you already know how to read them.

What each message means

establishing IKE_SA failed, peer not responding. Cloud VPN sends IKE_SA_INIT and nobody answers. In order of likelihood: the peer is on IKEv1 and the tunnel on IKEv2 (or the reverse), the configured peer IP is not the real public one (NAT in front of the firewall), UDP 500 and 4500 do not reach the peer, or the peer does not even have the tunnel enabled. The PSK does not produce this message: with a wrong PSK, phase 1 starts and fails at IKE_AUTH.

IKE_SA … established between and then nothing. Phase 1 fine, phase 2 not. Look for CHILD_SA and traffic selectors.

Remote traffic selectors narrowed / Local traffic selectors narrowed. The phase 2 networks do not match on both sides. On HA VPN (and route-based Classic VPN) Cloud VPN proposes 0.0.0.0/0 on both sides and expects the same; a policy-based peer with specific subnets makes strongSwan narrow the selectors and pass traffic only between what matched, or nothing. On the peer: phase 2 with 0.0.0.0/0 local and remote (on pfSense, Routed mode, which creates an ipsecN tunnel interface), and routing handled by BGP or static routes.

received DELETE for ESP CHILD_SA in a loop. The peer tears phase 2 down every few minutes: mismatched phase 2 lifetimes with badly negotiated rekeys, or aggressive DPD. Match lifetimes (Cloud VPN uses 3 hours for phase 2 and 10 for phase 1) and let only one side initiate rekeys.

Comes up, passes traffic for a while, dies with NAT-T. A peer behind NAT on UDP 4500 and a middlebox that “helps” (IPsec ALG on the router) drops encapsulated ESP packets. Disable the ALG or move the firewall onto a direct public IP.

HA VPN with BGP against pfSense (FRR)

The tunnel comes up, bgp establishes, and no route comes in or goes out. FRR on pfSense starts with a policy that rejects everything not explicitly permitted:

1. Services → FRR → BGP → Route Maps: create ALLOW-ALL, Action Permit, Sequence 100, no criteria.
2. BGP → Neighbors → the Cloud Router peer: Remote AS the Cloud Router’s ASN, and under Peer Filtering assign ALLOW-ALL as route map in and out.
3. BGP → Network Distribution: list the local networks you want to advertise (or Default Originate if everything goes through the tunnel).
4. On GCP, the Cloud Router with --advertisement-mode custom if you want to control which prefixes go out; by default it advertises the VPC subnets.

Without step 2, vtysh -c "show ip bgp summary" shows the session Established with 0 prefixes in both directions, which is exactly the symptom.

Traps

• IKEv2 unless the peer cannot: IKEv1 is still supported, but without IPv6 and with fewer ciphers. Classic VPN still exists (99.9%), but part of its functionality is retired; new work goes on HA VPN (99.99%).
• Two tunnels per gateway on HA VPN for the 99.99%: if you only bring one up, the gateway status stays in warning even though it works.
• MTU: 1460 by default on the GCP VPC; with IPsec on top, let TCP do MSS clamping on the peer (pfSense does it on the tunnel’s ipsecN interface) or you will see transfers hanging after the handshake.
• Logs lag: a minute or two between the event and Logs Explorer. Refresh before changing the configuration again.
• A PSK with special characters copied from a password manager: check on the peer that nothing got eaten; the symptom is IKE_AUTH failing, not peer not responding.

See also

• pfSense: NAT reflection and split DNS — the other classic of “the tunnel is fine and I still cannot get there”.
• Cloud VPN troubleshooting in the Google Cloud documentation.

1
2
3
4
5
6
7
8
9

pfctl -sT                                    # loaded tables
pfctl -t <table> -T show                     # contents
pfctl -t <table> -T add 192.168.1.10         # add an IP or network (10.20.0.0/16 works too)
pfctl -t <table> -T delete 192.168.1.10
pfctl -t <table> -T test 192.168.1.10        # is it inside? (match / no match)
pfctl -t <table> -T flush                    # empty the table
pfctl -t <table> -T replace -f /path/list    # replace the whole contents from a file

pfctl -t sshguard -T flush                   # pfSense: clear the failed-login lockout

What a table is

A PF table is a set of addresses and networks that rules reference as <name>. It changes live, without reloading the ruleset, and holds thousands of entries with fast lookups; that is why PF uses tables for block lists, bogons, and anything that changes more often than the rules.

In pf.conf:

1
2

table <blocklist> persist file "/etc/pf/blocklist.txt"
block in quick from <blocklist>

persist keeps the table even when no rule uses it at the moment; file loads it from a file (one IP or network per line).

Commands

All in the form pfctl -t <table> -T <command>:

And without -t:

1
2
3
4

pfctl -sT                    # names of all tables
pfctl -vvsT                  # global info per table: entries, evaluations, references
pfctl -T load -f /etc/pf.conf   # reload only the table definitions from pf.conf
pfctl -sr | grep '<name>'    # which rules use a table

Tables on pfSense

• Aliases are tables. A Host, Network, or URL Table alias called Admins exists in PF as <Admins>; pfctl -t Admins -T show shows what pfSense resolved, including the FQDNs it already turned into IPs.
• sshguard: where IPs blocked for failed SSH or webGUI logins land. If you locked yourself out, pfctl -t sshguard -T flush (documented by Netgate under Locked out of the WebGUI).
• virusprot: hosts blocked for exceeding a rule’s Max. src. conn. rate or Max. states limits. pfctl -t virusprot -T show and -T delete <ip> to release one.
• snort2c: Snort/Suricata blocks in legacy mode. -T flush to unblock everything.
• bogons / bogonsv6: the lists that update themselves when you enable Block bogon networks on an interface.
• pfBlockerNG: every list is a pfB_* alias. To know whether an IP is blocked by one: pfctl -t pfB_Top_v4 -T test 203.0.113.7.

On OPNsense the mechanics are the same (pfctl -sT to see the names); the login lockout table is called sshlockout.

What gets lost on reload

Any -T add, -T delete, or -T flush lives until the next filter reload: saving almost anything in the GUI, Filter Reload under Status → Filter Reload, or the alias update cron. At that point pfSense regenerates every table from its alias and your manual changes are gone. To make something permanent, edit the alias; for quick tests and unblocking, pfctl is perfect.

Beyond tables

What gets used most alongside the above:

1
2
3
4
5
6
7

pfctl -sr                    # loaded rules (with -vv, counters and rule numbers)
pfctl -ss                    # state table
pfctl -si                    # global statistics
pfctl -k 192.168.1.10        # kill a host's states
pfctl -F states              # kill all states (cuts every connection)
pfctl -d / pfctl -e          # disable / enable PF (no PF means no NAT: only to get out of a lockout)
pfctl -nf /etc/pf.conf       # syntax check without loading

Full reference: the OpenBSD Handbook’s pfctl cheat sheet and man pfctl on FreeBSD.

Clean option (split DNS): Services → DNS Resolver → Host Overrides → app.example.com → the server’s internal IP (192.168.1.50). LAN clients must use the firewall as their DNS.

NAT reflection option: System → Advanced → Firewall & NAT:

• NAT Reflection mode for port forwards: Pure NAT
• Enable NAT Reflection for 1:1 NAT: ✔
• Enable automatic outbound NAT for Reflection: ✔

Save and test from a LAN client against the public IP.

The problem

The port forward WAN:443 → 192.168.1.50:443 works from the Internet. From a machine on the same LAN, https://app.example.com (which resolves to the public IP) answers with the pfSense GUI, a certificate error, or Potential DNS Rebind attack detected.

The packet leaves the client towards the public IP, reaches the firewall through the LAN interface, and stops there: the port forward rule listens on the WAN, not the LAN, and the destination IP is one of the firewall’s own addresses. It never “goes out and comes back in”.

Option 1: split DNS

This is what Netgate recommends: the name resolves to the internal IP inside and to the public one outside. Traffic goes direct, the server sees the client’s real IP, and the firewall touches nothing.

1. Services → DNS Resolver → Host Overrides → Add: host app, domain example.com, IP 192.168.1.50. If the service has several names, add Additional Names.
2. Clients must use the firewall as DNS (the norm if DHCP hands it out). A client with 8.8.8.8 hardcoded will keep going to the public IP.
3. nslookup app.example.com from the LAN → 192.168.1.50.

Requirement: the internal and external ports must be the same (if outside you forward 8443 → 443, the internal client will have to use 443 directly).

If you run the DNS Forwarder (dnsmasq) instead of the Resolver, the equivalent setting is under Services → DNS Forwarder → Host Overrides.

Option 2: NAT reflection

When you do not control the clients’ DNS, or there are lots of ports, the firewall can “reflect” the connection: it rewrites the destination to the internal IP and, with automatic outbound NAT, the source too, so the reply comes back through the firewall.

System → Advanced → Firewall & NAT, Network Address Translation section:

It can also be enabled per rule: Firewall → NAT → Port Forward → edit → NAT reflection → Enable (Pure NAT), leaving the global setting on Disable.

Costs: the server sees the firewall’s LAN IP as the source (not the client’s), and all that traffic crosses the firewall even when client and server sit on the same switch.

OPNsense

Same idea, other menus:

• Split DNS: Services → Unbound DNS → Overrides → Host Overrides.
• Reflection: Firewall → Settings → Advanced → Reflection for port forwards, Reflection for 1:1, Automatic outbound NAT for Reflection.

Traps

• DNS rebinding. If instead of a host override you point the Resolver at an external DNS that returns private IPs (an internal DNS at another site, a provider with views), Unbound drops those answers as rebinding protection. Do not untick Disable DNS Rebinding Checks under System → Advanced → Admin Access: add private-domain: "example.com" under Services → DNS Resolver → Custom options and only that domain is exempt.
• A client with hardcoded DNS bypasses split DNS. Either force it through DHCP, catch it with a port 53 NAT rule, or use reflection.
• Pure NAT needs to know the interface and gateway when rules load; with dynamic WANs that change IP, a Filter Reload after the IP change fixes it.
• Different ports inside and outside only work with reflection; split DNS does not translate ports.
• Certificates: with split DNS the browser still sees app.example.com, so the server’s certificate works as is. When reflecting through the public IP, too. The certificate error at the start was the firewall GUI’s, not the server’s.

References: Port Forwards from Local Networks and NAT Reflection in the Netgate documentation.

From the console (option 8) or Diagnostics → Command Prompt:

1
2
3
4
5
6

certctl rehash
pkg-static clean -ay
pkg-static install -fy pkg
pkg-static install -xfy pfSense-repo pfSense-upgrade
pkg-static update -f
pfSense-upgrade -d -c        # shows which version the configured branch offers

With pkg alive again, finish the pending upgrade through System → Update (or pfSense-upgrade -d), not with pkg upgrade.

The error

1

ld-elf.so.1: Shared object "libssl.so.30" not found, required by "pkg"

You see it on pkg update, when installing a package, or indirectly: System → Package Manager shows up empty and System → Update cannot check versions. Sometimes the binary complaining is pfSense-repoc instead of pkg; it is the same problem.

Why it happens

pfSense is FreeBSD, and pkg is a binary dynamically linked against the system’s libssl. When the configured repository belongs to a pfSense release built on a newer FreeBSD, its packages come linked against a newer OpenSSL (libssl.so.30 = OpenSSL 3). If pkg, or pfSense-repoc, gets updated from that repo before the base system, the new binary asks for a library that does not exist on your install yet.

How you get there:

• A manual pkg upgrade from the shell. On pfSense you never do that.
• Installing or reinstalling a package after switching the Branch in System → Update to a higher version, without upgrading.
• An upgrade interrupted halfway (typical in the 2.7.0 → 2.7.1/2.7.2 jump, when the base moved to OpenSSL 3).
• On pfSense Plus, rolling back to an older boot environment with the repo pointing at the new one (Redmine #15070).

The library name will change across releases; the mechanics and the fix stay the same.

Fix

pkg-static is the statically linked copy of pkg: it needs no libssl, which is why it works when pkg does not.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 1. Let pkg-static talk TLS to the repo (holds until the next reboot)
certctl rehash

# 2. Drop the cache and reinstall pkg and the repo configuration
pkg-static clean -ay
pkg-static install -fy pkg
pkg-static install -xfy pfSense-repo pfSense-upgrade   # -x: regex, so pfSense-repoc comes along

# 3. Refresh metadata and check
pkg-static update -f
pfSense-upgrade -d -c

If pkg-static update still fails, pkg-static -d update prints the full trace (certificates, DNS, wrong branch).

Before step 3 check the Branch under System → Update: it must be the version you want to reach, not an intermediate one. And finish the job through the GUI or with pfSense-upgrade -d: a stray pkg upgrade leaves you halfway again.

If the base system is so mixed up that even this does not fly, Netgate’s documented last resort is pkg-static upgrade -f (reinstalls everything), followed by a reboot.

Traps

• pkg upgrade does not exist on pfSense. The only supported path is System → Update / pfSense-upgrade. This whole situation is born from skipping it.
• Backup first: Diagnostics → Backup & Restore. On ZFS, also a boot environment (System → Boot Environments) lets you roll back in one reboot.
• Do not copy libssl.so.30 from another FreeBSD. It circulates as a trick; it leaves the system with libraries from two releases and breaks the next upgrade.
• Packages first, no. With an upgrade pending, upgrade the system and then install packages, not the other way around.
• The repo and the upgrade use HTTPS: if certctl rehash is not enough, check the firewall’s system time and DNS.

Reference: Upgrade Troubleshooting in the Netgate documentation.

1. Cloudflare → My Profile → API Tokens → Create Token → Edit zone DNS template: permissions Zone → Zone → Read and Zone → DNS → Edit, Zone Resources limited to your zone. Copy the token; the Account ID and Zone ID are on the zone’s Overview page.
2. pfSense → System → Package Manager → install acme and haproxy.
3. Services → ACME → Account keys → Add: ACME Server Let’s Encrypt Production ACME v2 (or Staging to test) → Create new account key → Register → Save.
4. Services → ACME → Certificates → Add: name, the account, Domain SAN list: app.example.com (and *.example.com if you want a wildcard) with method DNS-Cloudflare, and in its fields only Token, Account ID and Zone ID. Actions list: Restart Local Service → haproxy. Save → Issue.
5. Services → HAProxy → Frontend → edit → SSL Offloading ✔ on the listen address → Certificate: the one ACME just created → Save → Apply Changes.

Automatic renewal (the package’s daily cron) and HAProxy restarted on every renewal.

Cloudflare: the token

The Global API Key old guides ask for gives access to the whole account; an API token with minimal permissions is the right thing and is what the package’s DNS-Cloudflare method uses when you fill in Token:

With Token one of the two IDs is enough; setting both does no harm. Token permissions: Zone:Read and DNS:Edit on the specific zone (Include → Specific zone).

If you enable Client IP Address Filtering on the token, it must include the firewall’s public IPv4 and also IPv6: pfSense goes out through whichever it has, and a token limited to v4 fails as soon as the API call goes over v6.

ACME: account and certificate

Account. Create two: one against Staging to test and one against Production. Staging has no issuance limits but its certificates are not trusted; once everything works, switch the certificate’s account to production and issue again.

Certificate. Under Services → ACME → Certificates → Add:

• Domain SAN list: one entry per name. For a *.example.com wildcard the validation has to be DNS-01 (HTTP-01 does not allow it). A wildcard does not cover the apex: add example.com as a second entry.
• Method: DNS-Cloudflare on each entry, with the three fields.
• DNS Sleep: Cloudflare propagates in seconds; the default is plenty. If issuance fails with TXT not found, raise it to 120.
• Key: RSA 2048 or ECDSA 256; both work fine with HAProxy.
• Actions list: Restart Local Service → haproxy. Without it, HAProxy keeps serving the old certificate until someone restarts it, even though ACME has already renewed.

Issue from the certificate list. The result shows up under System → Certificates with the name you gave it; that is where HAProxy will see it.

HAProxy: using the certificate

Services → HAProxy:

1. Settings: enable HAProxy, and leave Max SSL Diffie-Hellman size at 2048 or more.
2. Frontend → your HTTPS frontend → External address: port 443, SSL Offloading ✔ → SSL Offloading section → Certificate: the ACME one. For several domains on the same frontend, Additional certificates with the rest; HAProxy picks by SNI.
3. Save → Apply Changes.

Test from outside:

1
2

openssl s_client -connect app.example.com:443 -servername app.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -dates

issuer=C = US, O = Let's Encrypt and notAfter 90 days out.

As a bonus, the pfSense GUI with the same certificate: System → Advanced → Admin Access → SSL/TLS Certificate, and a second action on the ACME certificate: Shell Command /etc/rc.restart_webgui.

Traps

• Cloudflare in proxy mode (orange cloud) does not affect DNS-01, but it does affect how traffic arrives: if the A record is proxied, HAProxy sees Cloudflare’s IP as the source. For an internal service behind pfSense, grey cloud.
• Issue fails with Invalid request headers or Authentication error: token without permission on that zone, token IP filter, or the Zone ID of another zone.
• Production rate limits: five certificates per set of names per week. Test on staging.
• The certificate renews; HAProxy does not reload it by itself. The restart action is mandatory. Check under Services → ACME that the last renewal has a date and in openssl s_client that notAfter moved.
• ACME certificates renew at 2/3 of their lifetime (about 60 days). If you see the cron running and nothing changes before then, that is normal.

Reference: ACME package in the Netgate documentation and acme.sh’s DNS provider list (dns_cf section).

System → Certificates → Certificate Revocation → pencil on the CRL the OpenVPN server uses → Lifetime (Days) = 730 → Save. Saving regenerates the CRL with valid dates. Then Status → Services → OpenVPN → Restart. Clients get back in without changing anything on their side.

If the GUI will not let you set a sane lifetime (versions before 2.7 / 23.01), first System → Patches (the System Patches package) → apply Fix for CRL expiration lifetime default and maximum values (a3c1589086ea67d25a28ec14ab95d7fd9ab25fa2), then the step above. Or upgrade pfSense: current versions already carry it.

The error

In the server log (Status → System Logs → OpenVPN) and on the client:

1
2
3
4

VERIFY ERROR: depth=0, error=CRL has expired: CN=client1, serial=3
OpenSSL: error:0A000086:SSL routines::certificate verify failed
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS handshake failed

The clue is that every client fails at once. An expired certificate takes down one client; an expired CRL takes down the whole server, because it is checked on every handshake.

Why it happens

Two roads lead here:

1. The CRL really expired. Every CRL has a nextUpdate; past that date OpenSSL treats it as invalid and OpenVPN rejects everyone. A CRL created years ago with a short lifetime and never touched ends up like this.
2. The CRL was born expired. pfSense generated CRLs with a 9999-day default, which pushed them past 2050. X.509 encodes dates up to 2049 as UTCTime with a two-digit year, and pfSense wrote 50 where GeneralizedTime was due: OpenSSL reads it as 1950 and the CRL “expired” 75 years ago. That is Redmine bug #13424, and it explains why healthy installs started failing in 2022–2023 with nobody touching anything: CRLs regenerated by any change crossed 2050.

Netgate’s fix lowered the default lifetime to 730 days, capped the maximum (2050 on 64-bit, 2038 on 32-bit), and ships in current versions; for old ones it remained as a patch in the System Patches package.

Checking it

pfSense writes each OpenVPN server’s CRL into its configuration directory:

1
2

ls /var/etc/openvpn/server1/
openssl crl -in /var/etc/openvpn/server1/crl-verify -noout -lastupdate -nextupdate

A nextUpdate in the past, or a year of 1950, is the whole diagnosis.

Fix

1. Identify which CRL the server uses: VPN → OpenVPN → Servers → edit → Peer Certificate Revocation list.
2. Regenerate it: System → Certificates → Certificate Revocation → pencil on that CRL → Lifetime (Days) 730 → Save. Any save rewrites it with lastUpdate = now.
3. Restart OpenVPN: Status → Services. OpenVPN re-reads crl-verify when it notices the change, but the restart saves you the wait.
4. Check again with the openssl crl above.

On a version without the fix, between steps 1 and 2: System → Package Manager → install System_Patches → System → Patches → the patch shows up in the recommended list → Apply. Without it, the GUI writes 9999 again and the problem repeats as soon as you save.

Traps

• Do not delete the CRL to “fix it”: without a CRL, the certificates you revoked become valid again. Edit it.
• One CRL per CA: if you have several OpenVPN servers with different CAs, check each one.
• Imported CRLs (from an external CA) cannot be regenerated from pfSense; request a new one from your CA and import it again.
• 730 days run out too. Any revocation, CRL edit, or change to the OpenVPN server regenerates it; if you touch nothing for two years, you are back here. A calendar reminder is cheap.
• Past 2038 on 32-bit hardware the other limit applies; in practice none of that gear should still be your firewall.

References: Certificate Revocation List Management in the Netgate documentation and Pasquale Fiorillo’s write-up.

System → Advanced → Networking → Disable hardware checksum offload ✔ → Save → reboot the VM. The GUI does not say so, but the change does not apply to vtnet interfaces until the reboot.

To test without rebooting (lost at boot):

1
2

ifconfig vtnet0 -rxcsum -txcsum -tso -lro
ifconfig vtnet1 -rxcsum -txcsum -tso -lro

On OPNsense: Interfaces → Settings → Hardware CRC → Disable hardware checksum offload, and the same reboot.

Symptoms

The VM boots, the interfaces are UP, LAN DHCP hands out addresses, and still:

• Hosts behind the firewall cannot reach the Internet, or connections stall halfway (ping passes, TCP hangs).
• From the virtualization host itself or from other VMs on the same host nothing protected by pfSense is reachable, not even the GUI.
• Switching the VM’s NIC to e1000 fixes it on the spot, which confirms the diagnosis.

Why it happens

FreeBSD’s vtnet driver, with checksum offload enabled, hands the network stack packets whose checksum never got computed: between VMs on the same host, and between the host and the VM, traffic never crosses a physical NIC that would do it. FreeBSD sees invalid checksums and drops them (FreeBSD bug 165059). Netgate documents it under VirtIO Driver Support.

pfSense tries to tick the option only when it detects vtnet interfaces at install time. If the VirtIO NIC was added later, if you restored the config.xml from a physical firewall, or if you migrated the VM from another hypervisor with a different NIC type, the option stays off.

Procedure

1. System → Advanced → Networking, Network Interfaces section:

   • Disable hardware checksum offload: tick it.
   • Disable hardware TCP segmentation offload and Disable hardware large receive offload: already ticked by default; leave them.

2. Save.

3. Reboot from Diagnostics → Reboot. Without this step nothing changes on vtnet.

4. Check:

   1	ifconfig vtnet0 | grep options

   Neither RXCSUM nor TXCSUM (nor TSO4, LRO) should show up.

If it is still the same

• All of the VM’s NICs must be the same kind. A vtnet with offload and an e1000 behave differently; check every ifconfig.
• Offload on the host. Netgate notes that sometimes checksums and TSO must also be turned off on the hypervisor. On Proxmox/KVM, on the VM’s tap interface: ethtool -K tap100i0 tx off (the number is the VMID and i0 the NIC). Rarely needed; try it last.
• Plan B: e1000 NIC model on the VM. Less throughput than VirtIO without offload, but none of this bug.

Traps

• The reboot is not optional and the GUI does not ask for it. It is the number one cause of “I ticked it and it still does not work”.
• It is not a rules problem. With offload on, packets are dropped before reaching pf; the firewall log shows nothing.
• e1000 on OPNsense too as plan B; the equivalent setting lives under Interfaces → Settings.
• Multiqueue (queues=N on Proxmox) works fine with vtnet once offload is off; do not mistake it for the cause.