From owner-freebsd-questions@freebsd.org Wed Oct 18 17:58:20 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E69D3E40480 for ; Wed, 18 Oct 2017 17:58:20 +0000 (UTC) (envelope-from nospam@mgedv.net) Received: from mail.mgedv.net (mail.mgedv.net [83.64.34.254]) by mx1.freebsd.org (Postfix) with ESMTP id A716063E8F for ; Wed, 18 Oct 2017 17:58:20 +0000 (UTC) (envelope-from nospam@mgedv.net) Received: from my.loop (client.my.loop [255.255.255.255]) From: "no@spam@mgedv.net" To: References: <002101d346c0$65ef67d0$31ce3770$@mgedv.net> In-Reply-To: Subject: RE: pf/nat guru needed: fwd of packet to 255.255.255.255 Date: Wed, 18 Oct 2017 19:58:16 +0200 Message-ID: <001c01d3483a$acd06d40$067147c0$@mgedv.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHRu9U+ErauKZ6SvrTNkEattvcJUwIiE3/LotvpuQA= Content-Language: de-at X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 17:58:21 -0000 > -----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!