Bridging pf firewall not reliable - BSD

This is a discussion on Bridging pf firewall not reliable - BSD ; Hi, I have been trying to use reliably OpenBSD with pf has a firewall for our school for several years, through several OpenBSD releases (3.5 to 4.2) and arch. We always come up with a complete hang in the trafic, ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Bridging pf firewall not reliable

  1. Bridging pf firewall not reliable

    Hi,

    I have been trying to use reliably OpenBSD with pf has a firewall for
    our school for several years, through several OpenBSD releases (3.5 to
    4.2) and arch.

    We always come up with a complete hang in the trafic, about once every
    week, that need console intervention.

    Pf is used in bridging (stealth) mode.

    With hme on sparc and OpenBSD 3.7, the error is on the network driver
    which is overflooded in some way. Either a Receive FIFO overflow or a
    tag error during receive:


    hme1: status=20
    hme0: status=20
    hme1: status=200000

    One can find these status in the hmereg.h file:

    /src/sys/dev/ic/hmereg.h

    #define HME_SEB_STAT_RFIFOVF 0x00000020 /* rx fifo overflow */
    #define HME_SEB_STAT_RXTERR 0x00200000 /* tag error during rx dma */

    The IF with this errors stops sending trafic until reset with ifconfig
    down/up or until a complete reboot.


    ( the same hang happened with vge driver on i86 with OpenBSD 3.7. With
    OpenBSD 4.2, the os drops into the debugger somewhere in the vge driver...)


    I understand the trafic is high and there might be more packet than the
    IF can handle, but is there a way not to block the interface by catching
    the overflow and react otherwise by droping the packet, and still be
    functioning ?

    When too much packet go down to a computer's IF-kernel, it just drops
    them and the higher protocols use their own mechanisms to recover.


    I do not know what to do now, since we need a firewall cheap and in
    stealth/bridging mode.

    Which code in the kernel catches the IF error ? Is this an interrupt
    launchd and caught somewhere ?


    Any ideas appreciated: good experience with other driver, completely
    other fw that can work in bridging mode, etc...


    Many thanks


    Regards

    François Tamone

    n@d.c
    where n=t, d=eig, c=ch

  2. Re: Bridging pf firewall not reliable

    Try to find another network card, or another machine.

    The problem lies not with pf, but with flaky hardware.

  3. Re: Bridging pf firewall not reliable

    > Try to find another network card, or another machine.


    So far I have had hang problem with at least two different hardwares:
    - hme (100Mbit sun U10 network card driver)
    - vge (1Gb Zyxel in a i86 pc )

    How many network card shall I blind test before to find the good one !

    Anybody with experience of pf bridging with steady trafic and no hangs
    due to wrong overflow exception dealing ?

    > The problem lies not with pf, but with flaky hardware.


    On this I must say that I find pf not very good at bridging firewall:

    I have this state table / window scaling problem I find hard to settle.
    If the fist packets of tcp transaction -where tcpwindow scaling is
    negociated- are not passing through the exact same rule, each end might
    have a different value for the window scaling bit and trafic ceases.

    On the other end, in bridging pf rules I am not sure on how to be sure
    that both directions of the same tcp transaction passe trough the exact
    same rule and state table.

    Onother problem is with bridge and spanning tree, which is not working
    as expected with my cisco gear, but this might be a cisco problem...

    Many thanks

    François
    ----
    n@d.c where n=t, d=eig, c=ch

+ Reply to Thread