Announcement

Collapse
No announcement yet.

Fedora 32 Looking At Switching Firewalld From Iptables To Nftables

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Zucca
    replied
    Originally posted by tuxd3v View Post
    I am just asking since iptables syntax is literally very simple, at least for this "99% use cases"..
    I never fully understood iptables logic. But I really didn't use it that much since I switched to nftables quite early.

    Leave a comment:


  • Weasel
    replied
    nftables syntax isn't that much more difficult for the simple stuff.

    Leave a comment:


  • tuxd3v
    replied
    Originally posted by chilinux View Post
    It might be that the current user-space tools still have limitations but at least the inflexibility that puts limits on the usefulness and performance optimization is finally being move out of the kernel in the new model.
    first of all, thanks a lot for your comment!!
    I still have some doubts that I need to sort by myself, about this new model..
    I understand that its better to use less resources, if we can..

    But I don't really know the trade offs needed to achieve that..
    It could be that the new model is weird? I mean maybe complex, for the majority of situations, and in this case.. you end up creating something, that plays nice with 1% of the situations but in 99% of the cases, is not needed?

    I am just asking since iptables syntax is literally very simple, at least for this "99% use cases"..

    Leave a comment:


  • pal666
    replied
    Originally posted by chilinux View Post
    Considering Fedora is normally the incubator to test changes for Red Hat Enterprise Linux
    no more than debian is normally the incubator to test changes for ubuntu

    Leave a comment:


  • Zucca
    replied
    Oh... I do hope nftables isn't going away as some users here suggested. I've been using nftables for quite a long time. So long in fact, that I've removed the old iptables stuff from kernel.
    Yes. a Gentoo user here. Hi.

    Leave a comment:


  • Spam
    replied
    Iptables is usling same backend as nftables.

    # iptables -version
    iptables v1.8.3 (legacy)

    Leave a comment:


  • chilinux
    replied
    Originally posted by tildearrow View Post

    Neither.

    Code:
    $ iptables --version
    iptables v1.6.0
    Will assume it's legacy though...
    I don't think version 1.6.0 had any provisions to use nf_tables so legacy seems about right.

    Leave a comment:


  • tildearrow
    replied
    Originally posted by chilinux View Post

    If you run: iptables --version

    Does it then spit out a line ending with "(legacy)" or ending with "(nf_tables)"?

    If it says legacy then it is not shared. If it says nf_tables, then it is.
    Neither.

    Code:
    $ iptables --version
    iptables v1.6.0
    Will assume it's legacy though...
    Last edited by tildearrow; 09-12-2019, 12:36 AM.

    Leave a comment:


  • chilinux
    replied
    Originally posted by tildearrow View Post

    I thought these were shared? (e.g. adding a rule with iptables and deleting it with nft)
    If you run: iptables --version

    Does it then spit out a line ending with "(legacy)" or ending with "(nf_tables)"?

    If it says legacy then it is not shared. If it says nf_tables, then it is.

    Leave a comment:


  • chilinux
    replied
    Originally posted by tuxd3v View Post
    I don't get why somebody wants to change iptables or netfilter, by some crap..
    iptables is part of a suite of utilities that include iptables (for IPv4), arptables, ip6tables and ebtables

    Both the syntax and the code used with this suite make strong assumptions about the protocols that will be used. You want to allow/deny IPv4 (Layer 3) for a specific TCP (Layer 4) port, then iptables has the syntax for that. If you want to block LLDP (Layer 2) packets then ebtables has the syntax to do that.

    For over 90% of use cases, given the popularity of TCP/IP and UDP/IP, the suite that makes up iptables has worked out alright for now. Some side cases have been kind of address through iptable extension modules. Modern CPUs have kept up alright with 1gbps traffic. Things have been alright and most people's itch have been scratched.

    But this suite is now two decades old and some of the assumptions don't scale well for the future.

    What if you need a rule that applies only to VXLAN 5,001 (not VLAN but RFC 7348 VXLAN) for GRE tunneled IPv6 packets and block all packets with a source address of FD00::/8? The legacy filter system doesn't have a clean way to add this rule. This gets into concepts that pre-date assumptions about what protocols the filters would be used to act on. So, is it left to the user to write their own xtables kernel extension? Is it realistic that addressing side cases via code written by the user without being vetted by the standard kernel development process still provide an environment that continues to be just as stable and reliable? How will does doing things this way scale up to 10Gbps networking?

    The "some crap" that "somebody" wants to change to from the legacy filter system is designed to more cleanly answer these questions. It provides a flexible method to remove all assumptions about the protocols and protocol layers that will be filter out of the kernel. Brand new protocols that don't exist today could be filtered under the new system just be providing a new user-space tool that uses the new filter model. That flexibility greatly changes what additional use cases Linux can be used for in the future.

    It might be that the current user-space tools still have limitations but at least the inflexibility that puts limits on the usefulness and performance optimization is finally being move out of the kernel in the new model.

    Leave a comment:

Working...
X