Bdtyktl

I'm trying to add a simple PF rule:

block return-rst out proto tcp from any to any port 33128

to filter all outgoing traffic to TCP port 33128, and I'd like it to respond with a reset. However, when I test it with nc, it times out, instead of returning right away with a connection refused error, which suggests packets going to port 33128 are dropped without a TCP reset being sent:

$ nc -v 172.22.2.2 33128

nc: connectx to 172.22.2.2 port 33128 (tcp) failed: Operation timed out

The way I enable PF and add this rule:

$ echo "block return-rst out proto tcp from any to any port 33128" > pf.conf

$ sudo pfctl -f pf.conf

$ sudo pfctl -e

What's wrong with this rule?

I found that some of PF firewall rules work incorrectly after Thunderbolt Ethernet is connected, but work correctly when WiFi is the only network adapter. For example, action "return-rst" does not return TCP RST packets .

Update

I figured out that this bug affects any wired ethernet connection. Even built-in iMac ethernet adapter vs built-in WiFi adapter. Tested on old and newer iMac's.

Steps to Reproduce:
In the first step let's try correct behaviour. To do so, we need macbook/iMac with WiFi only connection, no Thunderbolt Ethernet connected.

1. Flush all PF rules
   sudo pfctl -F all




2. Create simple rule to block TCP connection to port 81, that should return TCP RST packet to abort connection instantly.
   echo "block return-rst out proto tcp from any to any port 81" | sudo pfctl -e -f -




3. Check if the new rule was added correctly.
   
   Here we can see the counter of packets that match firewall rule.
   pfctl -vsr
Packets: 0 Bytes: 0




4. Now trying to test firewall rule using curl that connects to port 81
   curl http://example.com:81
curl: (7) Failed to connect to example.com port 81: Connection refused

See that connection refused immediately by firewall rule as expected. It's a correct behaviour.

Now test the incorrect behaviour. To do so we need to connect genuine Apple Thunderbolt Ethernet with active wired connection. WiFi connection can be disabled or stay enabled, this does not matter, bug will appear in both cases.

1. Leave firewall rules the same




2. Trying to use curl again
   curl http://example.com:81
.....waiting....
curl: (28) Connection timed out
   
   Now connection is hanging and closes after a while by timeout. But the firewall rule is still active and working.




3. We can look at the packet counters
   pfctl -vsr
   and see that rule is matching and still blocking the connection. But without TCP RST reply.

My setup:

macOS: 10.14.1 (18B75)

MacBook Pro (Retina, 15-inch, Mid 2015)

Apple Thunderbolt 2 Ethernet adapter (57762)