Date: Fri, 16 Aug 2013 18:22:43 +0400 From: Alexander <axex007@yandex.ru> To: Daniel Hartmeier <daniel@benzedrine.cx> Cc: freebsd-pf@freebsd.org Subject: Re: Windows 7 + freebsd-pf + windows scale SYN-ACK problem Message-ID: <520E35B3.4080607@yandex.ru> In-Reply-To: <20130816125058.GA28156@insomnia.benzedrine.cx> References: <520E1822.7010505@yandex.ru> <20130816125058.GA28156@insomnia.benzedrine.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16.08.2013 16:50, Daniel Hartmeier wrote: > On Fri, Aug 16, 2013 at 04:16:34PM +0400, Alexander wrote: > >> Now my question is, is there any solution to stop PF block syn-ack >> packets that don't have wscale option in a connection where syn >> packet has it (in my case wscale proposed by windows 7 host is 8) > The missing wscale on the SYN-ACK is not the reason pf is blocking the > packet. This case is quite common: if the client supports (and offers) > window scaling, but the server doesn't support it. If pf would not work > in this case, more people would have noticed already ;) > > So, what other reasons could there be for the reply to arrive on the > external interface but not get forwarded to the internal interface > (that's what you verified, right?)? > > Check pfctl -si output before and after reproducting the problem, > are any counters increasing? If you simply disable pf for a test, > does it work? > > Same with netstat -sp ip|tcp > > HTH, > Daniel Big thanks to your feedback. > (that's what you verified, right?)? Yes, I surely did. On $if_int my dump doesn't notice any [S.] packets from server and on client using wireshark i don't see them as well. tcpdump -i vlan1 host 172.29.67.67 and host 172.29.27.204 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan1, link-type EN10MB (Ethernet), capture size 65535 bytes 18:21:00.553449 IP 172.29.27.204.55111 > 172.29.67.67.6666: Flags [S], seq 3377056805, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 18:21:03.559818 IP 172.29.27.204.55111 > 172.29.67.67.6666: Flags [S], seq 3377056805, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 18:21:04.868003 IP 172.29.27.204.55114 > 172.29.67.67.6666: Flags [S], seq 1159659251, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 18:21:05.003432 IP 172.29.27.204.55115 > 172.29.67.67.6666: Flags [S], seq 3718401262, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 18:21:05.144330 IP 172.29.27.204.55116 > 172.29.67.67.6666: Flags [S], seq 3444072516, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 Turning off PF woks. Some more info: Before test: root@gate:~ # pfctl -si Status: Enabled for 0 days 00:26:54 Debug: Urgent State Table Total Rate current entries 927 searches 365228065 226287.5/s inserts 2898304 1795.7/s removals 2897377 1795.2/s Counters match 3310402 2051.1/s ............................................. ip-option 108080 67.0/s proto-cksum 0 0.0/s state-mismatch 2648 1.6/s state-insert 214 0.1/s ............................................... After test: root@gate:~ # pfctl -si Status: Enabled for 0 days 00:27:00 Debug: Urgent State Table Total Rate current entries 890 searches 365299207 225493.3/s inserts 2898323 1789.1/s removals 2897433 1788.5/s Counters match 3310425 2043.5/s ................................... ip-option 108080 66.7/s proto-cksum 0 0.0/s state-mismatch 2650 1.6/s state-insert 214 0.1/s .................................. As i understand we have 2 packets(syn-acks i suppose) dropped due to state-mismatch. My further investigation revealed if i put following rules: (where vlan1 = $if_int, bge0 = $if_ext, and bridge0 to pass not natted traffic) block drop all pass quick on vlan1 inet proto tcp from 172.29.67.67 port = 6666 to <My-net> no state pass quick on bge0 inet proto tcp from 172.29.67.67 port = 6666 to <My-net> no state pass quick on bridge0 inet proto tcp from 172.29.67.67 port = 6666 to any no state pass quick on bridge0 inet proto tcp from <My-net> to 172.29.67.67 port = 6666 no state pass quick on vlan1 inet proto tcp from <My-net> to 172.29.67.67 port = 6666 no state pass quick on bge0 inet proto tcp from <My-net> to 172.29.67.67 port = 6666 no state .....omitted... <here and till the and i have only pass rules> My connection with server (port 6666) starts to work and i think i can be satisfied by this solution. But i still cannot understand why packets are dropped without no state rules. As i revealed they are dropped between bridge0 and vlan 1 interfaces. (to be more specific - clients that experience this problem are not natted on gateway they are just filtered by pf) PS: Do i need to add netstat -sp outputs?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?520E35B3.4080607>