On Wed, Sep 19, 2018 at 10:00:28AM +0000, Tim Jones wrote:
>
> > This feels like it might be an MTU related problem, especially likely
> > if the connection is going via pppoe or a tunnel - you may need "scrub
> > (max-mss ##)".
> >
> > The way Google's TLS server handshake is setup, it fits in pppoe without
> > fragmentation, most other sites do not this.
> >
> > Otherwise try simplifying pf.conf (one change at a time and test):
> > disable syncookies and change "modulate state" to "keep state", maybe
> > also the random-id scrub. ("syncookies always" in PF doesn't make a
> > lot of sense to me except for testing, especially if only allowing
> > inside->outside traffic, I think "adaptive" would be more usual if
> > using this feature).
>
>
>
> Thanks Stuart. These sound possibly more likely than some of the other
> suggestions (e.g. wrong date/time or bad pf rules ... I'm not that
> silly).
>
> The connection is not going via PPPoE or tunnel. The immediate next hop
> is an OpenBSD based BGP router (where, incidentally I can't replicate
> this SSL issue, but the router is not (yet) running 6.3 either). The
> OpenBSD router box is then plugged into large carrier routers. So it
> all this is not hanging off the end of some random DSL line !
>
> The reason I've got "syncookies always" is because there are various
> internet exposed services (e.g. webservers) sitting behind this PF
> instance, and as far as I can gather syncookies is recommended as a good
> thing (tm) for these sort of applications ? This PF instance is very
> much a majority out->in instance.
This is a very bad advise you got. Syncookies should only be used in
exterme situations because the they do lose some of the additional
information that is part of the SYN packet. "syncookies always" is only
there for testing but should not be used in production.
Syncookies are a way to preserve resources on the firewalls and servers
when they are attacked by simple SYN floods. This works because the
syncookie allows to respond to SYN packets without creating any kind of
internal state (which is normally required to finish the 3-way handshake).
All the data that would normally be stored in the state has to be
compressed into a few bits of the syncookie and so especially data like the
MSS is not stored at full precision.
> But at the same time I'm also unclear as to what the impact of
> syncookies is on states ? The man page talks of "continue the
> connection with synproxy in place", which in my mind implies "synproxy
> state" ?
Syncookies are similar to synproxy but unlike synproxy they don't create
state on the initial SYN (only on the ACK sent back as repsonse to the
syncookie). It does similar to synproxy only open the backend connection
once the 3-way handshake is finished.
--
:wq Claudio
