Blocking QUIC for Advertisement Filtering in OPNsense While Allowing Facebook Mobile

24 July 2026
Jonathan Aquilina - Eagle Eye T
Ad Blocking , Open Source Software , Opnsense

Blocking network traffic is not always about fixing something that is broken. Sometimes it is a deliberate part of a wider privacy and filtering strategy.

That is the situation with QUIC on my OPNsense network.

QUIC is blocked across the network to support advertisement filtering and prevent clients from using UDP port 443 as an alternative path around controls designed for conventional HTTPS traffic. The objective is to retain the broader filtering policy while allowing a specific Android device to use QUIC, which Facebook Mobile relies on heavily.

The answer is not to remove the network wide block. OPNsense can instead create a narrow exception for the Android device based on its Wi-Fi MAC address.

This preserves the default policy for the rest of the network while allowing the selected phone to communicate over QUIC.

What is QUIC?

QUIC is a modern encrypted transport protocol that operates over UDP. It provides reliable multiplexed connections, integrated encryption, lower connection establishment latency and support for network path migration.

HTTP/3 runs over QUIC. The practical firewall distinction is:

Traditional HTTPS normally uses TCP port 443.
QUIC and HTTP/3 commonly use UDP port 443.

Allowing HTTPS over TCP port 443 does not automatically allow QUIC. A firewall can therefore permit ordinary web browsing while separately blocking UDP port 443.

QUIC is especially useful on mobile devices, which frequently encounter changing network conditions, packet loss and movement between Wi-Fi and mobile data.

Why block QUIC as part of an advertisement filtering policy?

QUIC is encrypted by design. Although that protects user traffic, it can also reduce the visibility available to firewalls, proxies and older filtering or inspection systems.

Some network administrators block outbound UDP port 443 so compatible applications and browsers fall back to HTTPS over TCP port 443. The fallback keeps traffic on the path expected by existing DNS, proxy, application control or content filtering policies.

This can be useful as one layer of an advertisement filtering strategy, particularly where the firewall is also running DNS blocklists or another filtering service. OPNsense includes integrated DNS blocklist support through Unbound, which can prevent clients from resolving known advertising and tracking domains.

There is an important distinction: blocking QUIC is not a complete advertisement blocker by itself.

It blocks a transport path rather than identifying whether the encrypted content is an advertisement. Applications may fall back to TCP, and advertisements can still be delivered over conventional HTTPS. The actual blocking may be performed by DNS blocklists, proxy rules or another filtering product. The QUIC rule supports those controls by keeping clients on a traffic path they can handle.

If an application uses encrypted DNS, hard coded addresses or first party advertising endpoints, additional controls may still be required.

Why make an exception for Facebook Mobile?

Meta has invested heavily in QUIC. In 2020, the company reported that more than 75 percent of its internet traffic was already using QUIC and HTTP/3. Meta also developed its own implementation, called mvfst, and tested it at scale on Android, iOS and server infrastructure.

Facebook Mobile may be able to fall back to TCP in some situations, but QUIC is an important part of the transport architecture Meta has built for its applications. Allowing it can improve connection establishment, media delivery and general responsiveness under changing mobile network conditions.

In this configuration, QUIC remains blocked for the wider network. The exception is granted only to the Android device that should be allowed to use Facebook Mobile over Meta’s preferred transport.

This is a policy exception, not the correction of an accidental OPNsense fault.

Understand the scope of the exception

A standard OPNsense firewall rule cannot identify “the Facebook app” merely from the phone’s MAC address.

If a rule permits UDP port 443 from one Android device to any internet destination, it permits all QUIC traffic from that device. Chrome, YouTube and other applications on the phone may also use QUIC.

That means advertisement filtering may become less effective on the exempted device. The rest of the network remains covered by the original block.

It is technically possible to restrict the destination using IP or hostname aliases, but large platforms such as Meta use extensive and changing address ranges, content delivery systems and shared infrastructure. A destination list can quickly become incomplete or difficult to maintain.

The device wide exception is simpler and more dependable, provided its wider effect is understood.

The intended OPNsense rule order

The policy should operate in this order:

Permit UDP port 443 from the selected Android device.
Block or reject UDP port 443 from the remaining clients.
Continue processing the normal outbound rules.

OPNsense evaluates firewall rules according to section and sequence. Quick rules use first match behavior, while floating and interface group rules can be evaluated before ordinary interface rules.

The targeted pass rule must therefore be placed where it is evaluated before the wider QUIC block. If the network wide block exists as a higher priority floating rule, an interface level exception beneath it may never be reached.

Allow QUIC for one Android device using its MAC address

OPNsense provides MAC address aliases for client specific policies. The firewall learns the addresses associated with the client and dynamically tracks its IPv4 and IPv6 addresses.

The MAC alias can then be used as the source of the QUIC pass rule.

Step 1: Find the Wi-Fi MAC address Android is actually using

Do not assume that the factory MAC address printed on the device is the address visible to OPNsense.

Android enables MAC randomization for Wi-Fi networks. Open the connected network’s details on the phone and locate the MAC address, Randomized MAC address or Privacy setting. The exact menu varies between manufacturers.

You can also check the active DHCP lease or ARP table in OPNsense:

