Simen Stavdal wrote: : Worth submitting a feature request? : --- I looks like this would be the best solution ---
Sounds like you have your desired solution. So long as the OBSD developers accept your request as valid. : --- The subject of my posting is "Duplicating incoming packets to : multiple destinations using pf --- : --- And I never initially asked a closed question, but I did state : a scenario --- Right, so I was led to believe that the context of your question was limited to re-mapping SNMP destinations. In other words, you had a specific problem on hand to solve, and that SNMP trap multiplexing was that problem. : You have a piece of machinery. It's going to send traffic, to a : given : destination. However, this "destination" may be more than one : machine. It : may be two. It may be five. And the traffic may be single : datagrams, or : it may be a constant stream. Who knows. You don't want to update : the : source when this destination point changes, due to administrative : overhead. : So, you need an arbitrary resolution that is not protocol-specific, : that : provides a single point of management (or otherwise incurs a very : low : administrative overhead), and where the client doesn't need to be : modified. : --- I wouldn't describe the scenario as arbitrary --- Let's not argue over words. You need a resolution that can be applied to any number of situations. You need a resolution that is sufficiently abstracted such that it addresses the root problem, not the specific use case you supplied. This is where I went wrong, and my apologies: I addressed the specific instance of the problem, and not the underlying challenge. : --- There is a very usable syntax in place, which is also the : beauty of pf --- Whether or not it's the right tool for the job, I leave it up to the OBSD developers to decide. : --- A multicast sends traps to all listening devices, which : excludes the opportunity to filter destinations in pf --- Not entirely true. A multicast packet is destined towards a single address, for which multiple (physically separate hosts) are listening. Network gear duplicates the packet as needed, to ensure it reaches all members of that multicast group. I'm arguing semantics here, but there's a very important distinction: your SNMP client only sends out *one* packet per trap. : things. : 1) You're looking for a short-term fix for your problem. You've : been handed : a short-term fix. : --- I didn't say I was looking for a short term fix --- Not explicitly, but you implied it with your use case. Or maybe I misread you. Either way, you've established that you don't care to fix this specific SNMP problem, you want PF to be modified to do what you need. (Speaking of which, there's Yet Another Alternative. Set your trap destination to be some arbitrary address. Assign that address to the loopback interface of *all* SNMP receivers. Assign unique IPs to their external interfaces. That way, when you use pf's dup-to, each machine will actually receive the packet. It's clean, uses the functionality that currently exists, is only a mild abuse of best practices, and requires no network reconfiguration. This approach can be duplicated as needed.) - Damian
