Date: Fri, 16 Aug 2013 15:24:26 -0400 From: Jason Hellenthal <jhellenthal@dataix.net> To: Alexander <axex007@yandex.ru> Cc: "freebsd-pf@freebsd.org" <freebsd-pf@freebsd.org> Subject: Re: Windows 7 + freebsd-pf + windows scale SYN-ACK problem Message-ID: <D0F0B6F2-AF75-467B-93B8-AE2BE3A0A6EB@dataix.net> In-Reply-To: <520E35B3.4080607@yandex.ru> References: <520E1822.7010505@yandex.ru> <20130816125058.GA28156@insomnia.benzedrine.cx> <520E35B3.4080607@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] Remove scrub on the interface. This is only an assumption that you have it in your rules file not appearing here ? But ice noticed a similar behavior before with windows 7. Not sure if this might help either but turn off rxcsum and txcsum on lo0 -- Jason Hellenthal Inbox: jhellenthal@DataIX.net Voice: +1 (616) 953-0176 JJH48-ARIN On Aug 16, 2013, at 10:22, Alexander <axex007@yandex.ru> wrote: > 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? > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" [-- Attachment #2 --] 0 *H 01 0 + 0 *H 90000 *H 01 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0 130518085048Z 140519220947Z0H1 0 U jhellenthal@dataix.net1%0# *H jhellenthal@dataix.net0"0 *H 0 '`TmfkܨJ5u +c'Upb`zv)&ȸXZ*VN6JvLoVoh}g pQDŽKf/tZA˳( "4Ԅ˻'d2h| IBl' ^v^;'e8S99ۿVm|k8_UQtC"5l!kjZ]އQGn \Bh!F TsD%pV^Eӑd¨x"9 г" f 00 U 0 0 U 0 U %0++0 U ڔfmVʢ$䟓0 U #0Sr풜\|~5NԸQ0!U 0jhellenthal@dataix.net0LU C0?0; +70*0.+"http://www.startssl.com/policy.pdf0+00' StartCom Certification Authority0This certificate was issued according to the Class 1 Validation requirements of the StartCom CA policy, reliance only for the intended purpose in compliance of the relying party obligations.06U /0-0+)'%http://crl.startssl.com/crtu1-crl.crl0+009+0-http://ocsp.startssl.com/sub/class1/client/ca0B+06http://aia.startssl.com/certs/sub.class1.client.ca.crt0#U 0http://www.startssl.com/0 *H {0Ӹ,52W{Ey8b [ {7 _+P"n["-,@ŽpJ-W$ݍjWA-6z( RdIZ. KzXє[ K6}{s+v.Qh0PͅK hTw 0I73lz*K v4Kkگ63;p1:ױ@)]ok>:W%XwC1þL/o8~#oP040 0 *H 0}1 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1)0'U StartCom Certification Authority0 071024210155Z 171024210155Z01 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0"0 *H 0 -).2AUGo#G B|NDRpM-B=o -we5JQpa>O.#._<V [~**pz~3WG .ᘟMlr[<Ce6fqO"uxfWN#uicgkv$Lb%y`_{`xK'GN 00U 00U 0 U Sr풜\|~5NԸQ0 U #0N @[i04hCA0f+Z0X0'+0http://ocsp.startssl.com/ca0-+0!http://www.startssl.com/sfsca.crt0[U T0R0'%#!http://www.startssl.com/sfsca.crl0'%#!http://crl.startssl.com/sfsca.crl0U y0w0u +70f0.+"http://www.startssl.com/policy.pdf04+(http://www.startssl.com/intermediate.pdf0 *H }x,\c^ #wMq}>UK/^yX֏y frMIŲB61ymQҨݬZ0& ;@#13qۑ& ̢o 6r_;GO>*I( 74XS1r3)!LJy6Kotˆ# _wSr ;B ADp(fs 䰷6%.W0J3:bC<8t X1<Cn=t==wST~\wkBf|15zUP)(IjVB!OfI=bb\4-*em/нSJm7N[]'@ڽ D9Kr>R7/|o^I@ټ'Pa $ z9a'L)( I}vcH]۸D*W} m>Q|C.(,lQ000 *H 0}1 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1)0'U StartCom Certification Authority0 060917194636Z 360917194636Z0}1 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1)0'U StartCom Certification Authority0"0 *H 0 lF|x{3rb6 "$^wC d̎68#nm<r =3+/AYg} tyL7z9RYFC҅qub4, 4ǖR=3M ;JK&/ r5w<]&6v\t%x- 0-ryF*I cSb:̵fkt+v>mDsb ;ľSV%lQ ʿvmۿ=f VH:KߧXP8u[C lMp[)eݪ]̯1 ҍ{n'f HnB?!>{ pclT\%zɢɋ,~^MXn 2n6IHiMi y"H{ipz7 vOW`g:ԋr"Ɵƶ\R<*s `z/ۣn&0݉W=+ŷv+*r3] KtRK R0N0 U 00 U 0 U N @[i04hCA0dU ]0[0,*(&http://cert.startcom.org/sfsca-crl.crl0+)'%http://crl.startcom.org/sfsca-crl.crl0]U T0P0L +70;0/+#http://cert.startcom.org/policy.pdf05+)http://cert.startcom.org/intermediate.pdf0+00' Start Commercial (StartCom) Ltd.0Limited Liability, read the section *Legal Limitations* of the StartCom Certification Authority Policy available at http://cert.startcom.org/policy.pdf0 `HB 08 `HB +)StartCom Free SSL Certification Authority0 *H lf 4Ѕ^} N8 ^ߦ%K2;=D [I)f% <6+Kh9f=&9 Q{~ZWpi^X ߌE8 ^Wbz )n(DÐ8<CMdE(\s{諱.\dns1:}Q;Mf{<Ӛ ePu/CiyCFrd6% 8w~kjDKx, KD4R' ]xS2݀fuٵh(a.8 gd./pǖ|eCTݥ9`4ɖp, H{ ~k";*RKU"4N&",uJ} d6/# ;sIjWxřCcMw-eriG V$ yX. ~m >J9+u U77Cb VKel$$4"}?eQ 0j r^1o0k001 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0 + 0 *H 1 *H 0 *H 1 130816192428Z0# *H 1>o{g3VBrc<))0 +71001 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0 *H 101 0 UIL10U StartCom Ltd.1+0)U "Secure Digital Certificate Signing1806U/StartCom Class 1 Primary Intermediate Client CA0 *H 6{w!֊ p%n:\t&4Y+Bm{nzmv, } l BX'E@)w]4bfn2xub>4)6\ٿaCxQ#Ҷ|)Gf*eyR2LLJ.O 3 fQM #mcVx0( cc D Ec5O6o->>F{Iar$fCptb|otJ
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D0F0B6F2-AF75-467B-93B8-AE2BE3A0A6EB>