Hi again Nobody has answered, so I suppose nobody else has this problem :-) That's good.
So just to make sure: Is anybody using syncookies and/or synproxy in production in a similar setup? Thx /markus On 11/4/19 8:35 PM, Markus Wernig wrote: > Hi all > > After being hit by some synflood waves recently I enabled syncookies on > our OBSD 6.6 i386 CARP fw pair: > > set syncookies always > > This stopped the state table from filling up. But after some hours pf > started (randomly?) dropping legitimate connection attempts, both on > external->internal (dst-natted) and on internal->internal (not natted) > connections (TCP only, afaict). > > Looking at pflog and the rule number that blocked the packet, it seems > that the preceding "pass quick" rules matching the packets were ignored. > > The packets that were dropped were the ACK ones, so the SYN-SYNACK seems > to have taken place. The client then usually retransmitted the ACK, > which kept being dropped for ca. 15-20 seconds, after which time it was > suddenly accepted and the connection established. Many times also only > the first ACK was dropped, and the first retransmit was accepted. > > So I disabled syncookies and set the relevant ~5 external->internal > rules to synproxy state. > > With that, the same behaviour happened within a few minutes. > > During that time pfctl -vsi showed the "synproxy" counter increasing by > multiple thousands per second (sic), while the state table entries > remained stable around 500 (their normal value). > > So I disabled the synproxy state again, but reloading the rules with > pfctl was not enough, I had to reboot both boxes to stop them from > dropping legitimate connections. With both syncookies and synproxy > disabled, the problem does not occur. > > Is anybody aware of anything that could trigger this behaviour? Or have > any hint where I could look further? I have all the log files if more > info is needed. > > thx /markus > > (btw. the behaviour was the same on 6.5) >
