Date: Mon, 1 Nov 2004 12:01:00 -0500 From: Bill Eccles <Bill.lists@Eccles.net> To: Aaron Nichols <adnichols@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: ipfw configuration to intercept SMTP traffic Message-ID: <9B6D4C6C-2C27-11D9-A4D5-000D932C81E8@Eccles.net> In-Reply-To: <ac05538404110108274e8e4445@mail.gmail.com> References: <200410312349.08193.4711@chello.at> <BDAAF00E.10E7%Bill.lists@Eccles.net> <ac0553840411010822650f4ed0@mail.gmail.com> <ac05538404110108274e8e4445@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Actually, the original question contains the tidbit that the machine doing the serving is also the problem child, i.e., all of the traffic that I need to redirect is being produced on the same box from that box's SMTP server. Thanks for the explanation, though. Low-level TCP stuff is not my forte... yet. Bill On Nov 1, 2004, at 11:27 AM, Aaron Nichols wrote: >> I believe you'll have one additional problem to resolve. Even if you >> successfully modify the destination IP address and get it pointed to >> the upstream server, the source IP will be unmodified and will still >> be the originator. Since the source IP is unmodified - the upstream >> mail server will send an ACK back to the originators IP (not yours) >> which will most likely get discarded and the connection will fail. >> Most sane TCP/IP stacks will reject an ACK from an IP address to which >> it did not send a request. Since the ACK is not going to run back >> through your host (thus allowing natd another go at reversing the >> translation) this likely wont work. > > Sorry all - I had missed the post regarding use of the -proxy_rule > option, which may address this issue. > > Didn't mean to futher confuse the issue. > > Aaron >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9B6D4C6C-2C27-11D9-A4D5-000D932C81E8>