Problems with IPFW and 5.3-BETA1

From: Radek Kozlowski (radek_at_raadradd.com)
Date: 08/26/04

  • Next message: Ruslan Ermilov: "Re: No more floppy drive" 
    Date: Thu, 26 Aug 2004 00:23:04 +0200
To: current@freebsd.org

    I upgraded a remote dedicated server from 5.1 to 5.3-BETA1 today with a
    step by step procedure described in /usr/src/Makefile and everything
    went ok. Well, almost. I compiled the kernel (took the GENERIC conf
    from 5.3, so options PFIL_HOOKS is already there) with:

    options IPFIREWALL
    options IPFIREWALL_VERBOSE
    options IPFIREWALL_VERBOSE_LIMIT=100

    put firewall_enable="YES", firewall_type="open" in rc.conf, rebooted and
    locked myself out (world and kernel are in sync, before someone asks).
    After I could access the box again I tried to see what was wrong:

    root@wesside:~# ipfw show
    00100 0 0 allow ip from any to any
    65535 0 0 deny ip from any to any
    root@wesside:~# ping yahoo.com
    PING yahoo.com (66.94.231.98): 56 data bytes
    64 bytes from 66.94.231.98: icmp_seq=0 ttl=58 time=3.324 ms
    64 bytes from 66.94.231.98: icmp_seq=1 ttl=54 time=5.138 ms
    64 bytes from 66.94.231.98: icmp_seq=2 ttl=58 time=3.671 ms
    ^C
    --- yahoo.com ping statistics ---
    3 packets transmitted, 3 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 3.324/4.044/5.138/0.786 ms
    root@wesside:~# ipfw show
    00100 0 0 allow ip from any to any
    65535 0 0 deny ip from any to any

    Why aren't the packet and byte counters increased?

    Since the firewall was totally unresponsive to any rulset changes I
    removed above options from the kernel and decided to try the module
    instead. With firewall_type="open" left in rc.conf (but firewall_enable
    changed to "NO") I executed
    `kldload /boot/kernel/ipfw.ko && sh /etc/rc.firewall ; sleep 100 ;
    kldunload ipfw ; sleep 200 ; reboot` and locked myself out again. I
    don't know what really happend and am still waiting for the reply from
    the support team of the hosting company, but is it me or there's
    something wrong with ipfw? Anyone else seeing this?

    I'd appreciate any pointers.

    -Radek
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  • Next message: Ruslan Ermilov: "Re: No more floppy drive"

    Relevant Pages

    • Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility)
      ... For simple using, however, you don't need to bother all that details - just remember magic number and where to place it, and it is now simple for use with ipfw tags. ... Currently the only analyzing node in FreeBSD src tree is ng_bpf, but it merely splits incoming packets in two streams, matched and not. ... There are reasons to this, as netgraph needs to be modular, and each node does a small thing, but does it well. ... For long time ng_bpf was used for another purposes in the kernel, and now, as new ipfw features appeared, ng_tag came up for easy integration. ...
      (freebsd-current)
    • Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility)
      ... For simple using, however, you don't need to bother all that details - just remember magic number and where to place it, and it is now simple for use with ipfw tags. ... Currently the only analyzing node in FreeBSD src tree is ng_bpf, but it merely splits incoming packets in two streams, matched and not. ... There are reasons to this, as netgraph needs to be modular, and each node does a small thing, but does it well. ... For long time ng_bpf was used for another purposes in the kernel, and now, as new ipfw features appeared, ng_tag came up for easy integration. ...
      (freebsd-isp)
    • Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility)
      ... For simple using, however, you don't need to bother all that details - just remember magic number and where to place it, and it is now simple for use with ipfw tags. ... Currently the only analyzing node in FreeBSD src tree is ng_bpf, but it merely splits incoming packets in two streams, matched and not. ... There are reasons to this, as netgraph needs to be modular, and each node does a small thing, but does it well. ... For long time ng_bpf was used for another purposes in the kernel, and now, as new ipfw features appeared, ng_tag came up for easy integration. ...
      (freebsd-net)
    • Statefull filtering with IPFW + IPFilter (was: Packet flow through IPFW+IPF+IPNAT)
      ... > make a difference if they were loaded as modules or compiled in kernel. ... I have done some tests with IPFW and IPF compiled in kernel and I was ... not work in IPFW but only work in IPFilter ??? ... This flow of packets will give IPFW work with right statefull filtering ...
      (FreeBSD-Security)
    • FreeBSD Security Advisory: FreeBSD-SA-01:08.ipfw [REVISED]
      ... included in FreeBSD 4.0 and above. ... based on an old version of ipfw and does not contain as many features. ... Due to overloading of the TCP reserved flags field, ... incorrectly treat all TCP packets with the ECE flag set as being part ...
      (FreeBSD-Security)