[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: synproxy problem

[email protected] (Daniel Hartmeier) wrote in message news:<[email protected]>...
> On Fri, Jan 23, 2004 at 03:35:50PM -0700, duncan wrote:
> > I tried to implement synproxy the other day and found that some of our 
> > clients couldn't connect to our http servers.
> The rule looks ok (including the flags), you'll need to provide more
> information about how it is not working. Make sure you have 'log' on all
> 'block' and 'scrub' rules, enable debug logging (pfctl -xm), then
> reproduce the problem. Do you get anything in pflog or
> /var/log/messages?
> Run tcpdump -nvvvpXi $ext_if and capture the handshake of one failed
> connection and post it. If you see a complete handshake (SYN, SYN+ACK,
> ACK) on the external interface, tcpdump on the internal interface as
> well and repeat.
> Daniel
I just implemented a 3.4 stable firewall and experienced the same
problem.  It was only happening to people coming from a local ISP that
had just started migrating users to PPPOE DSL from standard DSL (we
have a T-1 connection).  From Lynx they could see my no frames page
(and see them in the Apache access logs), but if they tried to hit the
main page with graphics and what not it would just time out.  I at
first thought it was some PMTUD black hole, but working with them I
ended letting in all icmp and redirecting icmp to the web server in
the DMZ as well, no dice.  Took out scrub rules still not working. 
Changed synproxy to keep state or modulate state and everything worked
fine.  After it was working I added the scrub rules back in, and
blocked all ICMP.  Still worked even with blocking all ICMP.
Let me know if you want to see tcpdumps from this and I can post them.
Greg McConkey