How to add pf Dup-To rules

Andrew453

@mciep Hi Marius. Thanks for this (and for your helpful blog post at https://blog.because-security.com/t/pf-dup-on-a-pfsense-gateway-for-separate-distributed-ids-sensors/576?utm_source=pocket_mylist)

Did you ever raise a feature request for this please? I need to do the same thing, but need the dup to rules to persist after a filter reload.

I would suggest that, rather than having a feature in the GUI specific to dup to, instead there is simply a plain text field that the user can add whatever rules they want and they are appended by filter.inc within pfSense as part of the filter reload.

johnpoz

@andrew453 said in How to add pf Dup-To rules:

Did you ever raise a feature request

I don't see anything in redmine with dup-to mentioned.

Andrew453

Thanks very much @johnpoz. I'll add a feature request if I may on Redmine, as I think it would be helpful to have the ability to add custom pf rules from the GUI.

Andrew453

.... feature request now added, thank you.

https://redmine.pfsense.org/issues/12665

Andrew453

@mciep Hi Marius. I've been trying to get this to work today, but haven't been able to without blocking the original traffic flow.

I'm trying to mirror traffic from a specific device on my network (say 192.168.1.87).

If I tweak the existing rule that permits that traffic to duplicate to another address on the LAN for monitoring, e.g.

pass in quick on $LAN dup-to ( em1 192.168.1.3 ) inet from 192.168.1.87 to any tracker 1574414022 allow-opts keep state label "USER_RULE: Allow specific LAN addresses outbound"

... then I can see the traffic being mirrored to 192.168.1.3 (i.e. I can see the packets arriving in Wireshark on the 192.168.1.3 device) but for some reason the original NAT'd traffic doesn't route properly.

Instead of seeing a steady flow of TCP communications back and forth from the server with which 192.168.1.87 is supposed to communicate, I see a TCP SYN attempt followed by 6 retransmissions of the SYN (in each case mirrored to the 192.168.1.3 device). So clearly the original packet isn't getting through (or the reply is blocked).

It feels like a NAT/state problem to me but I've tried various permutations of match rules (which shouldn't disturb the original packet), no state specified as an option etc, all to no avail.

Grateful for any hints to the extent you or anyone else can point me in the right direction.

JKnott

@andrew453

One way to do this is with port mirroring on a managed switch. You can even make a "data tap" with a cheap 5 port managed switch.

Andrew453

@jknott Thanks. I had a look at this. There's a number of reasons that make that complicated here:

the device I want to monitor is on wifi only
it's an IoT device so I can't set up anything fancy, like VLANs.
the monitoring device has a number of functions and only has one network interface. Yes, I could add an extra ethernet port (e.g. via USB) but it's extra complexity.
even if I did add an extra port, if I was mirroring a port on a managed switch it would inevitably be picking up quite a bit more traffic than that of the particular device I want to monitor.

So, yes, it could be made to work but ideally I just want to set up a (simple) rule in pfSense and have it mirror the specific traffic to the monitoring device without any need to change network connections, set up new ports, reconfigure switches etc.

As described in my earlier posts, I've managed to get it to mirror the specific traffic, it's just for some reason it breaks the routing of the original packet.

JKnott

@andrew453 said in How to add pf Dup-To rules:

the device I want to monitor is on wifi only

You can set up a filter in Wireshark to capture only a specific IP or MAC address. So, with port mirroring on your switch, you can easily do that. If you make a data tap, you can put it wherever you can pick up the Ethernet connection.

Andrew453

@jknott Yes, understood. I should also have said I'm not using Wireshark.

I'm writing an application in C# (which incidentally does use WinPcap) to monitor the IoT device and then do things when it sees particular events occurring. This is a permanent arrangement.

The IoT device sends about 5KB every 15 mins, so I don't want to bombard the monitoring server with GBs of traffic going across the switch.

Also, if all I wanted to do was do a Wireshark analysis (which I've done already), I can use the packet capture facility that natively exists in Pfsense and/or ntopng and produces a pcap file that I can import into Wireshark.

Andrew453

I managed to (sort of) get this to work.

Rather than create the rules on the LAN, I created the rules on the WAN.

It's not ideal because it requires the filter to be applied to the destination server IP, which could in theory change. I'll just have to keep an eye on that.

I tweaked etc/inc/filter.inc to add the new rules immediately after the marker for the user defined rules:

	$ipfrules .= "\n# User-defined rules follow\n";
	$ipfrules .= "\nanchor \"userrules/*\"\n";
	$ipfrules .= "pass  out log  on {  em0  } dup-to ( em1 192.168.aaa.aaa ) inet proto tcp  from any to bbb.bbb.bbb.bbb port 80 tracker 1641638644 flags S/SA keep state  label \"USER_RULE: Outbound mirror\"\n";
	$ipfrules .= "pass  in log  on {  em0  } dup-to ( em1 192.168.aaa.aaa ) inet proto tcp  from bbb.bbb.bbb.bbb to 192.168.ccc.ccc port 80 tracker 1641638677 flags S/SA keep state  label \"USER_RULE: Inbound mirror\"\n";

where:
192.168.aaa.aaa is the internal IP address of the server on my network that is monitoring the device
192.168.ccc.ccc is the internal IP address of the device to monitor
bbb.bbb.bbb.bbb is the public IP address of the server that the monitored device talks to on the internet

Andrew453

fyi, the below is broken after upgrading to 2.6.0.

From some digging, this version introduces "ridentifier" rather than "tracker" in rule definitions.

If you replace

tracker 1641638644

with

ridentifier {$increment_tracker()}

... then all appears to work again.