Find the Android device’s current IP address.
Locate that address in the DHCP leases or ARP table.
Record the MAC address associated with it.
Confirm the address matches the Wi-Fi network details shown on Android.

Android commonly uses a persistent randomized MAC for an individual network profile, but some Android versions and configurations support non-persistent randomization. If that address changes, the firewall rule will stop recognizing the device.

On a trusted network, use either a persistent per network randomized address or deliberately select the device MAC for that SSID.

Step 2: Create the OPNsense MAC address alias

In OPNsense:

Open Firewall > Aliases.
Select Add.
Enter a name such as ANDROID_QUIC_EXCEPTION.
Set Type to MAC address.
Enter the Android device’s Wi-Fi MAC address, for example AA:BB:CC:DD:EE:FF.
Add a description such as Android device permitted to use QUIC.
Save and apply the changes.

Open Firewall > Diagnostics > Aliases and inspect the new alias. It should contain the IPv4 or IPv6 address currently associated with the phone.

OPNsense MAC aliases dynamically track client addresses, but mappings may not update instantly. The alias depends on the firewall’s knowledge of the device through host discovery, ARP and NDP.

Step 3: Create the targeted QUIC pass rule

Open Firewall > Rules and select the interface where the Android traffic enters OPNsense. This may be LAN, a Wi-Fi VLAN, a Media network or another internal interface.

Create the exception with these settings:

Setting	Value
Action	Pass
Quick	Enabled
Direction	In
TCP/IP version	IPv4 + IPv6, or the address family in use
Protocol	UDP
Source	`ANDROID_QUIC_EXCEPTION`
Source port	Any
Destination	Any
Destination port	443 (HTTPS)
Gateway	Default
Log	Enabled temporarily
Description	Allow QUIC for selected Android device

The service may be labelled HTTPS because port 443 is selected. Confirm that the rule’s transport protocol is UDP, not TCP.

Move the pass rule above the general rule that blocks UDP port 443. Save and apply the configuration.

Step 4: Confirm that the rule is being used

Open Firewall > Log Files > Live View and filter using:

The Android device’s current IP address.
Protocol UDP.
Destination port 443.

Use Facebook Mobile and open the feed, images or video content. The traffic should match the new pass rule rather than the network-wide QUIC block.

After verifying the policy, logging can be disabled on the exception rule to reduce routine firewall noise.

A more dependable approach: static DHCP mapping

The MAC alias approach meets the requirement of identifying the Android device by its MAC address, but it still resolves that hardware address to the client’s current IP addresses.

For a predictable long term configuration, create a static DHCP mapping using the same Wi-Fi MAC address. The phone will then receive a reserved IPv4 address.

You can either:

Keep the MAC alias as the source of the firewall rule.
Create a host alias containing the reserved IP address.

The static address makes firewall logging, troubleshooting and policy verification easier. It also avoids delays while a changed address is rediscovered.

Remember that a changed Android randomized MAC address will affect both the static DHCP mapping and the firewall alias.

Should the main QUIC policy use Block or Reject?

OPNsense offers both actions:

Block silently discards the traffic.
Reject discards it and returns an error to the client. For UDP, this is normally an ICMP unreachable response.

Rejecting UDP 443 on a trusted internal interface may encourage compatible applications to abandon QUIC and fall back to TCP more quickly. A silent block may leave them waiting for a timeout.

The targeted Android pass rule must be evaluated before either type of general denial.

Whether Block or Reject is more suitable depends on the filtering design and the behavior you want from non-exempt clients. Check the firewall logs after changing the action and confirm that applications are falling back as expected.

Security and privacy considerations

The exception is narrow, but it comes with several trade-offs:

The Android device can use QUIC for every service, not only Facebook.
Advertisements and tracking traffic may also use the newly permitted path.
Some network monitoring or inspection tools may have less visibility into QUIC.
A MAC address can be spoofed and should not be treated as strong authentication.
A changing Android randomized MAC can make the rule stop working.
IPv4 and IPv6 must both be considered if the network supports dual stack connectivity.

The rule is therefore best treated as a documented policy exception. Give it a clear description and periodically confirm that the device still requires it.

Troubleshooting checklist

If the exception does not behave as expected, check the following:

The MAC alias contains the phone’s current address under Firewall > Diagnostics > Aliases.
The rule is applied to the interface where the Android traffic originates.
The exception is above the general UDP 443 block.
A higher priority floating or interface group rule is not blocking the traffic first.
The rule uses UDP rather than TCP.
The destination port is 443.
The phone has not changed its randomised Wi-Fi MAC address.
Both IPv4 and IPv6 paths are covered.
Live View shows the exception rule receiving traffic.
The broader QUIC block still applies to other clients.

Final thoughts

The purpose of this configuration is not to repair a generally broken Facebook application or an OPNsense fault. QUIC is being blocked deliberately as part of a broader advertisement filtering and traffic control policy.

Facebook and Meta rely extensively on QUIC, so a selected Android device may be given an exception without abandoning the network wide rule.

Using an OPNsense MAC address alias keeps that exception limited to the intended device. The trade off is that OPNsense is permitting UDP port 443 for the phone as a whole, not only for Facebook Mobile. Other applications and potentially advertising traffic can use the same path.

That is the balance being made: retain the stricter advertisement filtering policy for the wider network while granting one clearly documented device access to QUIC.

Sources