Wouter Gritter
Software Developer | Electronics Hobbyist | Homelab Enthusiast
Home My Homelab Posts Contact/Where to Find Me

Getting a KPN TV+ box working behind your own pfSense router

Posted on 8th of August 2026.

I run my home network on pfSense, not KPN's Experiabox. That's fine for internet, but the KPN TV+ IPTV box is a different beast: KPN delivers TV as routed IPTV over multicast, and the box expects to talk to KPN's TV platform on a VLAN that the Experiabox normally handles for you. Replace the Experiabox and you inherit that job.

This post is how I got it working. It's pfSense-specific, but the concepts map cleanly onto OPNsense too.

The actual problem

You might assume the issue is NAT-behind-NAT. It isn't. The real problem is that KPN splits your line into separate VLANs, and the TV box needs one you don't normally touch:

Your internet already lives on VLAN 6. To get TV working you need pfSense to bring up VLAN 4, pull a DHCP lease from KPN on it, and then route/forward the multicast TV streams from that VLAN down to the box on your LAN. That's the whole game.

Prerequisites

For the examples I'll use placeholder values:

One tip up front: don't put the box on a dedicated IPTV VLAN. It's tempting for isolation, and it's fine for testing, but the TV+ box doubles as a Chromecast, and casting is far less painful when the box shares a subnet with your phones and laptops. I run mine straight on my regular LAN.

1. Bring up VLAN 4

Create a VLAN with tag 4 on your WAN-facing physical port (igb1 becomes igb1.4), then assign it as a new interface. I called mine WAN_IPTV.

You don't need to configure this as a WAN-type interface. It effectively acts as one, since the classless route KPN pushes over DHCP (step 2) sends the TV traffic out through it, but that happens on its own. You just assign the interface and let DHCP do the rest.

Configure WAN_IPTV:

The IPTV_RG class identifier is the magic word. KPN only hands out an IPTV lease to a client that identifies itself as an IPTV residential gateway. This is DHCP option 60, sent by the client.

Use ISC DHCP, not KEA. On current pfSense the KEA DHCP client does not work for this. Switch back to the deprecated ISC DHCP client or you'll never get a lease.

2. What the lease looks like

Once it's up, WAN_IPTV gets an address from KPN's TV range, e.g. 10.88.72.3/21. Because you requested classless-routes (option 121), it also gets a classless static route pointing at KPN's TV platform, e.g.:

213.75.112.0/21 via 10.88.72.1

pfSense installs that as a static route automatically. That 213.75.0.0/16 / 217.166.0.0/16 space is where KPN's TV servers and the multicast sources live. Note there's no default gateway and no DNS on this interface, and that's intentional. TV traffic only follows those specific routes.

3. Your LAN's DHCP server

Run your normal DHCP server on the LAN the box lives on, with one extra option:

That's it. Do not set option 60 (IPTV_RG) on this DHCP server. One guide tells you to, and it's wrong: option 60 is a vendor class identifier the client sends, not something a server hands out.

4. NAT outbound

Switch outbound NAT to Hybrid so you can add manual rules without losing the automatic ones. Add:

5. Firewall rules

On WAN_IPTV (traffic coming in from KPN's TV network):

On your LAN:

Why "Allow IP options"? IGMP membership reports carry the Router Alert IP option. pfSense drops packets with IP options by default, so IGMP silently dies unless you tick this on the IGMP rules. Make sure these rules sit above any generic match-all rule on the same interface.

6. IGMP proxy

Routed IPTV is multicast, and your LAN is a different segment from KPN's TV VLAN, so something has to forward the multicast streams across. That's the IGMP proxy: it listens for the box joining a channel (an IGMP group) and pulls that stream down from the upstream.

Enable Services -> IGMP Proxy and add:

Finally, on every switch between pfSense and the TV box, enable IGMP snooping and fast leave. Without snooping, multicast floods every port; without fast leave, channel switching is sluggish because old streams take too long to stop.

At this point, plug in the box and it should pull a picture.

A gotcha worth knowing about

igmpproxy on pfSense can wedge itself. If you repeatedly disable/enable the service, especially while the box is actively streaming, the daemon can deadlock inside FreeBSD's multicast teardown and end up stuck in an unkillable D state (even kill -9 won't touch it). Once that happens, every new instance blocks on the same lock and only a reboot clears it.

Symptoms: TV stops working, netstat -g -f inet shows the VIF table populated but the forwarding table empty, and no IGMP queries going out on the downstream. If you see that, stop poking it and reboot. Don't keep toggling the service, that's what makes it worse. If you want to stop it cleanly, turn the box off first, wait for the streams to drain, then stop the proxy.

Running the box on multiple networks

Got multiple LAN networks and want the box to work on all of them? Repeat the LAN-side steps for each subnet:

Sources