From: Francis Cianfrocca <garbagecat10@...>
Date: 2006-10-04T07:30:39+09:00
Subject: Re: NET::HTTP behind a firewall?

------=_Part_16208_2640733.1159914634694
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 10/3/06, Jeremy Tregunna <jtregunna@blurgle.ca> wrote:
>
>  Outgoing connections are almost always made on high ports. It doesn't
> matter what you're using to connect out, the fact that you're making
> a client request to some remote server on some port, will cause your
> client ip:port to be <ip you're going out over>:<some high port,
> probably over 10000>.
>
> So be sure you open up say 10000 - 65535 outgoing tcp



The port bound to the *local* side  of the TCP connection will (probably) be
an ephemeral port. From the firewall's point of view, the outbound rule will
specify the remote port, which is still 80. (It's possible but not very
useful to constrain outbound traffic based on the *local* port.) Firewalls
are smart enough to associate local ports with remote ports in regard to
specific connections, so I don't think your suggestion will help.

The OP tells us that iptables is blocking his traffic. I'm inferring
(perhaps incorrectly) that it worked in testing and started failing in prod.
Unless the prod shop mandates a severely locked-down iptables config, then
either the OP has no access to the iptables config, or he doesn't know how
to configure iptables, or else some other component is blocking the traffic.

------=_Part_16208_2640733.1159914634694--