From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Taylor Subject: Re: iptables not forwarding port 443 Date: Tue, 06 Jul 2010 13:03:21 -0500 Message-ID: <4C336FE9.3080403@riverviewtech.net> References: ,<4C336248.8060700@freemail.hu> ,<4C336757.5080100@freemail.hu> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: netfilter-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Mail List - Netfilter On 07/06/10 12:40, J. Webster wrote: > No, there is no proxy in the middle in this testing case, I believe > that's why the packets are received at port 443 on the server but > then somehow dropped. Do you show OpenVPN log entries indicating that connections are being attempted? Or is this failing during the TCP three-way-handshake? Have you tried running TCPDump (or the likes) to watch the traffic? > Is there anything wrong with the iptables rules that might stop this? I don't see any thing glaringly obvious. I do question what the source port is on the reply traffic. It may be (a modified version of) what I call the TCP-Triangle (1) that is causing things to break. > It was recommended by the OpenVPN users list. I've also read that OpenVPN can run over port 443, but I've not messed with it my self to know how well it will work. > Yes, I could but that makes an administration problem to do with > status logs and other stuff I think. Can you do it lone enough to test? 1: TCP-Triangle is when traffic from a client (C) is directed to a front end server (F) which then redirects to a back end (B) server and because of various situations the back end (B) server replies directly to the client (C). So what you end up with is C talks to F but replies come from B back to C causing C to reject / reset the reply all the while timing out the initial outgoing packet. C -> F C -> B C <- B C <- B C -> B (RESET I'm not talking to you.) ... C -> F (Timeout) Grant. . . .