PF, bridge, states and window scaling problem

[Alupului Costin]

On Nov 13, 2007 2:30 PM, J65nko <j65nko at gmail.com> wrote:
>
> On Nov 12, 2007 9:08 PM, Alupului Costin <costin.alupului at gmail.com> wrote:
> > Hello all,
> >
> > 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 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
> > 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 out quick on vlan0 from anIP/32 to any keep state queue ul_client
> > pass in quick on vlan1 from anIP/32 to any
> > pass out quick on vlan1 from any to anIP/32 keep state queue dl_client
> >
> > The above rules generate state-mismatches. I thought that would be
> > because pf doesn't see the SYN packet, although it does (one of the
> > out rules) and should create the state then... I tried writing all the
> > rules with keep state (even the inbound ones) but then nothing would
> > work at all. My intention was to create if-bound states, but I
> > switched back to floating states in the hope that pf would associate
> > the state created by an outbound rule with the traffic returning on
> > another interface of the bridge; still didn't work.
> >
> > I have read the man page for if_bridge and set the following sysctl variables:
> >
> > net.link.bridge.pfil_onlyip: 1
> > net.link.bridge.pfil_bridge: 0
> > net.link.bridge.pfil_member: 1
> >
> > I have also read some posts on the web that said that pf simply
> > doesn't have all the hooks necesary to do the filtering inbound and
> > outbound, but reading the pfil man page I seem to disaggree with that.
> >
> > Has anyone encountered the same problem? And, more important: if i
> > give up the bridge setup and switch to routing, would that have any
> > effect? I.E: will I then be able to use keep state with the inbound
> > rules?
> >
> > Any help at all would be hugely appreciated as I am trying for about a
> > week to sort out this problem and can't seem to get any closer. The
> > only solution was to kindly ask my clients using TCP window scaling
> > (Vista mostly) to turn off this feature... Now I am seriously
> > considering bumping my bridge to a router but I am not sure that the
> > problem will be solved then.
> >
> > Oh, here is the setup of the bridge from rc.conf, although there
> > shouldn't be any problems there (the bridge works fine without pf, or
> > with pf stateless):
> >
> > #
> > # Core:         em2 -> vlan1
> > # Border:       em1 -> vlan0
> > # Bridge0       vlan0 -><- vlan1
> > #
> > cloned_interfaces="bridge0 vlan0 vlan1"
> > ifconfig_em0="up"
> > ifconfig_em1="up"
> > ifconfig_em2="up"
> > ifconfig_vlan0="vlan 132 vlandev em1 up"
> > ifconfig_vlan1="vlan 132 vlandev em2 up"
> > ifconfig_bridge0="addm vlan0 addm vlan1 up"
> > # Admin iface
> > ifconfig_em0="inet adminIP netmask 255.255.255.0"
> >
>
> See "Create TCP states on the initial SYN packet" from
> http://undeadly.org/cgi?action=article&sid=20060928081238
>
> That paragraph explains nicely the necessity of pf to create state on
> the first packet of the 3-way TCP handshake to prevent TCP window
> scaling issues.

I aggree with you. My problem is why doesn't pf establish the
connection correctly with the first outbound rule (the SYN packet
passes that rule). Furthermore: why everything stalls if I use keep
state on the inbound rules also? Because that would make the most
sense: using keep state with every rule...
In a routing environment it all works fine, but not with the bridge.
So I guess that the problem could be the bridge, although everything
else works fine besides "keep state" on inbound rules...

Costin

>
> =Adriaan=
>
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
>