Date: Sun, 2 Nov 2014 01:00:29 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Hooman Fazaeli <hoomanfazaeli@gmail.com> Cc: freebsd-net@freebsd.org, Mark Felder <feld@freebsd.org> Subject: Re: transparent udp proxy Message-ID: <20141102003200.S52402@sola.nimnet.asn.au> In-Reply-To: <5454CD41.9010704@gmail.com> References: <54535B82.405@gmail.com> <1414764053.1422501.185543329.39B66970@webmail.messagingengine.com> <5453A3F0.7010706@gmail.com> <20141101035050.R52402@sola.nimnet.asn.au> <5454CD41.9010704@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 1 Nov 2014 15:38:33 +0330, Hooman Fazaeli wrote: > On 10/31/2014 8:30 PM, Ian Smith wrote: [..] > > : ipfw add 10 fwd localhost,7000 udp from any to any recv em1 > > > > Given these are local packets and that ipfw(8) /fwd states: > > > > The fwd action does not change the contents of the packet at all. > > In particular, the destination address remains unmodified, so > > packets forwarded to another system will usually be rejected by > > that system unless there is a matching rule on that system to > > capture them. For packets forwarded locally, the local address > > of the socket will be set to the original destination address of > > the packet. This makes the netstat(1) entry look rather weird > > but is intended for use with transparent proxy servers. > For FreeBSDs before 9.0, that description is only correct for TCP > packets. For 9.0+, it is true for both UDP and TCP. Ok. Well that description, up to that point, is identical from 8.2 to 9.3, so it's been wrong (and incomplete, re UDP) for a long time .. That's what I get for treating ipfw(8) with undue reverence while having virtually no knowledge of socket internals :) Unless you're not getting them in recvmsg() as ipfw forwarded them? Sorry, I'll quit speculating; way out of my depth - or rather, level. > Old kernels (before 9.0), change the destination of UDP packets forwarded to > a local address to > the forwarded-to address and port (those specified in the fwd rule). > > > Has the destination port in the received packet been changed to 7000? > > > > If not, you're all set. If so, where else could the dst port be stored? > There is no way to get the destination port. That is the problem. > recvmsg(2) only returns source address+port and destination IP > address. (on 9.0+). I naively ass(13)umed you'd still have access to raw IP and UDP headers, and that they'd indeed be unchanged. > Best regards. > Hooman Fazaeli cheers (and out), Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141102003200.S52402>