> 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. 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" ?
