How to add pf Dup-To rules
-
Hi,
would someone know how to add a pf bridge in order to copy traffic?
I am fine with getting into the command-line etc. since this is for testing. I'd like to avoid a conflict between such custom rules and the pfSense firewall management.
Dup-to is a standard pf feature, as indicated in the man pages. My concern is that the feature is not directly available via the pfSense utilities and I am looking for the best way to do this.
Best,
Marius -
@mciep
For testing purposes you can add fw rules to the/tmp/rules.debug
and re-read them withpfctl -f /tmp/rules.debug
You can also create a feature request:
https://docs.netgate.com/pfsense/en/latest/development/feature-requests.html -
@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.
-
@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.
-
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.
-
.... feature request now added, thank you.
https://redmine.pfsense.org/issues/12665
-
@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.
-
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.
-
@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.
-
@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.
-
@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.
-
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 -
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.