pf/nat guru needed: fwd of packet to 255.255.255.255

[no@spam@mgedv.net]

> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org [mailto:owner-freebsd-
> questions at freebsd.org] On Behalf Of Kristof Provost
> Sent: Tuesday, October 17, 2017 3:19 PM
> To: no at spam@mgedv.net
> Cc: freebsd-questions at freebsd.org
> Subject: Re: pf/nat guru needed: fwd of packet to 255.255.255.255
> 
> On 16 Oct 2017, at 22:50, no at spam@mgedv.net wrote:
> > hi folks,
> >
> > short: anyone out there knows, how to redir & forward packets to
> > 255.255.255.255?
> >
> > preface: i need to get a crappy, stupid, very (!) wrong programmed
> > device
> > running.
> > and i know this crapdev violates RFCs, so this is the wrong story for
> > RTFM
> > hints ;)
> >
> > the BSD box setup:
> > freebsd 11.1, amd64.
> > - interface "A": 10.10.21.1/24, MTU1500
> > - interface "B": 10.10.22.1/24, MTU1500
> >
> > the (crapdev) source generates an ipv4 UDP packet as follows:
> > - source address 10.10.21.11, port >1023
> > - target hw addr: ff:ff:ff:ff:ff:ff
> > - target ipv4 addr: 255.255.255.255 port 4444
> > - payload ~ 500 bytes, so it fits inside 1 packet.
> >
> I would not be surprised if that packet also has a TTL of 1.
> In fact, I’d consider it a bug if it had a different value.
> 
> You could probably set a scrub rule to change it, so the packet can be
> forwarded, but I’d be very tempted to just run a proxy for this,
> rather than trying to fix it with pf.
> It might even be possible to get the appropriate socat incantation to do
> it, so maybe you don’t even need to write any code for this.

the TTL idea is great! but the packet is of course violating this, too:
tos 0x0, ttl 128, id 17466, offset 0, flags [none], proto UDP (17), length 536

the (crappy) solution to a crappy communication:
i added a 2nd NIC for the source-LAN to the final target.
the packet to 255.255.255.255 ends up directly there, bypassing the fw.
the talkback is unicast. the 2nd NICs IP is set to invalid. hope this is enough.
(both VLANs are restricted and local only anyways).
so: issue worked around (dirty), no further analysis on our side (lack o' time).
thx!