> On 21 Apr 2017, at 10:34, Stuart Henderson <s...@spacehopper.org> wrote: > > On 2017-04-20, Sjöholm Per-Olov <p...@incedo.org> wrote: >> Could it be any buffers that is causing this in 6.1 but not in 6.0 ? > > There were changes that would allow larger TCP buffers in 6.1. This > would not have made a difference to normal or natted connections from > non-OpenBSD going through PF to non-OpenBSD but could possibly affect > some configurations with proxies (though only if PF rules were already > dodgy - you would have active states in "pfctl -ss|grep -A1 tcp" > without wscale values if this was the case). > > Might be worth bumping up the pf log level and seeing if system logs > give you more clues. Default is "error", you need "notice" to get the > ones which might give useful clues (loose state match warnings or > state mismatch errors). (On a busy machine, be ready to back-off on > the debug level in case it causes too much load). > >
Tnx for the answer Stuart I will check and do what you suggest. In the meanwhile some additions… I have removed all tuning in sysctl.conf to make sure we have nothing that interfere. When pf is reloaded it works perfect for hours. And then the kernel, just like that stops route some packages. when it works it could look like this in the logg… Apr 21 10:32:14.734332 rule 573/(match) pass in on em3: 202.67.41.252.49461 > 192.168.1.12.25: S 583218598:583218598(0) win 8192 <mss 1394,nop,wscale 8,nop,nop,sackOK> (DF) Apr 21 10:32:14.734356 rule 89/(match) pass out on vlan3: 202.67.41.252.49461 > 192.168.1.12.25: S 583218598:583218598(0) win 8192 <mss 1394,nop,wscale 8,nop,nop,sackOK> (DF) Note that the problem appeared and started just between these above and below connections. When it happens I have permanent intermittent issues that is only solved by reloading pf. When it stops working after a few hours it then looks like this where the kernel simply refuse to forward the incoming internet packet on em3 packet to the dmz1 (i.e vlan3)… Apr 21 10:32:17.373591 rule 573/(match) pass in on em3: 122.200.1.158.55956 > 192.168.1.12.25: S 1479648704:1479648704(0) win 8192 <mss 1460,nop,wscale 2,nop,nop,sackOK> (DF) Apr 21 10:32:17.373618 rule 63/(match) block out on em3: 155.4.8.28.25 > 122.200.1.158.55956: R 0:0(0) ack 1479648705 win 0 (DF) root@xanadu:/var/log#pfctl -g -sr|grep @573 @573 pass in log quick on em3 inet proto tcp from any to 192.168.1.12 port = 25 flags S/FSRA keep state (source-track rule, max-src-states 90, max-src-conn 90, max-src-conn-rate 30/30, max-src-nodes 70, overload <bad_hosts> flush global, src.track 30) label "MAIL" root@xanadu:/var/log#pfctl -g -sr|grep @89 @89 pass out log quick on vlan3 inet proto tcp all flags S/SA root@xanadu:/var/log#pfctl -g -sr|grep @63 @63 block drop log all So is it perhaps possible to give any more hints based on this extra info? Here I see wscale in both cases. Note though that on 6.0 it worked flawlessly. I upgraded from 6.0 and just did what the upgrade guide said + did a sysmerge where I kept my pf.conf as is. Peo
