Apologies for the double post, there is a better way to do this.
Instead of creating a Custom Service create a new regular TCP object
and name it TCP Reset or something similar. Check the boxes for the
"R" flag in both the Mask and Settings row. Use this object in your
rule instead of the custom service.
You also need to make the rule stateless. Do this by right-clicking
in the Options field and clicking on Rule Options. Check the box that
says "Stateless rule".
Hope this helps!
Regards,
-mike
On Thu, Nov 18, 2010 at 10:32 AM, Mike Horn <mike@...> wrote:
> Hi,
> Thanks for the additional info. Based on the fact that the connection
> between 192.168.0.2 and 192.168.0.1 is working on port 8080 as confirmed by
> your telnet session and that you get some of the page content loaded and the
> proxy is working for other machines on this subnet, it sounds like there is
> a problem with this specific machine and the proxy application. I don't
> think this is an iptables / Firewall Builder issue, but here's an idea you
> could try.
> One way to debug this further -- warning this is a hack -- is to create a
> custom service for TCP resets and allow these resets from the 192.168.0.2
> host to the 192.168.0.1 IP address on the firewall. This would at least
> keep the reset from being blocked at the firewall which could change the
> behavior you are seeing.
> To add the Custom Service go to Services -> Custom and add a new service
> called TCP Reset and set the code string to
> --tcp-flags RST
> and set the protocol to tcp.
> Now add a rule somewhere above your current rule #8 with the Source set to
> the 192.168.0.2 object and Destination set to 192.168.0.1 object service set
> to the TCP Reset object you just created permitted inbound on your internal
> interface.
> Btw, what browser are you using on the Mac machine? Have you tried other
> browsers and seen the same behavior? Let us know what you find.
>
> Regards,
> -mike
> On Tue, Nov 16, 2010 at 11:27 PM, hdlbq <hdlbq@...> wrote:
>>
>> Hello,
>>
>> I'm back with some additionnal information:
>>
>> First, the tcpdump while just telnetting 192.168.0.1 reports no rst. I
>> can,
>> of course, still post the dump, but I think that it will be bandwith
>> waste.
>>
>> I have decided to make more browsing with 192.168.0.2 tcpdump active,
>> until
>> the firewall log shows a rejected RST packet. And this leads to the second
>> trace. I try to upload it as zip file, but I can of course post an
>> extract,
>> around the send of the rst packet.
>> http://old.nabble.com/file/p30235873/serveur.txt2_dmp.zip
>> serveur.txt2_dmp.zip
>>
>> As I mentionned yesterday, the filtering policy of 192.168.0.1 as proxy
>> works as this: when a client requires a page coming from a site that is
>> not
>> yet allowed, the proxy sends a page asking for a password, instead of the
>> normal content. If this occurs for a picture, a css file..., the form is
>> not
>> always displayed (or visible), and (of course) neither filled nor
>> submitted.
>> The client can thus receive only a part of the files it needs. Can this
>> fact
>> leads it to make a reset ?
>>
>> Thanks for your help
>> Best regards
>> --
>> View this message in context:
>> http://old.nabble.com/rather-simple-rule-doesn%27t-match-tp30215530p30235873.html
>> Sent from the fwbuilder-discussion mailing list archive at Nabble.com.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Beautiful is writing same markup. Internet Explorer 9 supports
>> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
>> Spend less time writing and rewriting code and more time creating great
>> experiences on the web. Be a part of the beta today
>> http://p.sf.net/sfu/msIE9-sfdev2dev
>> _______________________________________________
>> Fwbuilder-discussion mailing list
>> Fwbuilder-discussion@...
>> https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion
>
>
|