I have a FreeBSD host which I noticed recently triggering some snort
decoder alerts due to using a TCP window scaling (rfc1323) value of
15. The decoder is tripping because anything greater than 14 is
considered invalid. This text from RFC seems to support it:
Since the max window is 2**S (where
On Tue, Nov 13, 2007 at 03:53:38PM +0200, Alupului Costin wrote:
> On Nov 13, 2007 4:20 AM, Girish Venkatachalam
> <[EMAIL PROTECTED]> wrote:
> > On 22:08:03 Nov 12, Alupului Costin wrote:
> > >
> > > pass in quick on vlan0 from any to anIP/32
> > > pass out quick on vlan0 from anIP/32 to any keep
On Tue, Nov 13, 2007 at 07:25:23PM +0530, Girish Venkatachalam wrote:
> On 18:57:34 Nov 13, Girish Venkatachalam wrote:
> > I just read the post you linked. Thanks. :)
>
> I read the post once again and it looks as though I understood what is
> mentioned there.
>
> The 'no-df' in scrub rule clear
n bridges. I.E. you
> can not create states on inbound rules at all although filtering
> works. Another problem is that states created by outbound traffic
> don't seem to take into account the window scaling when the client
> uses that.
> I was a big fan of the bridge setup simply b
use ALTQ with hfsc discipline; but that's
> > not really important. My problem comes with the filter rules. I have
> > to use keep state because of the speed benefits (really I don't have a
> > choice), but PF has a problem when the clients passing traffic through
&g
On 18:57:34 Nov 13, Girish Venkatachalam wrote:
> I just read the post you linked. Thanks. :)
I read the post once again and it looks as though I understood what is
mentioned there.
The 'no-df' in scrub rule clears the Don't fragment bit in the IP
header. When a host wrongly sends fragmented pack
t; > not really important. My problem comes with the filter rules. I have
> > to use keep state because of the speed benefits (really I don't have a
> > choice),
>
> One should always keep state.
>
> > but PF has a problem when the clients passing traffic through
> >
On 23:42:20 Nov 12, Erik Osterholm wrote:
> My understanding (and please correct me if I'm wrong) is that
> keeping state requires fragmented packet reassembly, which can break
> some applications.
You mean that you cannot support "broken applications" if you do
reassembly?
Packet reassembly h
h the filter rules. I have
> to use keep state because of the speed benefits (really I don't have a
> choice), but PF has a problem when the clients passing traffic through
> the bridge use TCP window scaling. Here is an example of four filter
> rules that I thought should work to pas
On Tue, Nov 13, 2007 at 07:50:53AM +0530, Girish Venkatachalam wrote:
> On 22:08:03 Nov 12, Alupului Costin wrote:
> > I seem to have quite a problem with PF. I have set up a bridge to
> > shape my upstream traffic. I use ALTQ with hfsc discipline; but that's
> > not really important. My problem co
ause of the speed benefits (really I don't have a
> choice),
One should always keep state.
> but PF has a problem when the clients passing traffic through
> the bridge use TCP window scaling. Here is an example of four filter
> rules that I thought should work to pass the traffic fr
e a
choice), but PF has a problem when the clients passing traffic through
the bridge use TCP window scaling. Here is an example of four filter
rules that I thought should work to pass the traffic from one client
through the bridge and create a state:
pass in quick on vlan0 from any to anIP/32
pass ou
On 8/30/07, Shah, Baiju-p98993 <[EMAIL PROTECTED]> wrote:
> Greetings.
>
> We currently use Espion appliance running FreeBSD 4.9 as a mail interceptor
> for SPAM. We have one customer who has their mail gateway hard coded with
> Window Scaling (WS=9). Their mail gateway fa
, August 30, 2007 11:16 AM
To: Shah, Baiju-p98993; freebsd-questions@freebsd.org
Subject: Re: Question about Window Scaling
Hi Baiju,
Try this to get started:
http://proj.sunet.se/E2E/tcptune.html
http://www.wormulon.net/files/pub/FreeBSD_Network_Tuning_-_slides.pdf
If upgrading is an option:
http
--
From: "Shah, Baiju-p98993" <[EMAIL PROTECTED]>
> Greetings.
>
> We currently use Espion appliance running FreeBSD 4.9 as a mail interceptor
> for
> SPAM. We have one customer who has their mail gateway hard coded with Window
> Scaling (W
Greetings.
We currently use Espion appliance running FreeBSD 4.9 as a mail interceptor for
SPAM. We have one customer who has their mail gateway hard coded with Window
Scaling (WS=9). Their mail gateway fails to establish SMTP hello connection
with WS=9. However if they set their Window
>
> "Do you think that it is possible to modify parameters on the BSD box in
> order to reach the same transfer rates than the Debian box with only one
> connection ?"
I would think there may be options you can pass to the ethernet driver via
ifconfig or maybe adjusting net related sysctls. You c
reach more
higher transfer rates.
On my Debian Box, I can reach easily 900 KB/s with only one connection. I
have heard about TCP Window size and Window scaling.
Do you think that it is possible to modify parameters on the BSD box in
order to reach the same transfer rates than the Debian box with
reach more
higher transfer rates.
On my Debian Box, I can reach easily 900 KB/s with only one connection. I
have heard about TCP Window size and Window scaling.
Do you think that it is possible to modify parameters on the BSD box in
order to reach the same transfer rates than the Debian box with
19 matches
Mail list logo
