Date: Wed, 18 Oct 2017 19:58:16 +0200 From: "no@spam@mgedv.net" <nospam@mgedv.net> To: <freebsd-questions@freebsd.org> Subject: RE: pf/nat guru needed: fwd of packet to 255.255.255.255 Message-ID: <001c01d3483a$acd06d40$067147c0$@mgedv.net> In-Reply-To: <DD63DF02-3DED-4B71-9BC6-5DAD913EBFAF@sigsegv.be> References: <002101d346c0$65ef67d0$31ce3770$@mgedv.net> <DD63DF02-3DED-4B71-9BC6-5DAD913EBFAF@sigsegv.be>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: owner-freebsd-questions@freebsd.org [mailto:owner-freebsd- > questions@freebsd.org] On Behalf Of Kristof Provost > Sent: Tuesday, October 17, 2017 3:19 PM > To: no@spam@mgedv.net > Cc: freebsd-questions@freebsd.org > Subject: Re: pf/nat guru needed: fwd of packet to 255.255.255.255 >=20 > On 16 Oct 2017, at 22:50, no@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=E2=80=99d consider it a bug if it had a different value. >=20 > You could probably set a scrub rule to change it, so the packet can be > forwarded, but I=E2=80=99d 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=E2=80=99t 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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001c01d3483a$acd06d40$067147c0$>