I use some LightwaveRF home automation kit, and one of its key pieces is the Link, which allows me to control my lights and other devices remotely, even when not connected to my home WiFi network.

I recently built a pfSense firewall from components bought from Scan, but when I moved the Link onto the new network behind the pfSense, it’s status light started flashing red, indicating a problem communicating with the remote servers.

My first thought was Strict NAT (where both the source address and source port are rewritten) was causing a problem, so I configured a static port NAT rule for the Link, but to no avail - strict NAT wasn’t causing the problem.

The Link documentation states it only communicates over the network for DHCP and on UDP:2011. Firing up the packet sniffer on the LAN interface and sniffing for the Link’s IP, I could see lots of UDP traffic to an AWS EC2 IP on port 2011, from source port 2011.

However, sniffing for UDP:2011 on the WAN interface showed no traffic, so it was being dropped by pfSense despite there being rules present which should’ve allowed it.

Digging through the pfSense interface, I found a scrubbing option under the System > Advanced > Firewall and NAT tab.

The pfSense documentation states:

Packet normalization - “‘Scrubbing’ is the normalization of packets so there are no ambiguities in interpretation by the ultimate destination of the packet. The scrub directive also reassembles fragmented packets, protecting some operating systems from some forms of attack, and drops TCP packets that have invalid flag combinations.”

• Enabled in the pfSense software by default
• Can disable if necessary. This option causes problems for some NFS implementations, but is safe and should be left enabled on most installations.

Aha! I disabled the packet scrubbing option and the Link status light turned a solid green! I was back in business and able to use my LightwaveRF kit remotely again!

It is possible that static port NAT is still a requirement, since the Link uses port 2011 as both source and destination ports - the remote servers might drop packets to 2011 that are not from source port 2011, but I haven’t bothered to test this theory since it is working now and I’m lazy 😉